Game Server DDoS Defense: Filtering, Rate Limits, and Host Mitigation

Game servers are the easiest DDoS targets on the internet: they run on fixed UDP ports, respond to spoofable query packets, and a single amplification reflection can multiply traffic 500x. The mitigation picture has three layers — upstream filtering, rate limits, and host-level hardening — and most admins only discover they needed all three after the first takedown. This guide walks through each layer with concrete values, so you know what to ask a dedicated hosting provider before an attack, not during one.

What game servers get hit with

Three attack families dominate. Volumetric floods saturate the port: UDP floods at 10–100 Gbps are routine against game servers, and reflected amplification (DNS ~50x, NTP ~556x, memcached up to 10,000x+ amplification) pushes small botnets to those volumes. Protocol floods exhaust connection state — SYN floods fill the conntrack table so legitimate players can’t connect. Application-layer floods abuse the game itself: mass connection attempts, Steam query spam, and join floods that make the sim thread spend all its time accepting and dropping connections. Knowing which one you’re under matters because the countermeasures differ.

Attack type	Target	Typical volume	Host-level fix
UDP reflection flood	Game port (UDP)	5–100+ Gbps	Needs upstream filtering
SYN flood	TCP game/query ports	1–10 Mpps	SYN cookies, conntrack limits
Query/join flood	Steam query, game port	10–100k pps	Per-IP rate limits, query throttling
TCP connection flood	All open TCP ports	100k–1M conns	Connection limits, timeouts

Layer 1: upstream filtering

No amount of host tuning stops a 50 Gbps UDP flood — it saturates the physical port before your firewall sees a byte. That’s why provider-level protection is non-negotiable for a public game server. The two models: on-demand (null-route the IP, re-announce it through a scrubbing center, usually 5–15 minutes of downtime) and always-on (all traffic passes through filtering, adding 1–10 ms latency but zero downtime). Always-on is the right call for competitive or community servers where 15 minutes of downtime is a wipe-day disaster; the latency cost is invisible for players since game traffic tolerates tens of milliseconds. Ask for the scrubbing capacity in Tbps — a provider advertising 2 Tbps of network-wide filtering is a different tier than one renting a 40 Gbps pipe.

Layer 2: rate limits at the host

Rate limiting stops the protocol floods that upstream filters often pass through. On Linux, nftables’ hashlimit drops per-IP packet rates above a threshold — the standard pattern is a generous limit for normal players and a hard cap for everything else:

# Allow 50 pps per IP on the game port (e.g. Rust 28015/UDP),
# then drop the rest — stops query floods and join spam
nft add table inet game
nft add chain inet game input { type filter hook input priority 0 \; }
nft add rule inet game input udp dport 28015 \
  ct state new limit rate 50/second burst 100 accept
nft add rule inet game input udp dport 28015 drop

# SYN flood protection on TCP query ports (Minecraft 25565)
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096

Two caveats. First, per-IP rate limits don’t stop distributed floods — 1,000 bots at 30 pps each sail under any per-IP threshold, which is why game servers on the public internet still need the upstream layer. Second, tune the burst above your real peak: a 100-player Rust server sees bursts well above its average, and an over-tight limit kicks out legitimate players during raids.

Layer 3: game-aware hardening

Host-level rules that generic firewalls miss: close everything except the game’s ports (Minecraft 25565/TCP, Source games 27015/UDP+TCP, ARK and Terraria 7777/UDP, Rust 28015/UDP, Palworld 8211/UDP, Valheim 2456–2457/UDP, 7 Days to Die 26900–26903/UDP, Enshrouded 15636–15639/UDP) — every open TCP service is another reflection or connection-flood surface. Rate-limit Steam query responses (some servers ship with unlimited query replies; a single spoofed query then bounces 10x the traffic at players). Enable net.ipv4.tcp_syncookies, cap conntrack entries, and set aggressive timeouts for half-open connections. Finally, keep RCON and web panels off public IPs or behind a VPN — credential-guessing botnets targeting RCON (Rust 28016/TCP, Source 27015) are a chronic, self-inflicted entry point that no DDoS filter can fix.

Building the defense stack

A realistic stack for a public community server: always-on or high-capacity on-demand scrubbing from the provider (layer 1), nftables per-IP rate limits plus SYN cookies on the host (layer 2), and a minimal exposed port set with query throttling (layer 3). Test the setup the way an attacker would — spoofed-source UDP floods from a second VPS, a SYN flood with hping3, and a scripted join storm — before launch day. When comparing providers, the questions that matter are scrubbing capacity, always-on versus on-demand latency, and whether filtering covers UDP reflection vectors like NTP and memcached. Our dedicated server hosting comparison lists which plans include DDoS mitigation and at what tier, so you can match protection to how public your server really is. If you want a concrete place to start, InterServer’s dedicated plans include always-on DDoS protection on every box — the baseline every public game server should have.