Why one stage is never enough
Every stage of DDoS protection is blind to something. A network big enough to swallow a 7 Tbps flood is measuring bits per second — it has no idea what a Minecraft handshake is. A filter that reads the Minecraft protocol perfectly is useless if the flood filled your uplink before it ran. The two failure modes are opposite, which is why real protection is a sequence rather than a product: each stage removes what the next one cannot see, and hands the remainder down.
The diagram below is that sequence, with one attack pushed through it end to end — sized to the largest volumetric attack this network has actually mitigated.
One flood, six stages
A 7 Tbps attack traced from the internet to a Minecraft backend. Each stage removes what the stage below it cannot see.
Anycast absorption
Cloudflare Spectrum
7Tbpsinbound−6.6 Tbps · 94%The raw flood lands on Cloudflare's anycast fabric and is spread across 330+ cities. Volumetric L3/L4 garbage — reflection, amplification, spoofed UDP — dies here, on a network with 500+ Tbps of published capacity.
L4 mitigation
Papyrus · AS216013
≤ 600 Gbps
400Gbpsinbound−202 Gbps · 51%What survives is TCP that at least looks like it wants a connection. Kernel-level SYN filtering and per-source rate limits drop the connection floods before they reach userspace.
L7 mitigation
Papyrus · AS216013
198Gbpsinbound−170 Gbps · 86%Connections that complete a handshake but never speak valid Minecraft — scanners, generic L7 floods, malformed protocol — are dropped once the payload fails to parse.
Protocol-aware antibot
Cryo
28Gbpsinbound−27 Gbps · 96%Now everything left speaks fluent Minecraft. Cryo parses the handshake itself: hostname, protocol version, join rate, origin ASN and history all feed a verdict. Auto-UAM tightens the limits as the flood grows.
Verification gauntlet
CryoLimbo
1Gbpsinbound−646 Mbps · 62%The residue is bypass bots — clients written specifically to look human to an antibot. They are detoured into limbo and made to prove it with physics and behaviour checks. Real players caught here pass and continue.
Clean traffic
Your server
400MbpsarrivesWhat arrives is players. Real client IPs are delivered via PROXY protocol, so bans and per-IP plugins behave exactly as they would on a direct connection. The origin never saw the other 6.99 Tbps.
Stage 1 — Absorption, where volume stops being a problem
The first question in any attack is arithmetic, not security: is the pipe bigger than the flood? If 7 Tbps arrives at a 10 Gbps uplink, the uplink is full and everything behind it is offline — the server, its firewall and any plugin it runs are all on the wrong side of a road that is already blocked. Nothing you configure on the machine changes that.
This is the entire reason absorption has to happen on a network with more capacity than the attacker can generate. Traffic enters through Cloudflare Spectrum's anycast fabric, where a single flood is split across 330+ cities and absorbed by a network with 500+ Tbps of published capacity. By volume this stage does almost all the work — 94% of the flood in the example — and by usefulness it does the least interesting part: it removes the traffic that was never pretending to be anything.
Stage 2 — L4 mitigation, connections without content
What survives absorption is traffic that at least wants to open a connection. This is the SYN-flood tier: enormous numbers of connection attempts, often spoofed, designed to exhaust connection-tracking state rather than bandwidth. Filtering happens in the kernel on our own network (AS216013), before any of it reaches userspace, with per-source rate limits and connection budgets.
Layer 4 knows a connection arrived. It does not know what the connection said — it cannot distinguish a player from a bot, because at this layer neither has said anything yet. Anything that gets past it is a legitimate-looking TCP connection, and from here the questions stop being about volume.
Stage 3 — L7 mitigation, is this even the game?
Now the traffic gets read. A large share of what completes a handshake never speaks Minecraft at all: internet-wide scanners, generic HTTP floods aimed at whatever answers, and malformed junk hoping something crashes. None of it survives contact with a parser that expects the Minecraft protocol and gets something else.
This is the first stage that a generic "game protection" appliance struggles with, because it requires actually implementing the protocol rather than matching packet shapes. It is also where the volume drops far enough that the remaining traffic is genuinely dangerous — everything past this point is speaking your game's language.
Stage 4 — Protocol-aware antibot, the stage that matters
Everything still moving is now fluent Minecraft: valid handshakes, plausible usernames, correct protocol versions, arriving from thousands of residential and datacenter addresses. This is the attack that actually kills Minecraft servers, and it is invisible to every layer above — each connection is individually indistinguishable from a real player joining.
- Hostname awareness — a connection asking for a hostname you do not serve is not a player who made a typo, and is dropped before anything else runs.
- Join-rate limits with auto-UAM — per-IP and global budgets that tighten automatically as combined ping and login rate climbs, so the response scales with the attack instead of being configured for it in advance.
- Risk scoring — origin country, ASN, datacenter range, protocol behaviour and prior history combine into a verdict before the join is allowed to continue.
- Ping and MOTD handling — status floods are answered from edge cache rather than being forwarded to your server to answer several thousand times a second.
In the example this stage removes 96% of what reaches it — 26 Gbps of traffic that would otherwise have arrived at the backend as apparently-real join attempts. This is the same engine described in detail in how Cryo mitigates an attack.
Stage 5 — Verification, for bots built to pass stage 4
A well-written bot studies the antibot. It paces its joins, uses plausible names, connects from residential proxies and does nothing that scores as anomalous — because it was built specifically not to. Scoring alone cannot catch it, and this residue is what people mean by bypass bots.
So the last stage stops scoring and starts asking. Suspicious joins are detoured into CryoLimbo, a lightweight limbo world, and required to demonstrate they are a real client — movement that obeys the game's physics, correct responses to server state, behaviour that a headless bot has to genuinely implement rather than merely imitate. Passing is cheap for a player and expensive for an attacker, which is the whole design. Real players caught here pass and continue to your server, usually without noticing.
What actually arrives
400 Mbps of players. Your server sees the connections it would have seen on a quiet day, with real client IPs delivered via PROXY protocol, so bans, alt detection and per-IP plugins behave exactly as they would on a direct connection. From inside the server the attack is not a smaller problem — it is not visible at all, which is why an operator's first sign of one is usually a Discord alert rather than a lag spike.
The proportions are worth sitting with. The volumetric stage removed 94% of the flood and the final two stages removed under 0.4% between them — and yet those last two are the ones that decide whether the server stays up, because they are the only ones that could tell a bot from a player. Capacity buys you the right to have the interesting problem. It does not solve it.
Where the stages live matters as much as what they do
Every stage above runs before your hardware, which is the structural point rather than an implementation detail. A plugin can do a version of stage 5's job and some do it well — but it runs after the connection has already been accepted, allocated and parsed by your machine, so it is fighting on the wrong side of the uplink. That trade-off is worked through in edge antibot vs plugin antibot, and it is why the sensible arrangement is an edge in front with a plugin behind it as a second layer, not one instead of the other.
Common questions
How does DDoS protection actually work?+
By filtering traffic somewhere with more capacity than the attack, before it reaches the target. Protection is a series of stages, each catching what the one before it structurally cannot see: a huge network absorbs the raw volumetric flood, packet filtering drops connection floods, protocol filtering drops traffic that is not really the game, and behavioural verification catches bots that imitate players convincingly. No single layer does the whole job.
Why can't a firewall or plugin stop a DDoS attack?+
Because of where they sit. If 7 Tbps is aimed at a 10 Gbps uplink, the uplink is full and nothing running on the far side of it gets a vote — the server is offline whether or not its firewall rules are perfect. A plugin acts even later, after a connection has already cost a slot, a thread and a login. Both are useful as final layers; neither can be the first one.
What is the difference between Layer 4 and Layer 7 DDoS protection?+
Layer 4 works on connections: SYN floods, spoofed packets, raw connection rate. It can tell you a million TCP connections arrived but not what any of them said. Layer 7 works on what the traffic actually is — for Minecraft, whether it speaks the protocol, what hostname it asked for, and whether the join behaves like a player. Bot attacks are Layer 7 problems, which is why L4-only filtering passes them straight through.
How much traffic actually reaches my server during an attack?+
In the worked example on this page, 400 Mbps out of 7 Tbps — a 17,500× reduction, with the origin never seeing the other 6.99 Tbps. The exact ratio varies with the attack, but the shape is consistent: the volumetric stage removes the overwhelming majority by volume, and the last stages remove the traffic that would actually have taken your server down.
Does filtering this many stages add latency for players?+
Barely measurably, because the stages run inline at wire speed rather than queuing traffic for inspection. Players connect to the nearest anycast entry point — often a shorter path than reaching your server directly — and only connections that look suspicious are held for verification. A clean join passes through every stage described here without stopping at any of them.
Every stage on this page runs on every plan, including the free one — paid tiers add capacity and control, not protection. Create a free network and you are behind all six in about five minutes.