FiveM Anti-DDoS: DDoS Protection for Your GTA RP Server

The word you will see in GTA RP Discords is booter — sometimes stresser, or IP stresser. Three names for the same thing: a DDoS-on-demand service, sold by subscription, with a web interface, a field for the address, a field for the duration, and a button. Nothing to install, nothing to understand.

That is what explains the attacker profile on FiveM: these are almost never people who know what a UDP packet is. "Getting DDoSed" on a GTA RP server, in the overwhelming majority of cases, means being targeted by someone who paid a few euros and pasted an address into a form. The practical conclusion is reassuring and alarming at once: the attack is dumb, but it is within reach of any banned player.

FiveM carries game traffic over ENet, on top of UDP. UDP establishes no connection: there is no handshake to complete before your server starts processing a packet. The attacker therefore has nothing to prove, nothing to complete, and does not even need to receive a reply — the source address can be spoofed end to end.

That is the structural difference from a website. An HTTP request arrives at the end of a TCP handshake, which gives you a point at which someone can be refused before you do work for them. On port 30120, that point does not exist.

An attacker with 100 Mbps does not send you 100 Mbps. They send small requests, with your IP spoofed as the source, to misconfigured services that answer much larger than they were asked: open DNS resolvers, NTP servers, Memcached, SSDP. Every reply lands on you.

Amplification factors run from 30× to over 50,000× depending on the protocol. That is why a multi-gigabit flood costs about as much as a streaming subscription, and why "having a good machine" protects nothing: the machine was never the limiting factor, the link is.

The base case: a very large volume of UDP packets aimed at your IP, making no attempt to resemble anything. It is crude and it works, because all it has to do is exceed your uplink capacity. A server on a 1 Gbps line goes down under 1 Gbps of attack, no matter how well configured it is.

This is handled upstream, on a network with the capacity to swallow it — never on the attacked machine, which by definition cannot receive less than what its link accepts.

The interesting one, and the one almost nobody filters. Once raw volume is absorbed, a serious attacker stops sending junk and starts sending technically valid traffic: thousands of well-formed FiveM connection attempts per second.

To a generic L4 tunnel, each of those looks like a player. So it gets forwarded, and your FXServer does the work of refusing it: parsing the handshake, checking the cfx.re ticket, queueing, allocating, then rejecting. The link is no longer saturated — the server’s CPU is, and your real players can no longer get in. The symptom is different ("the server is up but nobody can join"), the cause is the same.

Every player who joins downloads your resources. On a well-stocked RP server that routinely runs from several hundred megabytes into the gigabytes. An attacker only has to request your heaviest files in a loop, from a few hundred addresses, to saturate your outbound bandwidth with perfectly legitimate requests.

There is nothing malformed to detect here: it is exactly what a real player does, only more often. This is not fixed with a filter but with a cache that serves those files from somewhere other than your machine.

On that same port 30120, FiveM answers two families of request that have nothing to do with gameplay. Over UDP, out-of-band queries inherited from Quake — getinfo and getstatus — which the in-game server browser and listing sites use to show your name, map and player count. Over HTTP, on the same port number, the /info.json, /players.json and /dynamic.json endpoints, which expose the same thing as JSON.

Each one fits in a single packet or a tiny request, and makes FXServer assemble a full reply. So an attacker only has to repeat it a few thousand times a second to occupy the main thread, without ever attempting to connect. The link is not saturated, bandwidth barely moves, and the server still stops answering: it drops out of the server list while it is still running, and players trying to join sit on "Failed to get info from server (tried 3 times)" — the client asks for that information before it finishes connecting.

/players.json has a second, permanent effect: it lists your connected players to anyone who asks. That is how someone knows when your server is full, and therefore when an attack will do the most damage.

txAdmin listens on TCP, by default on port 40120, on the same machine as the game. It is one more exposed HTTP server, and it benefits from none of the settings you may have applied to the game port.

A SYN flood fills its half-open connection table without ever completing a single handshake: the panel goes unreachable long before the game port moves. It is the least spectacular attack and the most effective, because it removes the tool you would have used to react. Most owners only notice at the moment they open the panel to find out what is going on.

Moving the port — txAdminPort, or the environment variable that replaced it — moves the target without removing it: a port scan finds it again in seconds.

