FiveM DDoS traffic spike or host notice: how to confirm it and what to do

Updated

Verified against FXServer build 35245 (recommended), 37150 (latest) and txAdmin v8.1.1, checked on 7 October 2026. Sources

VerdictPoints to a DDoS once confirmed

It points to a DDoS when your host has reported an attack or your inbound graph shows a wall of traffic, but confirm direction, shape and timing before you act.

Protection is the right next step

FiveShield helps once the attack is confirmed: players connect to a proxy and not to your machine, which only works if the origin address changes and stays private.

If your host reported an attack on your IP, or your inbound graph shows a wall of packets that starts and stops with your players’ problems, treat it as a DDoS: here that is the most likely reading. Three checks make the case. Direction: the extra traffic is inbound. Shape: usually many sources, far above your player count. Timing: the host’s start and end times cover the minutes your players had trouble.

Save the evidence before changing anything: the host’s e-mail, an export of its dashboard and sar -n DEV 1 10. Do not restart repeatedly, announce a new IP or try to ban sources, which are usually spoofed.

It is not an attack when the rise is outbound only and starts at your restart, or when the sources are your own players. A spike with no host record behind it is unproven, not cleared. If the host null-routed your IP, nothing reaches you: cause 5 explains how to tell.

What a host notice or a spike actually tells you

This symptom has no error message: it arrives as a host notice or a shape on a graph. OVHcloud’s documentation says that when an attack is detected towards an IP of your service, “you are notified via email that traffic has been rerouted through the Anti-DDoS infrastructure”, and its Anti-DDoS FAQ adds that under mitigation “filtering may occur”. That is an automatic detector’s verdict: strong evidence from outside your machine, still worth checking against direction, shape and timing.

Check this first (two minutes)

Four questions, in order; each ends in a cause or a guide.

  1. Is there a record from outside your machine?

    Check your host’s e-mail and panel first. OVHcloud: the rerouting e-mail, and Network > Network Security Dashboard (scrubbing centre log, plus the Mitigation state in Advanced mode). Leaseweb’s colocation portal: a Nulled column. Other hosts: ask support.

  2. Which way is the extra traffic going?

    rxpck/s and rxkB/s are what arrives, txpck/s and txkB/s what leaves (rxkB/s is in kibibytes: multiply by about 0.008 for megabits). On Windows, use the Get-Counter line below. Compare with a quiet day.

    sar -n DEV 1 10

  3. Who is sending it?

    Capturing may need root. Read the source column; timestamps give the rate. status in the server console lists your players’ endpoints. Do not ban what you see: OVHcloud says sources are usually spoofed.

    tcpdump -n -i <iface> -c 2000 'udp dst port 30120'

  4. Does the server answer from outside while the process is alive?

    From a network that is not yours, open http://ip:port/info.json and run connect IP:Port in a player’s F8 console. Do not trust txAdmin here: with an endpoint of 0.0.0.0 or [::], its health check queries /dynamic.json on 127.0.0.1, so it can show the server online while nobody outside reaches it.

Causes, ranked

The order assumes you arrived with a host notice or an inbound rise, so an attack comes first; with only an outbound bump, start at cause 2.

