SA:MP DDoS protection

Why SA:MP servers are easy to knock over

SA:MP has been running since 2006 and the servers that survive are roleplay communities with regulars, a Discord and a hierarchy. That is a target with an audience, and the attack produces something the attacker can watch: players time out, the server empties, and someone posts about it.

The technical side helps them. SA:MP carries its traffic over UDP, and UDP has no transport-layer handshake a network device can use to separate a real client from a crafted packet. Something has to understand SA:MP specifically to make that call. Most generic protection does not, which is why a server can sit behind advertised DDoS protection and still lose its players.

What SA:MP DDoS protection filters

Every packet aimed at our range crosses the scrubbing layer before it reaches a customer machine, and on Shield that happens continuously rather than after a trigger. The SA:MP profile validates the traffic going to your server and drops what does not hold up, so spoofed sessions and connection floods stop at the edge instead of arriving and being dealt with on your box.

It runs as an XDP program at that edge. Dropping a packet there costs a roughly fixed amount of work no matter how large the attack gets, and it costs your server nothing, because the packet never arrives.

The query traffic is the part people miss

Your server answers the SA:MP browser so it can appear in the list with a name, a player count and a ping. Those queries are small requests that produce larger replies, which is the shape an attacker wants for reflection: send a query with your address forged as the sender, and your server helps flood someone else. The same mechanism run against you fills the service that answers the browser, and a server nobody can query is functionally a server nobody can find.

The profile covers that traffic alongside the gameplay traffic. Worth knowing, because a lot of advice about protecting a SA:MP server stops at the game port and leaves the part that makes you visible unprotected.

What it will not fix

Nothing at the network layer helps with an application problem. A gamemode that blocks on a database query, a filterscript that leaks memory, or a server that falls over at 300 players will do exactly that with perfect filtering in front of it. Attack traffic and a bad tick feel identical to a player, and it is worth knowing which one you have before buying anything.

Which machine, and where

For a live server, Shield, because the always-on filtering removes the detection window that disconnects everyone at once. The standard VPS line includes reactive mitigation at no surcharge and costs less, which makes it a reasonable development box and a poor home for a server people are on.

Our filtering and our machines are both in the Frankfurt metro, so for European and North African communities the packets are not detoured to another country to be cleaned and sent back. SA:MP populations are concentrated in places that are a long way from Frankfurt, so check where your players actually are before deciding. Latency you add by hosting on the wrong continent is not something mitigation can give back.

A SA:MP server on its own is light enough that the game is rarely what you are buying for. The gamemode runs on a single thread, so clock speed decides how much Pawn you can execute per tick and additional cores do nothing for it.

What actually sets the tier is everything you put beside it. A roleplay server means MariaDB on the same box, and the database wants both memory and the spare cores the gamemode cannot use. Add logs that grow all month and a compiler toolchain if you build plugins locally, and the entry tier stops being enough long before the game does.