FiveM DDoS protection: hide the endpoint, filter port 30120

02Why does my FiveM server IP leak?

Because, out of the box, it is published. The server list advertises the real address unless told otherwise, and every player's client sends UDP straight to the server endpoint, so a packet capture reveals it. Hiding it means the address players see must belong to something other than the machine running FXServer.

• Server listing: the real IP is advertised unless sv_forceIndirectListing is set
• Server endpoint: every player can see the UDP address they are connected to
• txAdmin and other panels on the same address
• Old DNS records, websites and Discord bots that print the connect address
• Resources making outbound HTTP requests, which reveal your egress address to whoever runs the URL

03Which FiveM settings hide the server address?

The documented convars that matter for exposure, summarised from Cfx.re's server command and proxy setup pages. Check the current documentation before relying on them; behaviour can change between builds.

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# never advertise the real address; list via the HTTPS connect proxy
set sv_forceIndirectListing true
set sv_listingHostOverride "connect.example.com"

# players' UDP goes to the protected relay, not to this host
set sv_endpoints "192.0.2.20:30120"

# trust X-Real-IP only from the connect proxy
set sv_proxyIPRanges "192.0.2.10/32"

# hide player IPs in public reports (does not hide the server)
sv_endpointPrivacy true

04Connect proxy, relay or tunnel: how to front FXServer

Cfx.re describes two proxy types that can be deployed independently. A connect proxy is an ordinary HTTPS reverse proxy on port 443 in front of the server's TCP port; it carries the listing, /info.json and initConnect, and can cache downloads. A server proxy is a raw TCP and UDP relay on the game port. The third option is a tunnel from a filtering provider that delivers protected addresses to your machine.

05Firewall the real host

Once something else carries the public address, the host should answer only that something. Drop TCP and UDP to 30120 from everyone except your provider or relay, and keep txAdmin reachable only from your own addresses or over SSH or a VPN. The ruleset below was syntax-checked and load-tested in an isolated network namespace: the provider address reached both protocols on 30120, the admin address reached txAdmin only, and everything else was dropped.

• Whichever public address Cfx.re's listing backend polls must accept the addresses in Cfx.re's published list; new entries are added at least a month before they start sending traffic
• If the server log keeps reporting that it could not contact the server browser, check that allowlist before blaming an attack
• Give the host a new address after moving it behind protection if the old one was ever public
• Keep the database, web panel and SSH off the public interface, or firewalled the same way with a default-deny ruleset

#!/usr/sbin/nft -f
# FXServer host: game port only from the protection provider,
# txAdmin only from your own admin addresses.
table inet fivem_host
delete table inet fivem_host

table inet fivem_host {
    set provider4 {
        type ipv4_addr
        flags interval
        elements = { 192.0.2.0/27 }
    }
    set admin4 {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.7 }
    }

    chain input {
        type filter hook input priority filter; policy accept;

        iif "lo" accept
        meta l4proto { tcp, udp } th dport 30120 ip saddr @provider4 accept
        tcp dport 40120 ip saddr @admin4 accept

        meta l4proto { tcp, udp } th dport 30120 counter drop
        tcp dport 40120 counter drop
    }
}

06What UDP filtering must a FiveM provider offer?

The game session itself runs over UDP, so a provider is only useful if legitimate ENet traffic keeps flowing while the flood is dropped (the attack itself is explained in what a UDP flood is). Ask about:

• Filtering, not null-routing: UDP to 30120 keeps passing during a flood
• Session awareness: game traffic from addresses that completed the HTTP connect step can be treated differently from UDP that appears from nowhere
• Reflection traffic dropped upstream: replies from DNS, NTP, memcached and similar services are never FiveM traffic (see amplification attacks)
• TCP protection on the same port against SYN floods and connection floods
• HTTP-level filtering for the connect endpoint, because /info.json and /players.json are public and cheap to flood
• IPv6 either protected or deliberately disabled
• Measured latency from your players' region, and capacity in packets per second as well as gigabits

07How to recognise an attack on a FiveM server

Match the symptom to the layer before reacting, and rule out lag first with the signs of a DDoS on a game server. The matrix below covers the common cases; the commands after it are read-only, and the filters were compiled and the top-talkers count run against a crafted capture.

# game traffic
tcpdump -nni eth0 'udp dst port 30120'

# new TCP connections to the game port
tcpdump -nni eth0 'tcp dst port 30120 and tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

# plain-HTTP GET requests, e.g. a flood on /info.json
tcpdump -nni eth0 -A 'tcp dst port 30120 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

# top 10 UDP sources in a 20,000-packet sample (IPv4)
tcpdump -nni eth0 -c 20000 'udp dst port 30120' 2>/dev/null \
  | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head

08What a proxy or tunnel can and cannot do for FiveM

A proxy or tunnel on a filtering network absorbs floods aimed at the address players know and keeps the host unreachable. That covers most of what people mean by a FiveM DDoS.

It cannot fix problems that arrive as legitimate traffic. A modified client spamming server events or an exploitable script passes through exactly like a real player, because it is a real connection; that needs server-side validation and anticheat. Protection also fails if the host's address leaks through another service, or if the provider null-routes the address once an attack grows.

Your community website, forum or store is a separate target with different needs: a web reverse proxy covers it, while the game needs Layer 3/4 filtering, as explained in Layer 3/4 vs Layer 7. For that web side, GuardX's DDoS protection for websites is available today; GRE transit for game traffic is marked coming soon.