What DDoS Protection Actually Buys You

Nothing you configure on the machine stops a denial-of-service attack. That is the first thing to understand, and it is the opposite of what most advice implies.

If somebody is sending more traffic at your address than your uplink can carry, the traffic has already arrived by the time your server sees it. The link is saturated. A firewall rule dropping the packets is a rule executed after the damage, on a machine that cannot answer legitimate players because the pipe is full.

Everything useful happens upstream of you.

What is being sold

"DDoS protection included" means a provider is filtering traffic before it reaches your machine, and the details vary enormously.

Volumetric filtering is the baseline. The network absorbs a flood and drops obvious garbage. This handles the common case, which is somebody paying a few dollars to a booter service to knock a Minecraft server offline.

Protocol filtering understands the shape of legitimate traffic. This is where game-specific protection matters, because a game server's traffic looks nothing like a web server's and generic filtering either passes attacks or drops players.

Application-aware filtering understands your specific game's protocol, and can tell a real Source query from a forged one. This is valuable and rarer than the marketing suggests.

A published capacity figure, in gigabits or packets per second. This is the number that means something and the one most providers do not put on the page.

The questions worth asking a host

Most hosting pages say "DDoS protected" and stop. Four questions get you past that.

At what volume does it stop working? Every provider has a ceiling. Above it they null-route you, which means your address is dropped and your server is offline for the duration. Ask what the ceiling is and what happens above it.

Do you null-route, and for how long? This is the answer that matters most in practice, because a provider whose response to an attack is a two-hour null-route has protection that ends with you being offline. Some do this at surprisingly low thresholds.

Is it always on, or does it engage on detection? Detection-based filtering has a gap at the start of every attack while it decides. For a game server that gap is the round everyone rubber-banded through.

Is it game-aware? Generic filtering frequently breaks query traffic, which means your server plays fine and disappears from every listing at once. That failure is particularly confusing because the server is up and looks down. How game server queries work explains why the query path can fail independently of the game.

What you can control

A short list, and it is worth doing all of it.

Do not publish the machine's real address. If you are behind any kind of proxy or filtered address, the protection is worthless the moment the origin leaks. Origins leak through old DNS records, a status page, a web panel on the same box, a plugin that phones home, and screenshots of a console.

Check what your domain resolved to a year ago. Historical DNS is public, and an A record from before you set up filtering is a permanent hole.

Separate the web from the game. Running your site, your panel and your game server on one address means an attack on any of them takes all of them. Different machines, or at least different addresses.

Rate-limit the query port. Query traffic is small and predictable. A server answering thousands of status requests a second is being used as an amplifier, and capping it protects both you and whoever the reflected traffic is aimed at.

Keep the firewall closed by default. Not because it stops a flood, but because it removes every other service from the attack surface. Game server security basics covers the wider set.

Have somewhere to tell people. A Discord that is not on the affected address, and someone willing to post "we are being attacked, back shortly". Silence during an outage does more damage than the outage.

Why small servers get attacked at all

The usual assumption is that nobody would bother. In practice the attacks on small game servers are almost never sophisticated or targeted in any meaningful sense.

The three common cases are a player who was banned, a rival server, and somebody who bought a week of a booter service and is working through a list. All three are cheap, and cheap is the whole point: the asymmetry is that a few dollars of attack costs you an evening.

That asymmetry is also why the answer is a provider rather than a configuration. You cannot out-engineer a cost difference that large.

The trade against everything else

Protection is a line item, and it competes with the rest of the budget.

A host with strong filtering usually costs more than one without, and the difference on a small server is real money. Weigh it against what an outage costs you: an evening of players who could not connect, a gap in your uptime history, and the arrivals who tried once and did not come back.

For a server nobody has attacked, the honest answer is that baseline filtering is usually enough and the money is better spent on a faster single core or a better region. For a server that has been attacked once, it will be attacked again, and the calculation changes.

What a game server costs and dedicated versus VPS both cover where this sits in the wider budget, and choosing a host covers asking about it properly.

During an attack

Confirm it is an attack. A server that is unreachable is not necessarily under attack; check whether the machine itself is responsive over SSH, and whether the provider's status page says anything. Diagnosing a crash covers ruling out the ordinary causes first.

Do not restart repeatedly. It changes nothing and it destroys the log.

Tell the provider. They can see the traffic and you cannot. Most have a process, and using it is faster than anything you can do from inside the machine.

Tell your players, once. One sentence, somewhere not on the affected address.

Afterwards, find out how they knew where to aim. An attack on an address that should have been hidden means the origin leaked, and finding the leak is worth more than any filtering you add on top.

The realistic summary

Most small servers never need more than what a reasonable host includes. The ones that do need it need it because somebody decided to, and no amount of configuration on the machine changes that.

So the practical version is: pick a host that filters, ask the four questions above rather than reading the marketing, keep the origin address private, and do not spend on protection you have never needed at the expense of things your players feel.

Stopping DDoS attacks on a small game server covers the same ground from the other direction, including what is and is not possible once it has already started.

Where it fits in the budget

For most community servers the honest answer is that baseline filtering from a reasonable host is enough, and the money is better spent elsewhere.

The ordering that makes sense: a fast single core first, because it is what players feel every session; then a route that suits where your community is; then backups you have tested; then protection beyond the baseline.

That last one moves up the list the moment you have been attacked once, because a server that has been hit will be hit again. Until then, paying for capacity you have never needed is money not spent on the things that affect every evening.

What a game server costs covers the whole picture, and choosing a host covers asking the right questions before you commit rather than after.

The one thing worth doing today

Find out what your machine's real address is, and then find out whether it is discoverable.

Check historical DNS for your domain. Check whether your web panel, your status page or any subdomain resolves to the game server's address. Check whether an old forum post has it written down.

If you are behind filtering and the origin is public, you have paid for protection that anybody can bypass, and the fix costs nothing but an afternoon of looking.

What to say to your players

An attack is one of the few outages where the cause is not your fault and the response still is.

Say what is happening, once, in a channel not hosted on the affected address. "We're being attacked, the host is filtering it, back as soon as we can" is the whole message. Do not speculate about who, do not name anybody, and do not promise a time.

Then say when it is over. The absence of that second message is what leaves people assuming the server is still down two days later.

What not to do is treat it as a secret. Communities handle outages fine when they are told; what they do not handle is a server that is unreachable for six hours with nobody saying anything, which is indistinguishable from an owner who has lost interest.