Stopping DDoS attacks on a small game server

If you run a public game server with any PvP in it, you will eventually be attacked. Not by anybody sophisticated — by a teenager who lost a raid and rented an hour of traffic for the price of a sandwich. The good news is that this class of attack is genuinely solvable. The bad news is that most owners buy the wrong thing first.

Know which attack you are actually facing

Three very different problems get called "DDoS" in Discord:

1. Volumetric flooding. Enough junk traffic to saturate your uplink. Your server is fine; the pipe to it is full. Nothing you configure on the box will help.
2. Application or query floods. Thousands of status queries or malformed join packets a second. Cheap to send, expensive to answer, and it will pin one CPU core and stall your tick loop.
3. Someone abusing your own game logic. Spawning entities, spamming a script, joining and leaving in a loop. This is not a network attack at all and mitigation will not touch it.

Diagnosing which one you have takes five minutes and saves you from paying for the wrong fix for a year. If the host's graph shows your inbound bandwidth pegged, it is the first. If bandwidth is normal but tick time exploded, it is the second or third.

What actually works

Never expose the real IP

This is the whole game. Almost every small-server attack starts with somebody reading your address off a listing, a status site or an old forum post and pointing a booter at it.

• Put the game behind a filtered IP or a proxy from your host, and give out only that address.
• Change the origin address after you migrate. An old address that still routes is an open door.
• Do not run your website, Discord bot or Teamspeak on the same machine or the same address as the game.

If your host offers filtered game IPs as an upgrade, that is the line item worth paying for. Almost everything else on the mitigation menu is optional for a community server.

Rate-limit the query port

Status queries are how listings see you, and also the cheapest thing to flood. A rate limit of a few requests per source per second keeps every legitimate lister happy and drops a flood on the floor. Set it too tight and you will show as offline everywhere, which is its own expensive problem.

Cap connections per address

Most game servers or their plugin ecosystems can limit simultaneous connections and join attempts from a single address. Join-flood protection is boring, free, and stops the second category of attack outright.

Keep the panel and SSH off the public internet

Key-only SSH on a non-standard port, a firewall that allows your own addresses, and no web panel exposed to the world. An attack that becomes an intrusion is a different order of disaster.

A community server does not need enterprise mitigation. It needs a hidden origin, a rate-limited query port and an owner who does not paste the raw IP into a support thread.

What is usually a waste of money

• Upgrading the box. More cores do not help when the uplink is full.
• Generic web WAF products. They protect HTTP. Your game traffic is UDP and they never see it.
• Paying the attacker. People do try this. It buys a week and a reputation as someone who pays.
• Moving hosts repeatedly. If you carry the same publicly known address pattern with you, you carry the problem too. The cost side of this is covered in the hosting costs breakdown.

Have a plan for the hour it happens

Write this down before you need it:

1. Confirm the type. Bandwidth graph first, then tick time.
2. Tell your players in Discord within five minutes. Silence looks like incompetence; a one-line update looks like control.
3. Do not restart repeatedly. It rarely helps and it destroys any chance of reading what happened.
4. Collect evidence. Timestamps, source counts, and who lost what in-game just beforehand. Small-server attacks are usually personal and the motive is normally visible in your own logs.
5. Escalate to the host with that evidence rather than with "we are being ddosed".

The uncomfortable social half

For a community server, the network fix is the easy part. Most repeat attacks come from someone who was banned, out-raided or removed from staff. The durable fix is a moderation process that does not humiliate people on the way out, and a rule that nobody in the community shares the origin address, ever — including the staff channel.

Fix the origin exposure, rate-limit the query port, write the incident plan, and the rest of your energy can go back into the server itself. If you are still choosing a host, ask in the Discords of the communities in your game that have been running for years — hosting is not something a directory can tell you, including this one, because nobody publishes it as a field. What they will tell you, consistently, is that the filtered IP was the line item that mattered.