DDoS Defense for Game Servers: Filtering, Rate Limits, and Choosing a Host That Protects You

Game servers are among 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 the game server threat landscape. Volumetric floods saturate the port: UDP floods at 10-100 Gbps are routine, and reflected amplification (DNS ~50x, NTP ~556x, memcached up to 10,000x) pushes small botnets to those volumes. Protocol floods exhaust connection state — SYN floods fill the conntrack table so legitimate players cannot connect. Application-layer floods abuse the game itself: mass connection attempts, Steam query spam, and join floods that make the simulation thread spend all its time accepting and dropping connections. Knowing which one you are 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 connections	Connection limits, timeouts

Layer 1: upstream filtering (non-negotiable)

No amount of host tuning stops a 50 Gbps UDP flood — it saturates the physical port before your firewall sees a single byte. That is why provider-level protection is non-negotiable for any 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 disaster. The latency cost is invisible for players — game traffic easily tolerates tens of milliseconds of additional latency. When evaluating providers, ask for the scrubbing capacity in Tbps. A provider advertising 2 Tbps of network-wide filtering is a different tier than one renting a single 40 Gbps pipe. Also ask whether the mitigation handles UDP reflection vectors specifically — NTP amplification, DNS amplification, and memcached reflection are the most common vectors against game servers, and a generic DDoS filter that only handles TCP floods is useless for a game server.

Layer 2: rate limits at the host level

Rate limiting stops the protocol and application floods that upstream filters sometimes miss or pass through. On Linux, nftables hashlimit drops per-IP packet rates above a threshold. Here is a practical configuration for a Rust server on port 28015/UDP:

# Allow 50 pps per IP on the game port, drop the rest
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
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096

Two caveats. First, per-IP rate limits do not 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. Monitor your normal traffic patterns for a week before setting production limits.

Layer 3: game-aware hardening

Host-level rules that generic firewalls miss: close everything except the game’s ports. Every open TCP service is another reflection or connection-flood surface. The standard ports by game:

• Minecraft: 25565/TCP
• Source games (CS2, TF2, Garry’s Mod): 27015/UDP+TCP
• ARK / Terraria: 7777/UDP
• Rust: 28015/UDP (RCON: 28016/TCP)
• Palworld: 8211/UDP
• Valheim: 2456-2457/UDP
• 7 Days to Die: 26900-26903/UDP
• Enshrouded: 15636-15639/UDP

Beyond port lockdown: rate-limit Steam query responses (some servers ship with unlimited query replies, allowing a single spoofed query to bounce 10x the traffic at players). Enable net.ipv4.tcp_syncookies, cap conntrack entries, and set aggressive timeouts for half-open connections. Most critically, keep RCON and web control panels off public IPs or behind a VPN — credential-guessing botnets targeting RCON ports (Rust 28016/TCP, Source 27015) are a chronic, self-inflicted entry point that no DDoS filter can fix.

How to choose a host that protects you

When evaluating dedicated server providers for DDoS protection, ask these specific questions:

• What is the scrubbing capacity? Not “enterprise-grade DDoS protection” — ask for the actual Tbps capacity of their mitigation infrastructure.
• Always-on or on-demand? Always-on adds 1-5 ms latency but means zero downtime during attacks. On-demand takes 5-15 minutes to activate — your server is offline during that window.
• Does the filter handle UDP reflection? Many providers’ DDoS mitigation is optimized for HTTP/HTTPS and handles TCP floods well but passes UDP reflection traffic. Game servers are UDP-first — your filter must handle NTP, DNS, and memcached reflection vectors.
• Is the mitigation per-server or per-network? Some providers offer per-server null-routing, meaning your neighbor’s attack can take your server offline. Network-level scrubbing that protects the entire IP range is far more reliable.

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, 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. Browse the latest dedicated server deals that include the mitigation stack your game server needs to survive its first attack.

Bottom line

DDoS protection for game servers requires three layers: upstream scrubbing for volumetric floods, rate limits for protocol attacks, and game-aware hardening for application-layer abuse. No single layer is sufficient alone. Test your defenses before you need them, and choose a provider that treats DDoS mitigation as a core feature, not an expensive add-on. The best protection is the one you configure before the first attack — not during it.