Filters and capture rules
Save the History queries you use on every hunt as presets, and set capture rules that drop or flag traffic at the proxy.
You type the same three queries on every target. The Filters view turns them into named presets, and goes one step further: capture rules that act on traffic as it passes the proxy — keep it, flag it, or drop it — instead of filtering it after the fact.

Saved filter presets
The left panel lists your presets; the right panel edits the selected one. A preset can use every filter field Hugin has — beyond the query language, the Advanced sections cover:
- Size & latency bounds.
- Negative filters — exclude by method, host, status, path, request/response body content, response header, content-type, or tag. This is where the CDN noise goes.
- Time window — a recurring time-of-day window or an absolute date range. "Only flows from last night's test window" is one preset.
- Content search — match on request body, response body, response header, or parameter.
Apply a preset from the dropdown in the filter bar above History — and save the query you just typed there as a new preset without leaving the view.
Capture rules
Capture rules run in the proxy on every request. A rule is one or more
conditions — field operator value, optionally negated, joined by all
(AND) or any (OR) — plus an action:
- capture — keep the flow (the default behaviour).
- flag — forward it normally but mark the stored flow, so the interesting class of traffic is pre-highlighted when you get to History.
- drop — block it; the client gets a synthetic
403and nothing reaches the server. The clean way to kill telemetry beacons or a noisy third party for the whole session.
Condition fields cover the HTTP phase (host, method, path, extension,
status, content_type) and the WebSocket phase (ws.opcode, ws.direction,
ws.payload, ws.size); operators are equals, contains, starts_with,
ends_with, and regex. Rules are evaluated by priority, highest first —
the first enabled rule that matches wins.
Bambda predicates
When a field/operator condition can't express the match, write it as a Bambda — a sandboxed Lua predicate over the flow:
return flow.status >= 500
The editor ships presets for the common hunts — server errors, requests with
parameters, Authorization header present, Set-Cookie responses, responses
with no cache headers, empty bodies, "interesting" status codes — and an AI
Generate from prompt button that writes the expression from a description.
Filter presets hide noise after capture; capture rules stop it at the proxy. If a host pollutes every view on every target, a drop rule beats re-typing the exclude.