If you run a game server with a public listing, you will be attacked. Not might be. A browser-visible server with an address anyone can read is a target that costs nothing to hit, and the people doing it are usually not sophisticated, just persistent.
Here is what happens on our side when that starts, and what changed recently about how you find out.
The flood never arrives in one place
The first thing that matters is where traffic enters the network. Ours uses anycast ingress, which means traffic arrives at the closest edge rather than travelling to one central point first.
That distinction does most of the work before any filtering happens at all. An attack aimed at your server is not one flood arriving at one door. It is split geographically across the edge by the routing itself, so no single point ever sees the whole of it. A design with one ingress point has to be big enough to survive the entire attack in one place. A design with many only has to survive a fraction of it in each.
Volumetric first, because it is most of the attack
The bulk of a typical attack is volume: L3 and L4 floods whose only real idea is to be larger than the pipe. That is absorbed at edge capacity, which is where the 500+ Tbps of volumetric capacity is spent.
The important part is not the number, it is the location. This dies at the edge, off your node entirely. It never reaches the machine your server runs on, so it never competes with your server for CPU, memory or bandwidth. A mitigation that filters on the host has already lost, because the host has already had to receive the traffic to decide it was bad.
Reflection and amplification attacks, the ones that borrow someone else’s infrastructure to multiply themselves, are handled at the same layer.
Then the part that has to be clever
Volume is the easy half. What survives it is traffic that looks plausible: correctly formed packets, arriving at the right port, in the right protocol, that are simply not from a real player.
That meets 13+ Tbps of stateful filtering, and stateful is the word doing the work. The rules are protocol-aware and game-aware. They know what a genuine join looks like for the game you are running and what a forged one looks like, which is a distinction you cannot make by counting packets. Resource exhaustion attacks, the ones that aim to tie up a server’s capacity rather than fill its pipe, are caught here rather than at the volumetric layer.
The result is the only measure that actually matters: only validated traffic reaches your server, your players stay connected, and your tick rate does not move. An attack that gets mitigated but drops your tick rate for ten minutes is one your players still experienced.
Every region, every plan, no upsell
Two things about how this is sold, because both are choices some hosts make differently.
It covers every region we run. It is not a premium location or a subset of the fleet.
It is included on every plan and is never an upsell. We do not sell tiers of protection, and we do not sell the good version separately. A protection add-on priced as an extra is a business that profits when you get attacked, which is a strange set of incentives to build a network on.
Our infrastructure now runs on Terabit-owned hardware across every region we operate, which is what makes the filtering ours to tune rather than something we rent and hope about.
You now get told when it happens
For a long time the mitigation was invisible, and that was a genuine failure even though the protection was working.
An attack would start, the filtering would absorb it, and you would find out because players mentioned the game felt off. By then you had usually spent an hour going through your own mod list and configs looking for a fault that was never on your end. Protection that works silently is still protection, but it leaves you debugging a problem you do not have.
So now:
- You get an email when an attack is detected, and a second one when it has been mitigated. It goes to the account owner and there is one switch in account settings to turn it off.
- Each server can post the same two messages to Discord, up to two channels per server. You add the channel on the server itself, so the people who actually run that community get told without needing access to the billing account. There is a test button, so you can confirm it works before an attack becomes the thing that tests it.
- Every server keeps its own attack history, showing when each attack started, when it finished and how long it ran. Anyone you have given server access to can read it, so you can settle whether last Friday really was an attack or whether something else was wrong.
- Several of your servers can share one address. When that happens you get one message about the attack, not one per server, and a large attack touching many addresses at once still only produces one message rather than filling your inbox.
What the alerts deliberately do not tell you
The alerts do not include the size of the attack, where it came from, or what kind it was. That is on purpose, and it is worth explaining because it looks like something missing.
That detail is exactly what an attacker uses to find out whether the attack worked. An attacker who can read a public readout of how much got through, from where, and in what shape has been handed a measuring instrument, and a protection service that publishes it is being used as a test rig against its own customers. So that information stays with our network team, where it is useful, rather than being echoed back to the person generating it.
It is the same reason you will not see us publish a running total of the largest attacks we have absorbed. It reads well and it tells the wrong people something worth knowing.
The short version
The flood is split at the edge before it is filtered, most of it dies there without touching your node, what survives meets rules that know what your game’s traffic should look like, and you now find out it happened instead of hunting for a fault of your own.
You can read the full breakdown on the DDoS protection page, or start a server on the order page. Game servers come with a 3-day refund window.