Guide

FiveM DDoS protection: what attacks hit and what stops them

A FiveM server is easy to find and easy to hit: its address is in the server list, in every player's connect history and often in Discord. This guide explains the three kinds of attack that reach FiveM servers, which of them a filtering network stops and which you have to handle yourself, and the settings that close the gaps. Convar names and defaults come from the Cfx.re documentation as it reads in November 2026.

By Evorxa teamPublished

How FiveM servers get attacked

FXServer takes game traffic on one port for both TCP and UDP, 30120 by default, as the endpoint_add_tcp and endpoint_add_udp lines in the example server.cfg show. The same port also serves HTTP endpoints such as /info.json, /players.json and /dynamic.json: a client fetches /info.json before it joins, and the Cfx.re server list polls the server for data such as player counts. txAdmin, the web panel most servers use, listens on 40120 by default. Attacks aim at those surfaces in three ways.

  1. Volumetric UDP floods at 30120 or at the whole IP. The goal is to fill the server's network link. Once the link is full, nothing on the server can help, because the junk arrives before any setting gets a say.
  2. Connection floods: many TCP connections or connection attempts to 30120. They use up connection slots, memory and CPU while the link itself may look calm.
  3. HTTP floods (layer 7): valid-looking requests to the .json endpoints or to the txAdmin login page, often sent through open proxies. Each request is small, but answering thousands of them a second keeps the server busy.

There is a fourth kind of abuse that is not a DDoS but feels like one: a connected client spamming network events or state changes through your resources. It comes through the normal game connection, so no network filter sees it.

What edge filtering does and does not do

DDoS filtering at the network edge means traffic for your IP passes through a scrubbing network before it reaches the server. That network has far more capacity than one server's link, so it can take a volumetric flood, drop packets that do not look like the protocol on that port, and forward the rest.

What it handles well

  • Volumetric UDP and TCP floods that would fill your link.
  • Spoofed and malformed packets, and traffic to ports you do not use.
  • Large numbers of connections from one source, within what the filter can identify.

What it cannot do for you

  • Protect an IP that the attacker reaches by another route, for example a second address of the same server or a proxy that forwards to the origin without filtering.
  • Tell every bot from a real player when the bot speaks the protocol correctly. Some of that load still reaches the server, which is why the server-side limits below exist.
  • Stop abuse from players who are already connected. Event spam and exploits in resources are a scripting problem.
  • Protect services you left open: SSH, a database port, or txAdmin open to the world.

Settings in server.cfg

These lines come from the server commands reference. They cost nothing and make the connection and HTTP floods that get past the edge cheaper to absorb.

server.cfg
# game traffic on one port, TCP and UDP (the defaults)
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# concurrent TCP connections allowed per IP (default 16)
net_tcpConnLimit 16

# block IPs whose HTTP requests carry a 'Via' header
set sv_requestParanoia 1

# hide player IP addresses from public reports
set sv_endpointPrivacy true

# leave RCON off unless you use it
#set rcon_password ""
  • net_tcpConnLimit caps concurrent TCP connections per IP. The default is 16. Lower it only if you know no legitimate players share an address; players behind one router or carrier NAT share an IP.
  • sv_requestParanoia runs from 0 (off, the default) to 3. Level 1 blocks IPs that send a Via header, which proxies add to the requests they forward. Level 2 also blocks requests with an Upgrade-Insecure-Requests header, which includes anyone opening a .json endpoint in a browser. Level 3 also closes the socket. Start at 1.
  • sv_endpointPrivacy true hides player IP addresses from the server's public reports, so your players are not the next target.

Servers on FiveM for GTAV Enhanced also get token-bucket rate limiters for handshakes, the HTTP endpoints, net events, state bags and RCON. Each has a rate (tokens per second) and a burst (maximum tokens); a request with no token left is rate-limited. The defaults include 4 per second with a burst of 10 for http_info and http_players, and 50 per second with a burst of 200 for netEvent. The reference lists these commands as exclusive to the Enhanced build.

server.cfg (Enhanced)
# FiveM for GTAV Enhanced only
# set rateLimiter_<name>_rate  <tokens per second>
# set rateLimiter_<name>_burst <maximum tokens>
set rateLimiter_netEvent_rate 100
set rateLimiter_netEvent_burst 400

