Quick answer
Game servers are attacked more than almost anything else and are harder to protect than a website, for three reasons: they run on UDP, which no HTTP proxy can handle; they are latency-sensitive, so protection that adds a detour is its own kind of outage; and their address is usually published to players, so it cannot be hidden by DNS alone. The practical answer is routed or tunnelled transit that filters UDP inline rather than discarding it, with the real server address firewalled so the filtered path is the only way in.
Why it is harder than protecting a website
That last row matters operationally. A game server under attack usually does not go down; it becomes unplayable while still responding to a health check. Monitoring that only asks "is it up" reports everything as fine while your players are leaving.
| Website | Game server | |
|---|---|---|
| Protocol | HTTP over TCP | Mostly UDP, often custom |
| Protection route | DNS change to a proxy | Routed transit or GRE tunnel |
| Latency tolerance | 100 ms is fine | 20 ms extra is noticed |
| Can challenge clients | Yes, the browser solves it | No — a game client cannot |
| Address visibility | Hidden behind the proxy | Often published to players |
| Failure looks like | Page does not load | Lag, rubber-banding, players leave |
The UDP question decides everything
Most hosting advertised as DDoS-protected filters TCP competently and handles UDP by discarding it when a flood starts — null-routing the address or dropping the protocol for the duration. For a web server that is survivable. For a game server it is identical to the attack succeeding.
So the question to ask a provider is not whether they stop UDP floods, but whether legitimate UDP keeps flowing while they do. Those are very different products and they are marketed with the same words.
Latency is part of the product
On-demand mitigation reroutes your traffic through a scrubbing centre once an attack is detected. For a website that costs a few minutes of disruption. For a game it can mean a sudden latency jump mid-session, which players experience as the attack succeeding even though the server stayed up.
Always-on filtering in the packet path avoids the jump entirely: there is no rerouting event, because the traffic is already taking the filtered path. The steady-state overhead is a few milliseconds, which is a far better trade than an unpredictable spike.
Hiding the address when players need it
A website's origin is easy to hide because visitors only ever talk to the proxy. A game server's address is typically in a server list, a launcher, or pasted into a Discord channel — it is public by design.
The way around it is that the published address belongs to the protected network, not to your machine. Traffic arrives there, is filtered, and reaches your server through a tunnel. Your real address never appears anywhere a player could see it, and the firewall on your box accepts nothing else.
- Publish only the protected address; never the machine's own
- Firewall the server to accept traffic solely from the filtering network
- Watch for leaks: status pages, query APIs and crash reports often expose the real IP
- Remember that a player with your real address can attack it directly, and some will
What to check before buying
- Is UDP filtered or discarded under load? — the single most important question
- Is mitigation always-on, or activated after detection?
- What is the added latency in normal operation, not during an attack?
- What happens when an attack exceeds the included capacity?
- Are per-port policies possible, so your game port is treated differently from everything else?
- Is attack traffic billed, or included?
- Can you keep your existing host, or is migration required?
Frequently asked questions
Last updated