Traffic Filtering Rules
Decide who gets through a short link: conditions on network type, visitor quality, geography and time, with five outcomes and a preview that matches the redirector.
Updated August 14, 2026
A traffic rule is a condition attached to a link and an outcome for the visitors who match it. Rules are evaluated at the edge, before the destination is chosen, and the first rule that matches decides what happens. A link with no rules performs no extra work at all.
Traffic rules are a paid capability. If the Rules tab is missing from the link dialog, the workspace plan does not include them.
Where rules live
Rules exist in two places and are evaluated in this order:
- The link's own rules — the Rules tab of the link dialog.
- The workspace rule set — one shared list applied to every link in the workspace.
Link rules run first, which is what lets a single link carry an exception above a general ban: block every data centre across the workspace, and let your uptime monitor through on the one link it watches. A link can also switch the shared set off entirely with Ignore workspace rules.
Both lists are capped at twenty rules, and the combined list is capped at twenty as well.
Conditions
A rule needs at least one condition; a rule with none would swallow all traffic and make every rule below it unreachable, so the form refuses to save it. Conditions inside one rule are joined by and — all of them must be met.
| Condition | What it matches | | --- | --- | | Visitor type | The classifier's verdict: human, search crawler, library, data centre, VPN, TOR, unknown | | Verified crawler | Whether a declared crawler is confirmed by its address, not by its name | | Network type | Data centre, public proxy, commercial VPN, TOR exit, web anonymiser | | Quality below | Quality score strictly below a threshold from 1 to 100 | | Country / region / city | Location of the visitor's address range | | Autonomous system | Network number, up to 200 per rule | | Address or subnet | Individual addresses and CIDR ranges, up to 1,000 per rule | | User agent / referrer | Text pattern against the header | | Campaign tags present | Whether the request carries UTM parameters | | Device / language | Device class and preferred language | | Local time / weekday | Time window and days in the visitor's time zone | | Visit | First visit to this domain, or a repeat one |
Every condition is three-valued: met, not met, or unanswerable because the data is missing. Unanswerable never counts as a match. The Invert switch flips only a confident answer, so "everyone except Germany" does not quietly fire on visitors whose country could not be determined.
Reusable address lists
Address lists are defined once for the workspace and referenced by rules. A rule may reference up to five lists. Lists are expanded into the link's cached configuration when you save, so the redirector never fetches a list while a visitor is waiting.
Outcomes
| Action | What the visitor gets | | --- | --- | | Pass | The normal destination. The match is still recorded. | | Block 404 | The ordinary not-found page — indistinguishable from a link that never existed. | | Block 410 | A branded "link unavailable" page. | | Redirect | A different destination, chosen by the rule. | | Stub page | A branded page with your own heading and text. | | Warn | The normal destination, with the visit marked as suspicious. |
Pass exists so that filtering can be audited. A rule that lets traffic through and records that it did is how you check a filter before you make it block anything.
Blocking with 404 returns the ordinary not-found page on purpose. Anything more specific tells whoever is probing your links that they found something worth probing.
Preview before you publish
The Preview panel takes a hypothetical visitor — country, device, network type, time of day, first or repeat visit — and shows which rule fires and where that visitor lands. It is not a separate implementation: the preview calls the same function the edge worker calls, and an end-to-end test compares its answer with the real Location header of a real redirect.
Reading the results
Every match is written into the click event with the rule identifier and the action. The Filtered breakdown on the analytics screen answers two questions: how much traffic each rule stopped, and what it did with it. The action is stored next to the identifier so that the breakdown still reads correctly for rules you have since edited or deleted.
Rules keep their identifiers across saves. Renaming or reordering a rule does not break its history.
What filtering costs
Filtering runs on the path to the redirect, so the engine fetches only what the rules of that specific link need:
- a country, region or city condition triggers a geo lookup;
- a network-type condition loads the range set;
- a verified-crawler condition reads a cache entry;
- a first-visit condition sets a small cookie on your redirect domain — and only when a rule actually asks for it.
Whatever the rules fetched is reused by the background task that assembles the click event, so nothing is looked up twice.
Limits by plan
Plans can cap the number of rules per link. When a plan's cap is lower than the number of rules already configured, existing links stay editable — the cap applies to adding rules, not to saving a link that already has them.