Overview
How traffic reaches you through our mitigation network, and what it does on the way.
Every address we announce sits behind the mitigation network, and every service we sell is behind it by default. There is no "under attack" mode to switch on, no add-on to buy, and no reduced tier for consumer hosting — a game server and a B2B remote-mitigation deployment are filtered by the same stack.
Filtering does not wait to recognise an attack
Detection-based mitigation has to identify a flood before it can act on it, which means the first instance of anything novel reaches you. Ours works the other way round: every packet is validated against what your protocol and service legitimately expect, and anything that cannot satisfy that check is dropped — whether we have seen it before or not.
That is what "always on" means here. There is no threshold to cross, no diversion to trigger, and nothing to wait out before filtering begins.
Detection still exists — for reporting
Attack records, the Protection → Events page, attack history and attack webhooks all come from a detector that samples traffic and decides when an event started and ended. Filtering does not wait for it. Traffic can be dropped without ever growing large enough to open an attack record, so a quiet attack history does not mean nothing was filtered.
The path a packet takes
| Stage | What happens |
|---|---|
| Anycast ingress | Traffic enters at the closest edge location. A flood from many sources fragments across many nodes rather than converging on one |
| Volumetric absorption (L3/L4) | High-volume floods are absorbed at edge capacity. Malformed, spoofed and unsolicited packets are dropped statelessly here, before they cost anyone capacity |
| Stateful validation (L7) | What survives is checked against what your protocol actually expects — this is the layer filters configure |
| Clean traffic | Only validated traffic is forwarded to your infrastructure |
The two middle stages answer different questions. Volumetric absorption asks whether there is too much; stateful validation asks whether this particular packet belongs. An attack that is small enough to ignore volumetrically can still be stopped dead by the second stage, which is the usual shape of a game-server attack.
Where the capacity is
The published figures are 500+ Tbps of edge capacity for volumetric absorption, 13+ Tbps of in-house stateful filtering, and 29 edge locations across five regions. The two numbers are not interchangeable: the first is how much volume can be absorbed, the second is how much traffic can be inspected packet by packet.
terabit.io/network carries the current figures and the location list.
What is configured, and where
| What | Where |
|---|---|
| Always-on filtering | Nothing to configure. It is on before you ask |
| Default protection filters on service addresses | Managed by us. They do not appear in your own filter catalogue |
| Allow and deny rules, stateful filters | Protection → Firewall, or the firewall API |
| Geo rules — blocking by country or ASN | Portal only |
| Firewall groups | Portal only |
| Attack visibility | Protection → Events, attack history and attack webhooks |