DDoS Playbook for Game Servers (Friend Servers / Small Public Servers)

Over the holidays I ran a quick defense review of a handful of small game servers for a friend. The conclusion belongs at the top of the playbook: there's no free, perfect magic. The thing small servers fear most is a UDP flood once your real IP gets scanned out. The goal here isn't "never get attacked" — it's "when it happens, you know what to do first, and your money goes where it counts."

The option matrix: pick by player count and how public you are

How to read the matrix: start with "am I serving five friends or five hundred strangers?" Friend play → a VPN dedicated server first. Public community server → talk high-protection budget. Put DDoS defense into the launch budget instead of discovering it as a post-launch surprise. Never let the server IP show up in streams or screenshots; post the domain in group announcements instead of a bare address, and have a switch ready to go.

Exposure reduction you can do today

Separate admin ports from game ports; SSH gets keys-only on a non-standard port or behind VPN. Keep worlds and saves migratable and backed up, so if you get knocked off and move machines you don't lose the save along the way. Firewall only the UDP/TCP you actually need. If you must be public, shorten your DNS TTL, and verify the backup IP or hidden node is reachable ahead of time — don't do your first resolution at disaster time. Some games support invite-only or whitelists: turn those on when you can, that's one fewer random-scan entry point.

Relays and CDNs only help when they match the problem: TCP games can sometimes ride a tunnel, but plenty of multiplayer games run custom UDP where a CDN does nothing. Spectrum-class products are powerful, yet the personal billing usually talks you out of them. High-protection hosting bills by protected bandwidth, and it's for servers that have decided to stay public long-term with real traffic or real demand. IP rotation is a stopgap only: under a targeted attack it gets exhausting, and it breaks player bookmarks and DNS caches.

If the game supports listening on a specific interface, or separates its query port from the game port, split the firewall rules per the docs instead of lazily opening 0–65535. State-sync games can leave some clients stuck half-connected after an IP switch, because old connections linger — so put a line in the playbook: after a switch, players fully quit the client and rejoin.

The order of operations when you're under attack (follow it, don't panic)

1. Confirm it's actually an attack
   Check the datacenter traffic graph, the host NIC, and whether the game is reachable. Don't misread "corrupted save" or "crashed process" as an attack; and don't misread an attack as "one more restart will fix it."

2. Switch to the hidden node / bring up the backup IP
   If the playbook already has a WireGuard dedicated server or backup entry, move your real players there first. Public DNS can temporarily point at a maintenance page or an update notice.

3. Tell players to reconnect or pause
   Say it plainly in the group: how long the downtime is, what the new connection method is, whether saves survived. Information asymmetry blows up the group faster than a short outage does.

4. Decide whether high-protection is worth it
   One-off flood vs. sustained targeting; friend group vs. public recruiting. Do the math on protection cost against the server's expected lifetime — no panic spending.

5. Save evidence and call the datacenter
   Send the traffic graphs, start time, targeted ports, and sampled packet signatures — that goes much further than "we got attacked." Ask about temporary scrubbing and the price and duration of a high-protection IP switch before you commit to it.

Playbook appendix: the checklist for talking to your datacenter

Have ready: machine IP, approximate attack start time, inbound bandwidth peak, game ports and protocol, whether you've already switched IPs, and whether short downtime is acceptable. Some datacenters offer temporary scrubbing — check whether you're back to bare exposure the moment the window ends. If you're going high-protection, confirm your game protocol is on the scrubbing device's compatibility list first; UDP games getting scrubbed into "pings fine, won't play" is not a rare story.

Put the mindset in the footer

Security is sometimes a product decision. VPN for friend-only servers, bought protection for public ones — both are legitimate calls; what isn't legitimate is the fantasy of "public recruiting, zero cost, never down." If you grow from a friend group into a public server mid-season, re-run the matrix — architecture follows the product, it doesn't stick an expired "we're secure" sticker over it.

Walk the playbook every six months: is the backup IP still valid, can backups boot on a new machine, is the group announcement template still around, is the datacenter ticket channel still open. The reason to write this during the holidays is so that the next time the traffic graph spikes red, you've got an order of operations in hand instead of just anxiety. Option matrix at the top, emergency order in the middle, datacenter talking points in the appendix — three pages beat ten post-mortems' worth of "if only I'd known."