FiveM Server Under DDoS Attack? What to Do Right Now
Is your FiveM server being DDoSed? Confirm the attack first, then follow a step-by-step response to get players back online and stop it happening again.
Roby Einstein
FairShieldAC Security Team
If your FiveM server is under DDoS attack right now, start here: confirm the traffic spike outside FXServer - on your host's network graph, not the game console - then open a ticket with your provider and ask whether filtering is engaged or your IP has already been null-routed. A volumetric DDoS flood saturates the link upstream of your machine, so nothing you edit in server.cfg while it is landing will clear it. Below is the order we work a FiveM DDoS incident in.
Step 1: Is Your FiveM Server Actually Under DDoS Attack?
Server hitches alone are not evidence of an attack. A pattern we run into regularly is an owner fighting a DDoS that turns out to be a runaway resource. The most useful discriminator is: did inbound traffic rise? Measure it outside the FXServer process - at the NIC, or on your provider's graph. Volumetric and protocol floods show up as a rise in inbound packet rate or bandwidth. A low-rate application-layer flood may not move bandwidth much, so also check request rates against the JSON endpoints. A broken script stalls with no inbound anomaly at all; if anything it raises outbound traffic as event storms go out to clients.
| What you are seeing | Most likely cause | How to confirm |
|---|---|---|
| Inbound packets or bandwidth spike at the NIC and at the provider; players time out at connect; CPU stays low | Volumetric L3/L4 flood | Provider traffic graph shows the spike; your CPU is not the bottleneck |
| Dark from every network, ICMP dead, provider graph shows traffic stopping at the edge | Your IP has been null-routed by the host | Attack traffic vanishes from your own NIC entirely - that is the giveaway |
| Console prints thread hitch warnings, one resource dominates CPU, no inbound rise | Bad script or resource | Run profiler record from the server console, not client F8 |
| Gradual degradation over hours, clean again after a restart, no traffic anomaly | Memory, entity or handle leak | Correlates with uptime, not with traffic |
| Everything stalls in lockstep, including unrelated resources, while CPU stays low | Database or blocking I/O stall | Slow query log; the hitches line up with DB calls |
| Player count normal but new connections refused; info.json and players.json hammered | Application-layer (L7) flood | HTTP request rate against the JSON endpoints on your game port |
What To Do When Your FiveM Server Is Being DDoSed, In Order
Do not skip the first item because it feels like lost time. Every minute you spend tuning convars during a volumetric flood is a minute your host is not working the ticket.
- 1. Confirm it is an attack before touching anything. Check inbound traffic at the NIC and on the provider dashboard. If inbound is flat, you have a server-side fault.
- 2. Check whether you have already been null-routed. If attack traffic vanished from your NIC but you are unreachable everywhere, your host blackholed the address and nothing server-side helps until it lifts.
- 3. Open a host ticket immediately with timestamps, the destination IP and port, and the traffic graph. Your provider sits upstream of the saturated link. You do not.
- 4. Read the provider's mitigation state. OVHcloud's Network Security Dashboard, for example, shows a scrubbing centre log with detection time, targeted IP and attack vector, and flags mitigation Automatic or Forced.
- 5. Preserve evidence before restarting anything - traffic graphs, console output, connection logs.
- 6. If the signature is application layer, check that your rate limiters have not been loosened, and consider sv_requestParanoia knowing what it breaks.
- 7. Post in Discord. It costs nothing and stops your player base hammering reconnect in a loop.
- 8. Only then consider an IP change or proxy migration - and only with a plan that closes the path by which your origin gets rediscovered.
Scrubbed Or Null-Routed? That Answer Shapes Your Next Hour
Under scrubbing you still receive traffic, filtered; OVHcloud's traffic chart shows dropped malicious traffic in red and delivered clean traffic in green. Under a null-route the traffic stops at the provider edge and you are dark everywhere. Blackholing is normal industry practice - it protects the provider's other customers - but it also means there is nothing left for you to tune.
What Does Not Work, And What Makes It Worse
This is where a lot of FiveM community advice falls apart. Each of these is repeated confidently, and each costs you time you do not have.
| Common advice | Why it fails |
|---|---|
| Put Cloudflare in front of it | The standard proxy carries HTTP and HTTPS. FiveM game traffic is UDP and is not proxied by it. Cloudflare Spectrum is a separate paid L4 product - do not conflate the two. |
| Just add iptables rules | Host-level filtering runs after packets have crossed your link into the kernel. It cannot un-saturate a saturated uplink, and it burns CPU while you are already struggling. Useful for small L7 floods only. |
| Change the game port | Obscurity fails. Your connect endpoint is published to the server list, which is how players find you. |
| Collect the attacker IPs and ban them | Volumetric sources are spoofed or botnet-distributed. In practice you are as likely to ban your own players. |
| Restart or reinstall the server | Changes nothing about inbound traffic and destroys the diagnostic state your host ticket depends on. |
| Raise net_tcpConnLimit to 65535 | Often repeated as hardening. It is the opposite - it widens your TCP concurrency surface. The documented default is 16. |
| Fail2Ban will handle it | Reactive log parsing is far too slow for a volumetric flood, and it does not apply if you host on Windows. |
Volumetric, Protocol, Application: Knowing What Hit You
The joint CISA, FBI and MS-ISAC guidance splits denial-of-service attacks three ways: volumetric attacks that consume available bandwidth, protocol attacks that exploit weaknesses in network protocols, and application attacks that target a specific running service. Only the third can be meaningfully influenced from inside your server. UDP is connectionless - there is no handshake to refuse, and your machine must receive and inspect a packet before it can drop it. When the bottleneck is your upstream link, host-side filtering cannot fix it.
FiveM's Application Layer Sits On The Same Port As The Game
A default FXServer binds endpoint_add_tcp and endpoint_add_udp on port 30120, and that same TCP endpoint also serves unauthenticated JSON: info.json, dynamic.json and players.json. Those responses are cheap to request and comparatively expensive to produce. There is no separate web tier here to shield.
CFX already ships defences for this: token-bucket rate limiters, set as rateLimiter_NAME_rate and rateLimiter_NAME_burst, where rate is tokens replenished per second and burst is the maximum token count. The documented defaults are conservative. A common self-inflicted wound we see is an owner loosening a limiter while chasing an unrelated bug months earlier and never restoring it.
| Rate limiter | Default rate per second | Default burst |
|---|---|---|
| challenge | 4 | 10 |
| handshake | 4 | 10 |
| handshakeUDP | 1 | 5 |
| http_info | 4 | 10 |
| http_players | 4 | 10 |
| http_dynamic | 4 | 10 |
| netEvent | 50 | 200 |
| netEventFlood | 75 | 300 |
The other documented control is sv_requestParanoia, an integer from 0 to 3, default 0. Level 1 blocks IPs sending a Via header; level 2 blocks IPs sending an Upgrade-Insecure-Requests header - which the docs note covers browser-based attempts to reach the .json endpoints; level 3 also closes the socket. That is a real trade-off, not a free win - anything that requests those endpoints the way a browser does can be blocked, so test your own status page and monitors against it before leaving it on. The docs say to use it with care, and they are right.
One nuance: the netEvent and stateBag limiters exist because an already-connected client can abuse them - a different threat model from an external flood. That is where FairShieldAC's encrypted, shuffled event triggers help; a client that cannot guess your trigger names cannot spoof server events.
The IP Problem: Why Changing Your IP Rarely Holds
Here is the part almost nobody gets right. sv_forceIndirectListing defaults to false, so an out-of-the-box FXServer advertises its real IP address to the server list. Rotate to a fresh IP without changing that and you have simply published the new one. Public tools resolve a Cfx.re join code back to an address, so rediscovery is a lookup, not an attack.
The supported fix is CFX's own proxy setup: a connect proxy handling HTTPS on 443 in front of your TCP endpoint, a raw TCP/UDP proxy on matching ports, sv_forceIndirectListing enabled, and sv_endpoints set explicitly - when it is empty, the auto-detected public IP is used. Then firewall the origin so it only answers the proxy. On the CFX forums, an owner whose real IP kept leaking behind a stack of load balancers was corrected by CFX's nta: "Host override is not for setting an IP! IP override is also not for setting an IP for clients!" Those convars do not do what their names suggest.
So the honest answer to "should I change my IP?" is conditional: rotate only after upstream mitigation is live, do it exactly once, and never let the origin be advertised again.
Why FiveM Attacks So Often Follow A Ban Wave
The timing is often not random. One trigger we see is retaliation after a ban wave - a cheat group loses a batch of accounts, and the server is unreachable shortly after. That is not a reason to stop banning; it is a reason to expect the response and have your host contact ready before the wave. If you are unsure whether cheating is feeding the cycle, start with the five warning signs a cheater is on your server, then screen at the door - FairShieldAC checks every connecting player against a global HWID ban network, as covered in our three layers of protection.
Questions Owners Ask Mid-Incident
Should I restart my FiveM server during a DDoS attack?
No. A restart does nothing to inbound traffic, because the flood targets your address, not your process. It drops the players still hanging on and wipes the console output and connection state your host ticket depends on.
Can Cloudflare stop a DDoS attack on my FiveM server?
Not the standard proxy. It carries HTTP and HTTPS; FiveM game traffic is UDP and never passes through it. Cloudflare protects your website, not your game endpoint. Cloudflare Spectrum is a separate paid L4 product, and it is the part of the Cloudflare line-up that is actually relevant to a game port.
Why did my server disappear from the FiveM server list?
Delisting is a symptom, not a second problem. Your listing depends on traffic getting through in both directions - your server's heartbeat out to the Cfx.re ingress, and the server list backend querying your endpoint. When a flood saturates your link that exchange fails and you drop off. It returns once traffic is filtered.
Can I find out who DDoSed my server?
Realistically, no. Attack traffic is botnet-sourced and frequently spoofed, so the source addresses in your logs are not attribution. The most reliable real-world signal is timing: what happened on your server in the hours before it started.
Hardening So It Does Not Happen Again
- Restore any rate limiter you loosened while debugging, and record the defaults before you change them again.
- Decide consciously about sv_requestParanoia. If you run a public status page or a player-count bot, test it against level 2 or 3 before you leave it on.
- Lock down txAdmin. It ships with FXServer and its HTTP server defaults to 0.0.0.0 on port 40120 - every interface, not localhost. Put it behind a VPN, an SSH tunnel, or an IP allowlist.
- Enable sv_endpointPrivacy so player IP addresses stay out of your server's public reports.
- Do the proxy work properly, once, following the official CFX proxy setup guide.
- Get filtering upstream of your link, so the opening minutes of the next attack are absorbed before they reach your box.
That last point is the one you cannot build yourself, and it is where FairShield Gravity fits: an always-on mitigation layer at the edge that absorbs volumetric and application-layer traffic upstream, before it reaches your box. The honest limits - it does not replace competent hosting, it will not fix a resource leak or a blocking database call, and no mitigation layer is absolute. What changes is that the response happens upstream, rather than being your decision at 2am in a Discord call.
Once the incident is over, keep the order honest: prove the cause, close the exposure, then add the layer you cannot run yourself. We broke down how the edge layer works in our guide to FiveM DDoS protection, and you can see what each of our plans covers. Right now, though, take the first step: measure inbound traffic outside the game.