Change them only when your console shows a limiter dropping traffic you can identify. Raising netEvent to make a busy resource work also gives a spamming client more room.

Firewall rules on the server

Close everything players do not need. Players need 30120 over TCP and UDP. You need SSH and txAdmin, and nobody else does. On Ubuntu or Debian with ufw, allow your own SSH rule before ufw enable, or you lock yourself out:

shell
# replace 203.0.113.10 with your own public IP
ufw default deny incoming
ufw default allow outgoing
ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw allow 30120/tcp
ufw allow 30120/udp
ufw allow from 203.0.113.10 to any port 40120 proto tcp
ufw enable
ufw status verbose

Do not block the Cfx.re backend. The server list polls your server from the addresses published at static.cfx.re/ips.txt, and Cfx.re says a strict firewall or DDoS filter must allow all of them. New addresses are added at least a month before traffic comes from them, so sync the list on a schedule.

txAdmin's port is 40120 unless you change it with TXHOST_TXA_PORT, and it cannot be 30120, according to the txAdmin environment reference. If your IP changes often, keep 40120 closed entirely and reach the panel through an SSH tunnel:

shell
# open txAdmin through SSH instead of the internet
ssh -L 40120:127.0.0.1:40120 root@your-server-ip
# then browse to http://localhost:40120

On Windows Server, the same rules go into Windows Defender Firewall: allow 30120 TCP and UDP from anywhere, and 3389 and 40120 only from your own address.

Keeping the origin IP hidden

Filtering only works if attack traffic has to pass through it. When the protection sits on the server's own IP, every packet to that IP is filtered and hiding matters less. When you put a separate proxy in front of the server instead, the real address (the origin) must stay secret, because an attacker who knows it can skip the proxy.

The Cfx.re proxy setup guide describes two proxies: an HTTPS proxy for the connect endpoint, and a raw TCP and UDP proxy on matching ports for game traffic. With both in place, these convars stop FXServer from advertising its own address:

server.cfg
# stop the server list from advertising the real IP
set sv_forceIndirectListing true

# the hostname the server list backend should query
set sv_listingHostOverride "play.example.com"

# your proxy addresses in CIDR notation (trusted for X-Real-IP)
set sv_proxyIPRanges "198.51.100.7/32"

# the UDP endpoint players are given: the proxy, not the origin
set sv_endpoints "198.51.100.7:30120"

Players then join with connect "https://play.example.com/"; the guide notes that a bare host such as play.example.com resolves to http://play.example.com:30120/ instead. Then close the usual leaks:

  • Old DNS records. If a domain ever pointed straight at the origin, assume the address is known and change it after the proxy is live.
  • Other services on the same IP: a website, a Discord bot, a database or mail server.
  • Resources that call outside APIs or webhooks. Those requests come from the origin IP and are visible to whoever runs the other end.
  • Direct connect addresses posted in Discord or forums before you moved behind the proxy.

What to ask a host before you buy

  1. Is filtering always on, or does it start after an attack is detected? If it starts later, how long does it take?
  2. Does it cover UDP on game ports, or mainly web traffic? FiveM needs UDP on 30120 filtered without breaking the handshake.
  3. What is the filtering capacity, and what happens above it? Some providers null-route the IP, which takes your server offline until the attack stops.
  4. Is there a firewall in front of the server that you control, per port and protocol?
  5. Can you see when an attack happened and how big it was? Without that you cannot tell an attack from a resource bug.
  6. Are there enough single-thread CPU speed and RAM left for the server itself? Protection does not help a server that is already at its limit.

FiveM on Evorxa

Evorxa servers sit behind Shield, Evorxa's DDoS filtering, with 3 Tbps of scrubbing capacity. Servers run in one region, Eygelshoven in the Netherlands; Shield's CDN edge locations are separate from that server region. The FiveM hosting page lists plans with shared cores (VPS) and dedicated high-frequency cores (VDS), prepaid monthly, for six months or yearly, with full root access for the settings above.

Sources

The facts in this guide come from these pages.

  1. Cfx.re docs: Server commands (convars, rate limiters)
  2. Cfx.re docs: Proxy setup
  3. Cfx.re docs: Static IPs (ips.txt)
  4. Cfx.re: example server.cfg
  5. txAdmin: environment configuration