“DDoS protection included” is printed on every hosting price list, and it means something different at every provider. This post explains what ours does, in the order events actually happen during an attack, what it costs you in latency (nothing, in the normal case), and the class of attacks that no network-level mitigation can absorb on your behalf.
Detection: sFlow at the edge
Every border router in our six locations exports sampled flow records to a collector in the same site. The collector keeps a per-destination baseline (packets per second, bits per second, and the mix of protocols) and compares the last few seconds against it. A destination whose traffic jumps by an order of magnitude with a shape that looks like an attack, for example millions of UDP packets from tens of thousands of sources, or a SYN rate no legitimate service produces, is flagged within two to four seconds of the flood starting.
Sampling means the collector sees one packet in a few thousand, which is enough to recognise a volumetric attack but not enough to notice a slow application-layer one. We come back to that limit at the end.
Diversion: the affected prefix moves, the rest does not
When a destination is flagged, the collector announces its /32 (or /128) into the site's routing with a next hop pointing at the scrubbing cluster. Only that address changes path; every other server on the same host, in the same rack or in the same /24 keeps its normal route. Diversion takes one BGP update inside the site, so from detection to scrubbing is typically under ten seconds.
Traffic for the flagged address now enters the scrubbing cluster, which is a set of servers running DPDK-based filters with capacity well above the site's total transit. The filters drop the attack by signature first (amplification sources, malformed packets, spoofed ranges), then by behaviour (per-source rate limits, SYN cookies, TCP handshake validation), and forward what survives to the original server over the internal network. Your server sees the clean remainder with the original source addresses intact.
What “always on” means for your latency
It means nothing is inline until an attack is detected. In normal operation, packets take the direct path from the border router to your server; the scrubbing cluster is not on it, so there is no added hop, no added latency and no proxy rewriting your headers. During an attack, the extra hop through the cluster adds a few hundred microseconds inside the site. That is the entire latency cost of the protection, and you only pay it while under attack.
The alternative design, where all traffic always passes through a filter, protects against nothing more and costs everyone a little latency all the time. We do not do that.
Capacity, and where it comes from
Each hub site (Frankfurt, New York, Singapore) has scrubbing capacity larger than its combined transit and peering, so an attack that saturates the upstream links is stopped before it can. Attacks larger than a single site's transit are the reason we keep multiple upstreams with independent paths, and why the largest floods are absorbed with our upstream carriers' own mitigation, which they announce under a signed contract, before they reach us at all. The smaller sites (Amsterdam, Helsinki, Los Angeles) divert attacked prefixes to the nearest hub over our backbone.
We do not publish a single terabit figure because it would be true only for one attack shape. The figure that matters is that in the last twelve months no attack against a customer has caused a measurable loss for customers on the same site who were not the target. That is the promise: your neighbour's problem stays your neighbour's problem.
Release
When the collector sees the attack traffic fall back to baseline for a few minutes, it withdraws the diversion and the address returns to the direct path. Repeated attacks on the same address keep the diversion in place longer, up to a few hours, to avoid flapping. You can see the state in the panel under the server's Network tab and in the event log, with the peak rate observed.
What we cannot absorb for you
A layer-7 flood is a few thousand well-formed HTTPS requests per second against an expensive endpoint of your own application, from real browsers or from a botnet that speaks TLS properly. To the network it looks like traffic; to your application it looks like a very busy day, and it takes your CPU or database down before any packet count crosses a threshold. Network mitigation cannot tell those requests from customers, and neither could we without decrypting your traffic, which we do not do.
The defences for that live in your stack:
- Rate limiting per client in nginx or Caddy (
limit_req, or Caddy's rate-limit plugin), with a stricter bucket for login and search endpoints. - Caching anything that can be cached, so an attack hits the cache rather than the application.
- A CDN or a WAF in front of the origin if you need challenge pages and bot scoring; keep the origin's IP out of DNS so the attacker cannot bypass it.
- Connection limits and timeouts tuned so that slow-request attacks cannot hold every worker.
We will happily help with any of those in a ticket, and a server that is being attacked at layer 7 is never null-routed for it; it just needs application-level defences that only you can configure.
The rules in one place
- Detection in seconds, diversion of only the attacked address, scrubbing in the same site.
- No latency cost when not under attack; a few hundred microseconds when you are.
- No cap on how many attacks or how long; it is part of every plan, not an add-on.
- We never null-route a customer for being attacked. Null routes are for outbound abuse, which is a different story told in our abuse policy post.