DDoS protection for game servers

02Know exactly what you expose

Every filtering policy starts from a list of the ports the game actually uses. Anything else that answers on the machine — an admin panel, a database, a forgotten query port — is attack surface with no players behind it.

The two most common community servers each have a dedicated guide: protecting a Minecraft server covers proxies such as Velocity, and FiveM DDoS protection covers the server's proxy and endpoint settings.

03The UDP question decides everything

Some 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.

Much of the volume in a UDP flood is reflected: small spoofed requests to DNS, NTP, memcached and similar services come back as large answers aimed at you, as explained in amplification attacks. CISA lists bandwidth amplification factors of 556.9 for NTP and 10,000 to 51,000 for memcached (see NTP amplification and memcached amplification), and the reflected traffic arrives from those services' well-known source ports.

# reflected UDP, counted by source port
tcpdump -nn -q -i eth0 -c 5000 'udp and (src port 53 or src port 123 or src port 389 or src port 1900 or src port 11211)' \
  | awk '{print $3}' | awk -F. '{print $NF}' | sort | uniq -c | sort -rn

# game traffic reaching the public interface from outside the filtering
# network (example range): if real players show up here, the address leaked
tcpdump -nn -q -i eth0 'udp dst port 30120 and not src net 203.0.113.0/24'

04Latency 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. Its steady-state cost is the detour to the filtering site and back, so where that site sits relative to your players matters more than its headline capacity.

This is the model behind remote DDoS protection: the filtering happens on the provider's network, and only clean traffic is delivered to the server you already run.

05Hiding 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.

The tunnel is usually GRE, sometimes IPIP; the difference between GRE and IPIP matters mostly for what else you need to carry through it. GRE is IP protocol 47, so the server's firewall can accept it from the provider's tunnel endpoint alone. Replies have to leave through the tunnel as well, which is a routing setting your provider documents.

• 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

#!/usr/sbin/nft -f
table inet game_edge
delete table inet game_edge

table inet game_edge {
    chain input {
        type filter hook input priority filter; policy accept;
        iif "lo" accept
        ct state established,related accept

        # the tunnel itself: only from the provider's endpoint
        ip protocol gre ip saddr 203.0.113.1 accept
        ip protocol gre counter drop

        # FiveM example: 30120 over TCP and UDP, inside the tunnel only
        iifname "gre1" meta l4proto { tcp, udp } th dport 30120 accept
        meta l4proto { tcp, udp } th dport 30120 counter drop
    }
}

06Lag or attack?

Players report lag for many reasons, and only some of them are attacks: everyone lagging at once while the process stays healthy points at a flood, while lag confined to one ISP or region is usually routing upstream, which a traceroute or MTR from an affected player shows. A server that is suddenly unreachable from everywhere has often been null-routed by its host, the failure described under the UDP question above, so ask the host before changing anything. The network checks that confirm a flood on a game server are in signs of a DDoS attack.

07What to check before buying

• Is UDP filtered or discarded under load? — the single most important question
• Is mitigation always-on, or activated after detection?
• Where are the filtering sites, and how far are they from your players?
• 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?