The reference still describes it as hiding player IP addresses from the public reports the server outputs — player addresses, not yours. On current FXServer builds it no longer does even that: the convar was removed, the behaviour became unconditional, and leaving it in the config makes the server print a startup message asking you to take it out.

It does not hide your machine’s IP and it does not drop a single packet. This is the most common confusion on the subject: the name suggests origin masking, the behaviour has nothing to do with it.

sv_requestParanoia runs from 0 to 3 and only concerns HTTP requests reaching the server. At level 1 it blocks addresses whose requests carry a Via header; at level 2, those carrying Upgrade-Insecure-Requests; at level 3 it also closes the socket the requests came in on. It is designed against proxy-relayed HTTP floods.

Two limits worth knowing. It reasons about headers, so an attacker who does not send them is unaffected. And it does not see UDP: neither game traffic nor the getinfo queries on port 30120 go through that path. Set it to 3, and do not count on it against a volumetric flood.

sv_forceIndirectListing true stops the server being advertised with its real IP address: this is the setting that matters as soon as you sit behind a proxy. It works together with sv_endpoints, which declares the actual endpoint or the proxies, and where needed with sv_listingHostOverride / sv_listingIpOverride, which override the hostname and IP sent to the master server.

sv_proxyIPRanges declares the networks, in CIDR notation, from which the X-Real-IP header is accepted and the rate limiter bypassed — in other words, your proxies. By default it lists only private ranges (10.0.0.0/8, 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12); not adjusting it makes FXServer see the proxy address instead of the player’s, which breaks your IP bans before it breaks anything else.

Together these keep your IP from being published. They do not erase it from an old DNS record, from a website hosted on the same machine, or from a resource calling a hardcoded address.

sv_authMinTrust runs from 1 to 5 and expresses how hard a client identity is to spoof: raising the level turns away the least trustworthy identities. sv_maxClients caps the number of players (1 to 2048), and therefore the size of the queue.

Both are decided inside FXServer, once the attempt has been received and processed. That is useful against bots that actually join; it does nothing against ten thousand attempts per second, because the cost you wanted to avoid — receiving, decoding, verifying — has already been paid by the time the decision is made.

Cloudflare protects HTTP. FiveM game traffic is not HTTP — it is UDP on port 30120, which the standard Cloudflare proxy never sees. Putting your domain behind Cloudflare protects the community website and does precisely nothing for the game server.

Worse, it creates false confidence, and it almost always leaves the real IP exposed somewhere: a forgotten subdomain, a DNS record still in the clear, an old A record. The attacker only needs one.

There is one exception better known than argued at you: Cloudflare Spectrum is a Layer 4 proxy that does relay TCP and UDP and does mask the origin. Two caveats. Cloudflare’s documentation states that custom TCP/UDP applications — which port 30120 is — require an Enterprise plan with Spectrum as a paid add-on, which is not the order of magnitude of a community server. And Spectrum remains a generic tunnel: it does not verify the cfx.re handshake, so it forwards a well-formed fake connection exactly as any other L4 tunnel would. It covers the first of the three jobs, not the second.

It exists, it is real, and it is generic. It is tuned to protect an entire network against large attacks, not to understand one game’s protocol. In practice it does stop the volumetric flood, and it sees no difference whatsoever between a player joining and ten thousand fake connections per second. The exception is a host that adds a game-aware layer on top, such as OVHcloud’s Game firewall, which lists a FiveM profile on its recent Game servers (2024 and later); OVHcloud’s documentation does not say what that profile checks.

It also has an unpleasant failure mode: when mitigation kicks in, it often filters coarsely enough to degrade the game for players who are already connected. Staying online at 400 ms with rubber-banding is not very different from being offline, as far as players are concerned.

Filtering on the attacked machine is too late by construction: the packets have already crossed the saturated link to reach the rule that drops them. You save application CPU; you do not recover bandwidth.

As for Lua resources sold as "anti-DDoS" on marketplaces: they run inside FXServer, so after the packet has been received, decoded and processed. They can rate-limit application abuse. They cannot, by definition, stop a network attack.

This works for about a day. Your players need the address to connect, so the attacker learns it the same way they do — the server list, a friend, a throwaway account. Without permanent origin masking, changing IP is a delay, not a fix.

Volumetric traffic is handled where the capacity exists, ahead of your link. What matters is not only the Tbps figure but where the packet is dropped. Filtering in userspace means an attack packet costs a kernel wake-up, a memory copy and a context switch — which makes the mitigation itself a target.