Ranked by what owners report most and how cheap each check is. That is an editorial order, not a statistic: nobody publishes a dataset of FiveM outage causes. Documented means official docs or the FXServer and txAdmin source. Owners report means forum threads and issue trackers. Our inference is our reasoning from documented facts, shown so you can check it.

  1. A real attack: an inbound wall of packets from many sources

    Our inferenceThe DDoS case

    Attack traffic reaches your IP from many sources at a rate your host’s detection notices. The rest is our inference from direction: attack traffic arrives, so receive counters climb, while a join wave leaves. OVHcloud does not show sources “because they are usually spoofed”.

    How to confirm

    Start with the host’s record. Then confirm direction with sar -n DEV 1 10 and shape with a tcpdump sample. If record, direction and timing agree, treat it as an attack.

    What to do

    Save the evidence, then open a ticket with timestamps. Do not restart repeatedly, announce a new IP or ban sources.

  2. A join wave after a restart or update: outbound downloads

    Our inference

    When many players reconnect together, above all after an update that changed resources, their clients fetch files with GET /files/* (or from a file-server override). Those bytes leave your machine: outbound climbs, inbound rises far less. Restarting again repeats the wave.

    How to confirm

    Outbound (txpck/s, txkB/s) rises right after the restart time in your console or txAdmin, then decays. Inbound rises far less than outbound and the host has no record.

    What to do

    Stop restarting. If every update does this, take the load off your uplink: the docs.fivem.net cookbook describes a caching proxy for the file server (fileserver_add).

  3. Traffic you know: a busy event, or another job on the same machine

    Our inference

    More players means more traffic both ways, and a full house can look as large as an attack with no hostile source. Backups, system updates, a website or a voice server add traffic on the same address.

    How to confirm

    Compare the tcpdump sources with the endpoints status prints (behind a proxy, they may be the proxy’s addresses). Run iftop -n -N -P -i <iface>, which lists every port, and look for ports other than 30120.

    What to do

    Nothing to defend against. Keep the peak as your new baseline, and move any job to another machine or IP, or off-peak.

  4. Host mitigation in forced mode, filtering real players

    Documented

    OVHcloud shows a Mitigation state per IP: Automatic, where the scrubbing centre “reroutes traffic for deeper analysis when needed”, and Forced, where it is “taking action” right now. Under mitigation “filtering may occur”, and its Game firewall guide tells owners of bigger services who “still observe false positives” to contact support. Real players can be caught, which looks like the attack itself.

    How to confirm

    In the Network Security Dashboard, enable Advanced mode and read the Mitigation state; compare Detection time and End time with the minutes real players were refused.

    What to do

    Open a ticket with the details listed in the FAQ and state whether legitimate traffic is being dropped.

  5. The host cut off your IP: nothing reaches you at all

    Documented

    A null route makes the network drop every packet for an address. TransIP says it nullroutes a VPS automatically when it detects a DDoS of multiple Gbit/s, and that the address “will not be reachable from the outside” meanwhile; Leaseweb’s colocation portal lets customers null-route an IP too, for a number of hours or until “you remove it”. Hosts differ. A null route shows what the host did, not why.

    How to confirm

    The panel or e-mail says the address is nulled. The process answers locally, http://ip:port/info.json fails from every outside network, and since packets are dropped upstream, sar -n DEV 1 10 should show inbound near zero, not a wall.

    What to do

    Ask the host in writing why, since when, how it ends and what lifts it. Do not announce a new IP while you wait.

What a DDoS looks like here

An attack leaves traces outside your machine; the ordinary causes do not.

What a DDoS looks like here

  • A record from outside: a host e-mail about rerouted traffic, a scrubbing centre log row (detection time, end time, your IP as destination, attack vectors), a Forced mitigation state, or a nulled flag.
  • Direction: inbound. rxpck/s and rxkB/s usually climb while txpck/s does not follow.
  • Shape: usually many sources, far above your player count. Read how many and how scattered, not who: addresses are usually spoofed.
  • Timing: the host’s window covers the minutes your players had trouble, and the Server->client connection timed out. drop reasons in txAdmin’s log cluster in it. The ENet hard timeout is 30 seconds on both sides, so we infer a shorter disturbance causes lag, not a mass timeout.

Evidence you can collect

  • The host’s own record

    Keep the e-mail with its time zone and export the dashboard. OVHcloud’s docs keep log entries one year and the traffic chart two months, but its marketing FAQ says two weeks for the chart: export early.

  • Packets and bytes per second, Linux

    Take it during the event and on a quiet day. sar -n EDEV 1 10 adds rxdrop/s, packets dropped for lack of buffer space.

    sar -n DEV 1 10

  • Packets received per second, Windows

    Same purpose; swap in Packets Sent/sec for the outbound side. Microsoft also lists Packets Received Discarded among its network-problem counters.

    Get-Counter -Counter '\Network Interface(*)\Packets Received/sec' -Continuous

  • A sample of who is sending

    Capturing may need root. Each line starts with a timestamp, so the packets per second can be read off it. If it shows nothing during a reported event, the attack may target another port: drop the filter.

    tcpdump -n -i <iface> -c 2000 'udp dst port 30120'

  • A capture your host may ask for

    OVHcloud documents this Linux command for support captures and points Windows users to Wireshark with 100,000 packets.

    tcpdump -w capture-ovh -c 100000 port not ssh

What it does not look like

  • Hitch warnings, timeouts or high ping on their own: scripts and weak CPUs produce them too.
  • An outbound-only rise from your restart: that is a join wave.
  • Sources that are your own players, or a rise that follows your player count.
  • An empty scrubbing centre log as proof of calm: it only means the detector suspected nothing, and OVHcloud’s docs say attacks from inside its own network are handled by its security teams and “will not be reported by Anti-DDoS infrastructure systems”.

When protection is, and is not, the answer

Your host’s filtering and a proxy do different jobs; your evidence says which one you need.

Protection is the answer when

  • Record, direction, shape and timing agree, and the attacker keeps hitting the same origin address.
  • The address was nulled or you had to change it, and the new one must stay private.
  • Your host’s protection is generic: OVHcloud calls its Anti-DDoS mostly focused on layers 3 and 4, and its FiveM profile belongs to Game DDoS Protection, available only on Bare Metal Game servers.

Protection is not the answer when

  • Nothing unusual arrives from outside: a proxy changes nothing for a join wave, a busy night or a backup job.
  • The failure is inside the server: hitch warnings, a stalled script, event spam.
  • You would keep the same origin address: packets aimed at it do not go through your proxy.

If the attack is confirmed

Protect the evidence and the address first: do not restart repeatedly, announce a new IP or try to ban sources. Open a ticket with timestamps, your IP, the port and, if asked, a capture.

Then take the step your host cannot take for you: put a proxy in front of the server, ask your host for a new origin IP, publish it nowhere and let only the proxy reach it. The order matters: a proxy in front of an address the attacker already knows leaves that address under fire.

Check that nothing else gives the new address away: the cfx.re listing, old DNS records, a website on the same machine, a hardcoded address in a resource.

Start Free Trial

Your first server gets $10 CAD of free trial credit (eligible accounts, no card required): about four days of protection for up to 50 players.

FiveM anti-DDoS: how FiveShield works

Still stuck? What to post

Post lines and times, not impressions, and leave out your players’ full IP addresses.

  • The host’s record, word for word: the e-mail, or the scrubbing centre log row and the Mitigation state.
  • The output of sar -n DEV 1 10 during the event and on a quiet day (or the Get-Counter lines), and how many distinct sources the tcpdump sample showed.
  • Your txAdmin log and console lines around the event, including any drop reason starting with Server->client connection timed out., with timestamps.
  • Your FXServer build, txAdmin version, host and plan, and whether a proxy sits in front.
  • A timeline in one time zone: first player report, host start and end, first inbound rise, every restart.

Frequently asked questions

Should I restart my server during a DDoS?

Not repeatedly. Traffic aimed at your address arrives whether or not FXServer runs, so a restart does not stop it, and it brings every player back at once, adding a join wave (cause 2) on top of the attack. Take the evidence first; a single restart to clear a hung process is a separate decision.

How do I read my host’s attack dashboard?

At OVHcloud, the log gives Detection time, End time, Destination IP and Attack vectors; Mitigation reads Automatic or Forced; the chart shows dropped traffic in red and clean traffic in green. Other hosts differ.

How do I know my IP was null-routed, and how long does it last?

Your host tells you, by e-mail or a flag in the panel. From outside, the process stays up locally but http://ip:port/info.json fails from every network and inbound drops to about nothing. Nobody can give a duration without your host’s policy: on Leaseweb colocation, a null route you set yourself lasts the hours you enter or until you remove it. For the host’s own, ask in writing.

What should I put in a ticket to my host?

OVHcloud lists what it needs to tune its protection: the service on the server, when the attack started and ended, the IPs affected, protocol and port, the size of the service, other services and ports, whether legitimate traffic is being dropped, and whether the connection to the server was lost. Send the same to any host.

Verified against, and sources

Verified against FXServer build 35245 (recommended), 37150 (latest) and txAdmin v8.1.1, checked on 7 October 2026.

Sources from companies that compete with FiveShield are named, with their domain, but not linked.

Server behaviour changes between builds. If your build prints something different, the build numbers above tell you what this page was checked against.