A web service spends real effort keeping its origin address secret. An online game sends its server's address to every player in the match, including the one who brought a booter.
That single fact reshapes the whole problem. The attacker is not outside, probing for a way in. They are in the lobby, holding the same IP and port as the other nine players, and they learned it by clicking "find match".
The second fact is just as unusual: a match cannot be retried. A slow checkout can be reloaded. A ranked match that loses its server for twenty seconds is over, for everyone on it, with abandon penalties and lost progress that no recovery afterwards gives back.
What is DDoS testing for gaming?
DDoS testing for gaming is an authorised test of whether live matches, login and matchmaking survive an attack timed and aimed the way gaming attacks are: at the game-server ports players can see, at the platform services everyone shares, and at the hours the studio has announced in advance. The pass mark is the share of matches that finish normally, not whether the servers stayed up.
Approval, ramps and abort criteria work as they would for any production test, and the complete guide to DDoS testing lays them out. This post is about the parts that only games have: the tick, the exposed address, protocols no scrubber has a signature for, and peaks that sit in a press release.
| Surface | What an attack breaks | What to measure |
|---|---|---|
| Game server (UDP) | the tick, then the match | matches completed, per-player loss and jitter |
| Player connections | one player, picked by a rival | which addresses a client can see |
| Login and matchmaking | everyone, after a region drops | entries per second the queue survives |
| Anti-cheat, licence checks | play itself, if a check-in is mandatory | what happens when the check-in fails |
The match is the unit, and it cannot be retried
Most DDoS outcomes are counted in minutes of downtime. A game counts them in matches, and a match fails long before the service looks down.
The tick budget
A game server runs a fixed loop: read every player's input, simulate, send the new state, repeat. Common rates run from about 20 to 128 updates a second, so a 64-tick server has 15.6 milliseconds to finish each pass.
Every packet that reaches the process has to be read before it can be thrown away. A flood of junk on the game port does not need to fill the link; it only needs to push tick processing past its budget. Players see that as rubber-banding and teleporting while the host's CPU graph looks merely busy.
A short gap ends the match
Game clients give up on a silent server after a timeout, often in the range of seconds to tens of seconds depending on the engine and the studio's settings. That number is small next to the time an on-demand mitigation needs to detect a flood and divert traffic.
On a web property, a three-minute diversion window is a bad few minutes. On a game host it is the end of every match running there, because the clients timed out at second twenty and the scrubbing arrived at minute three.
So the posture question is sharper
Whether mitigation should sit permanently in the path or be swung in on detection is a general trade, covered in DDoS protection in the path. For game servers the detection gap is usually longer than a match can survive, which pushes the hosts players connect to toward always-on mitigation. A test should measure that gap against the client timeout, not against an internal target.
Why does a game hand its address to the attacker?
Because a player has to send packets somewhere, and the somewhere is in the matchmaking response.
Three topologies, three exposures
In peer-to-peer and listen-server games, one player's machine hosts the match and every other player learns its home IP. A rival with a booter can knock that player offline mid-match, and no studio control protects a residential connection.
With dedicated servers, players see the server's address instead of each other's. That moves the target onto infrastructure the studio can defend, but every player in every match still learns a server IP and port.
With a relay network, players only see relay addresses, and the game server's own address never leaves the studio's network. Valve's Steam Datagram Relay is a well-documented public example; many studios build or buy the same idea.
What to test
Join a match as an ordinary client and capture the traffic with tcpdump or Wireshark. List every address the client talks to and every address that appears in a payload: voice chat, party systems, spectator streams and replay uploads have leaked server or player addresses on games whose main traffic was relayed.
Then check how long an address stays useful. A server that keeps the same IP for weeks gives a player all the time they need; per-match allocation, short-lived ports and relays shrink that window. The web equivalent of this hunt is in origin IP exposure and CDN bypass, and the instinct carries over: assume anything a client can see will be found.
Game traffic is UDP that generic filters do not understand
Scrubbing for UDP grew up around reflection: DNS, NTP, memcached, CLDAP, each with a well-known source port and a reply size that gives it away. Game traffic has neither.
No signature to match
A game protocol runs on a port the studio chose, with packet sizes that vary by tick and by what is happening in the match. A flood aimed straight at that port, with payloads cut to look like game packets, is plain UDP flood to a generic filter: nothing to fingerprint and no reflector to block.
The blunt fallbacks hurt players. Rate limits per source fall on cafés, dormitories and carriers putting thousands of players behind one address (the same carrier-NAT trap the mobile backend post walks through). Geographic blocks remove whole regions of the player base.
What a game-aware filter checks
Filters that understand a game check whether a packet belongs to a session. A common design has the backend issue a signed, short-lived connect token with the matchmaking response, and the edge drops any first packet that does not carry a valid one. The open-source netcode.io library is built this way, and some hosts sell filters profiled for specific game protocols; OVHcloud is one.
Your own query port is a reflector
Many servers answer a small unauthenticated status query (player count, map name, server rules) on UDP. A short request for a long answer is an amplifier, and game query protocols have been used as reflectors. Valve's server query protocol now answers an info request with a challenge before it sends the full reply, for exactly this reason. Check whether your own query port does the same, from outside, with a spoofing-free test that compares request and reply sizes.
What to test
Send three kinds of traffic at the game port of a test host: random UDP, packets shaped like the game's own, and valid-looking packets replayed from a captured session. Measure, for each, how much reaches the server process and what happens to the tick time. A filter that stops the first and passes the third is doing pattern matching, not session checking.
What does a lost region do to login and matchmaking?
It turns an attack on game servers into a load test of every shared service behind them.
Every player comes back at once
When matches end abruptly, players do not leave. They go back to the menu, re-authenticate or refresh a session, and queue again. If one host drops, that is a few hundred people. If a region drops, it is every player in it, inside the minute their clients give up.
Reconnect herds as a client behaviour, and why jitter fixes them, are covered for WebSocket services and mobile fleets. What gaming adds is where the herd lands: matchmaking, which does real work per entry (skill and latency matching over a pool), and the login path, which often sits on an identity provider with its own rate ceiling.
The arithmetic
In steady state, players enter matchmaking at roughly the number in matches divided by the match length. A hundred thousand players in thirty-minute matches is about 56 entries a second.
Lose one host of two hundred players and the rate barely moves. Lose a region holding thirty thousand, with players back within a minute, and it jumps to about 556 a second, ten times normal. Gate the same players back over ten minutes and it is about 106.
Where the second outage starts
A region outage that floods the shared login and matchmaking services reaches players in regions the attacker never touched. That is the finding worth testing for: drop a test region's hosts on purpose and measure what happens to login latency and queue times everywhere else.
A login queue is the honest control here. Admitting players at a rate the services behind it can carry, with a position and a wait time on screen, turns a second outage into a wait.
Launches, patches and tournaments: peaks you announce
Gaming attackers rarely need to guess when to strike. The studio publishes the date.
The attack sits on top of the busiest hour
Launch day, a season reset, a big patch and a live event all concentrate legitimate players into the same window, and that is when attacks arrive. Lizard Squad's Christmas Day 2014 attacks on PlayStation Network and Xbox Live hit the day new consoles came out of their boxes. The Mirai botnet's authors started out attacking rival Minecraft servers before it took down much larger targets.
A test at average load proves little. It has to run with the event's own concurrency underneath it, which usually means headless bot clients standing in for players.
The event configuration is new
Event days often bring new things: a new build, a new region, temporary capacity, tournament servers with fixed addresses, a new spectator or broadcast path. Each one is untested by definition. Test the event setup as it will run on the day, a week or two ahead, not the everyday setup it replaces.
Tournaments narrow the target to a person
An online tournament is a published schedule of exactly when one team's connection matters. If any competitor plays from home on a path that exposes their address, a single booter can decide the match. Organisers' answers are architectural: relayed traffic, tournament clients that never reveal peers, or bringing players to a venue. The test is the same address capture as above, run on the tournament build.
Anti-cheat and licence checks sit on the play path
Some dependencies look like back-office services and are in fact required for a match to continue.
A mandatory check-in is a single point of failure
Many anti-cheat systems check in with a backend while the game runs, and some games verify a licence or entitlement when a session starts. If a failed check-in ends the session, that backend is as critical as the game server, and usually far less protected.
Find out what the client does when the check-in fails. Waiting and retrying is one answer; disconnecting the player is another, and it hands the attacker a much smaller target than a fleet of game servers.
Classifiers learn the wrong lesson
Behavioural anti-cheat and fraud models are trained on normal play. Under attack, latency spikes and packet loss make honest players move, aim and resend in ways the models have rarely seen. A test is a good time to log what they flag, so an attack does not turn into a wave of false bans.
Where to point a game test, and what to watch
Players notice a test before monitoring does, so where traffic goes matters more than usual.
Aim at a test fleet first
Stand up game hosts in a test region, running the live build, joined only by bot clients and staff. Point the flood there, at the platform services through their production edge, and at the query and voice ports. Tell your host and your mitigation provider before you start; game hosting terms are often strict about unannounced floods.
Running near live players needs ceilings and a kill switch, which testing without disrupting production covers. The gaming addition is a measurable stop rule: abort the moment live matches outside the test fleet start ending early.
Measure what a player feels
Server CPU and bandwidth say little on their own. Record, per bot client: packet loss, jitter, round-trip time, server tick time and whether the match finished. Add the platform view: login latency, queue time and matchmaking entries per second in every region.
The headline number is simple. Out of the matches running when the flood started, how many finished?
Before the next launch: a checklist
- Write down the client timeout and the tick budget, then measure mitigation's detect-and-divert time against them.
- Capture a real match and list every address the client can see, including voice, party and spectator paths.
- Check how long a game-server address stays valid, and whether relays or per-match allocation shorten it.
- Send random, game-shaped and replayed packets at a test host and record what reaches the process and the tick.
- Measure the reply-to-request ratio of your own server query port from outside.
- Drop a test region on purpose and watch login and matchmaking in the others.
- Confirm a login queue exists, admits at a known rate, and is visible to players.
- Find every check-in a match depends on (anti-cheat, licence, entitlement) and fail it deliberately.
- Rehearse the event configuration, not the everyday one, at the event's expected concurrency.
- Agree a stop rule tied to live match completions before any test touches production.
FAQ
Can a game studio protect players from being DDoSed at home?
Not directly; a residential connection is the player's and their provider's. What a studio controls is whether its game reveals the address. Relayed traffic and dedicated servers keep players' IPs out of each other's hands.
Is UDP game traffic harder to protect than web traffic?
It is harder to filter by signature, because game protocols have no well-known port or packet shape and floods can imitate them. Filters that check whether a packet belongs to a session, for example by validating a connect token issued at matchmaking, separate the two far better than rate limits.
Why do games go down on launch day even without an attack?
Because launch concentrates real players into one window, and login, entitlement and matchmaking take the full load at once. An attack on that day lands on top of the peak, which is why tests should run at launch-like concurrency.
What should a gaming DDoS test measure?
The share of matches that finish normally while the flood runs, alongside per-player loss and jitter, server tick time, and login and queue times in every region. Uptime alone misses the failure players see.
Should game servers use on-demand or always-on mitigation?
Measure the gap first. If detection plus diversion takes longer than the client timeout, every match on an attacked host ends before mitigation arrives, and that is a strong argument for keeping player-facing hosts permanently in the path.
Every player is inside the perimeter
Web security was built on a boundary: customers are let in, attackers are kept out, and the work is telling them apart at the door. Games broke that model years ago. The attacker holds a valid account, sits in the same match and receives the same packets as everyone else.
So the durable questions for a game are not about the size of the next flood. They are about what any player can learn, how long it stays true, and how many matches end before anyone at the studio has noticed.