fiveshield filters in XDP, that is, inside the Linux kernel’s network driver, before the sk_buff is even allocated. A packet dropped there costs almost nothing to drop, which is the only reason mitigation throughput holds under real load.

This is the part a generic proxy cannot offer, because offering it means implementing the FiveM protocol. Telling a real player apart from a fake connection means verifying the cfx.re handshake itself — the ticket, the sequence, the consistency between what is announced and what follows.

That Layer 7 filter is the difference between "the server is online" and "players can actually join" during an attack.

Filtering is defensive; origin masking is what ends the cycle. If your players only ever resolve a proxy address and never learn your machine’s real IP, the attacker has nothing left to aim at except infrastructure built to be aimed at.

It is also the piece owners most often undo without noticing: an unproxied website on the same machine, an old DNS record, a resource calling a hardcoded address. Any one of the three makes the rest pointless. The first thing to look at is what the cfx.re listing already publishes about your server — that is what an attacker reads first.

Every proxy adds a hop, and the hop is where voice chat degrades. Mumble and PMA-Voice are unforgiving about jitter in a way game traffic is not: a mitigation path tuned only for throughput produces a server that stays online and sounds broken.

That is a selection criterion, not a detail. A protected server where voice stutters is a server players leave without ever saying why.

Six in Europe, three in North America, one in Asia and one in Oceania. You pick one in the dashboard when you add your server — ideally the one nearest the machine.

North America: Beauharnois (BHS5), Virginia (US-EAST-VA-1), Oregon (US-WEST-OR-1).

Europe: Frankfurt (DE1), Gravelines (GRA9), Roubaix (RBX-A), Strasbourg (SBG5), London (UK1), Warsaw (WAW1).

Asia: Singapore (SGP1). Oceania: Sydney (SYD1).

Our proxies run on OVHcloud, whose 17 Tbps anti-DDoS network absorbs the raw volume upstream of them. On the 11 proxy locations themselves, filtering happens in XDP, in the kernel, with per-port counters and limiters: one client under attack does not consume another’s capacity.

On every proxy instance the XDP program is attached to the network interface and runs on each packet as soon as the driver receives it. Per-source rate limits and SYN-flood protection apply at that point, and only traffic from the players assigned to that instance, on your server’s active ports, is passed on to the nftables rules behind it, which handle connection tracking. Everything else is dropped before the kernel has committed anything to it, and that is where the per-core gap in the figure below comes from.

Every connection is verified against the FiveM protocol before being forwarded to your server. An attempt that does not correctly complete the handshake never reaches FXServer — which is exactly what a generic tunnel lacks.

Players are not all routed through the same address. Each connection is assigned a proxy instance, which means a compromised or attacked address neither exposes nor blocks your whole population — it affects the players who were on it, and they get reassigned.

Your resource files are served from cache, not from your machine. That removes the third attack vector (the download flood) and, incidentally, cuts your players’ initial load time substantially — the same mechanism fixes both.

The admin interface goes through the same protection as the game. You keep control during an attack, which is precisely when you need it.

fiveshield does not replace your hosting, it sits in front of it. The server stays on the machine and with the provider you have today, your panel stays yours, and your hosting contract is unaffected. The only change on the server side is a configuration block in server.cfg.

So there is nothing to migrate, no DNS record to move and no resource to install. That is what makes setup possible during an attack, where a migration is not.

Restarting FXServer or the machine achieves nothing: the attack is upstream, and all you lose is the current session. Announcing a new address in your Discord is worse — the attacker is in there, and that is often where they got the first one.

Low CPU and RAM, a live FXServer process, and every player dropping at once: that is the network, not the server. Ordinary lag makes something go up — CPU, tick time, memory; a network attack makes nothing go up at all.

Two useful variants. A server that vanishes from the list while it is still running, or players stuck on "Failed to get info from server (tried 3 times)", points at a query flood rather than a volumetric one. A txAdmin you cannot reach while the game still answers points at port 40120.

That is the only action that changes anything durably, and the order matters. Putting a proxy in front of a server whose address is already known does not empty your link: the attacker keeps hitting where they were hitting. The sequence that works is: put the proxy in place, ask your host for a new IP, publish it nowhere, and let only the proxy address out.

Setup fits in five minutes — one block pasted into server.cfg and a restart — because there is no DNS change and no migration to wait on. That is precisely why it is doable during the attack.