Is my FiveM server being DDoSed? How to tell

Q: How do I tell a DDoS from a thread hitch?

A hitch is measured inside the process: the console prints server thread hitch warning: timer interval of N milliseconds when two ticks of the main loop were more than 150 milliseconds apart. A DDoS is measured outside it: a host notice, a scrubbing centre log entry or an inbound graph far above normal. Warnings with a flat host graph point to a stall; a host notice with a quiet console fits traffic that was dropped before it reached the process (our reading), and it may or may not be what hurt your players. With both, see which started first.

Updated 8 October 2026

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

Players time out, the console fills with warnings or the server drops off the list, and the first word that comes to mind is DDoS. It is a fair suspicion and a hard one to settle by feel: a packet flood, a script that stalls the server and a forgotten firewall rule can look alike from the player’s side.

This page is a decision flow: three measurements, a table from each message to its guide, and what to save before you restart. In the forum threads we read, owners trace stalls to scripts, oversized network events, the machine and its setup; that is an editorial reading of a handful of threads, not a statistic, and we know of no public dataset of FiveM outage causes. An attack is a documented possibility, and its evidence sits outside your machine.

You cannot prove a DDoS from symptoms alone. You need one piece of evidence from outside the machine: your host’s dashboard or notice, or an inbound traffic graph.

Did inbound traffic rise at the host or on the network interface?
Is the server process stalling or logging hitch warnings?
Is it one player, or everyone at once?

Under attack right now? Go to the emergency checklist

Three questions that sort an outage

Answer in this order, before you change a setting or restart. Each one rules a layer in or out.

Did inbound traffic rise at the host?
Open your host’s dashboard at the minute it started. On OVHcloud, Network > Network Security Dashboard lists the attacks its Anti-DDoS system detected (detection time, end time, destination IP, attack vectors), and OVHcloud e-mails you when it reroutes traffic; other hosts differ, so ask yours. On a Linux machine, sar -n DEV 1 10 prints packets and kibibytes received per second (rxpck/s, rxkB/s); compare with a quiet day (the host-notice guide below has the Windows equivalent). Inbound traffic far above normal, at the minute players dropped, makes an attack likely; a legitimate surge would read the same, so have your host confirm it. An empty OVHcloud log means it saw no suspected attack: that argues against a flood without ruling one out, since OVHcloud says very specific attacks can escape automatic detection. A quiet reading on the machine does not clear the path either: packets dropped on the link in front of it, or by a null route, never show up there (our reading). A flood arrives inbound; heavy outbound traffic after a restart is more likely players downloading (our reading).
Is the server process stalling or logging hitch warnings?
Read the console around that minute. server thread hitch warning: timer interval of N milliseconds means two ticks of the main loop were N milliseconds apart; it prints when N is above 150 (network thread above 150, sync thread above 100). A high N means a loop that ran late, not a slow network. After more than 45 seconds without a check-in, the watchdog prints a line such as Loop svMain seems hung! (last checkin N seconds ago). Warnings put the problem inside the process or the machine; an attack shows here only if enough of its traffic reaches the machine to slow the process (our reading). No warnings while players cannot connect points away from a busy process, toward a process that is down, a firewall or the path in front of the machine. txAdmin does not settle it: its health check is a request the machine sends to itself, normally to 127.0.0.1, so a server shown online in txAdmin says nothing about the outside path.
Is it one player or everyone?
Count the players affected in the same minute and ask where they are. One player, or one ISP or region, points first at their route, VPN or setup. Everyone at once points at something shared: the process, the machine or the path in front of it, where an attack would also show. Ask two or three of them to run cl_drawperf true in the F8 console and read Ping and PL (packet loss) at the same minute.

Start here: what you see, and the guide to open

The client fetches /info.json, then shows Handshaking with server..., Downloading content, Fetching info from server... (UDP) and Connecting to server... (ENet). The message on screen points to the stage that failed: pick the row that quotes it.

What you see
Players see Failed to get info from server (tried 3 times)
Most likely layer
The UDP path: the HTTP stages already passed
Guide
Failed to get info
What you see
Players see Failed to connect to server after 3 attempts., or stay on Handshaking with server...
Most likely layer
The ENet connect, or the HTTP handshake
Guide
Failed to get info
What you see
Many players see Client -> server connection timed out at once, or the console prints Server->client connection timed out. Pending commands: N
Most likely layer
About 30 seconds without a reply (a stalled server, or the path), a crash or restart, or commands queued for the player
Guide
Connection timed out
What you see
The console prints server thread hitch warning, network thread hitch warning or sync thread hitch warning
Most likely layer
The server process: scripts, CPU, network events
Guide
Thread hitch warning
What you see
The console prints Server list query returned an error, or the server is missing from the list
Most likely layer
The listing, or reachability
Guide
Not in the server list
What you see
Ping and packet loss are high for everyone, with no hitch warnings and no crash
Most likely layer
The server tick, network events or the path
Guide
Rubber banding, high ping
What you see
Only one player, or one ISP or region, is affected
Most likely layer
Their route, VPN or setup, more likely than your server
Guide
Rubber banding, high ping
What you see
Joining is slow, or players sit on Downloading content
Most likely layer
Your server’s uplink, or the player’s side
Guide
Stuck downloading
What you see
txAdmin says Server is not responding, warns of a partial hang, or the panel will not open
Most likely layer
A hung server, or port 40120
Guide
txAdmin not responding
What you see
Your host reports an attack or a mitigation event, or the inbound graph shows a wall of traffic
Most likely layer
Likely an attack: confirm the window and the IP with your host
Guide
Traffic spike or host notice
What you see
Someone sent a threat, or you wonder whether your IP is exposed
Most likely layer
Exposure, not yet an attack
Guide
DDoS threat, IP exposed

What to capture before you restart anything

A restart ends the process you are diagnosing and does nothing about traffic aimed at your address. Copy these first.

The window: start, end and roughly how many players dropped, in a time zone you name.
Console lines from that window, as text: the hitch warnings, any Loop svMain seems hung! line and the drop reasons, Server->client connection timed out. Last seen N msec ago. or Server->client connection timed out. Pending commands: N. plus its Command list: of queued commands and their sizes.
txAdmin’s restart line: it writes a line that begins Restarting server: Server is not responding to its console and logs, then lines such as HealthChecks failing for the past <t>. or Stopped receiving HeartBeats <t> ago.
The Timeout info line from the timeout dialog of two or three affected players.
The host’s view of the window (screenshot or export) and any e-mail it sent. Retention is limited (OVHcloud documents two months for the traffic chart), so save it now.
A reading from the machine while it happens, such as sar -n DEV 1 10 on Linux, and the same reading on a quiet day for a baseline.

The symptom guides

Each guide opens with a verdict on whether it is a DDoS, including when FiveShield does not help.

Could be a DDoS: the evidence decides
Connection timed out
Many players drop at once with Client -> server connection timed out.
FiveShield helps only if an attack is confirmed
Not evidence of a DDoS by itself
Thread hitch warning
The console prints server thread hitch warning or network thread hitch warning.
FiveShield does not help with this
Check other causes first
Failed to get info
Players see Failed to get info from server (tried 3 times) and cannot connect.
FiveShield helps only if an attack is confirmed
Not evidence of a DDoS by itself
Not in the server list
The server runs and accepts direct connections, but is missing from the list or shows as private.
FiveShield does not help with this
Could be a DDoS: the evidence decides
Rubber banding, high ping
Everyone rubber-bands or has high ping and packet loss, and nothing crashes.
FiveShield helps only if an attack is confirmed
Not evidence of a DDoS by itself
Stuck downloading
Joining takes minutes, or players sit on Downloading content.
FiveShield helps with part of this
Check other causes first
txAdmin not responding
txAdmin restarts the server with Server is not responding, or the panel will not open.
FiveShield helps with part of this
Points to a DDoS once confirmed
Traffic spike or host notice
Your host reported an attack, or your graph shows a sudden wall of inbound packets.
Protection is the right next step
A threat is not an attack
DDoS threat, IP exposed
Someone threatened to take you down, or you want to know whether your IP is public.
FiveShield helps with part of this

When it is a DDoS

A DDoS is traffic, so its evidence is traffic: a host event for your IP, or an inbound graph far above normal, at the minute players dropped. The console can stay quiet, because traffic dropped on the link or filtered by the host never becomes work for the process (our reading; the documentation does not say so). OVHcloud shows no source addresses for detected events because they are usually spoofed, so do not spend the outage banning them.

Hosts react differently: OVHcloud documents rerouting through its scrubbing centres plus an e-mail; TransIP documents, for its VPS, that it null-routes an address under a multi-gigabit attack, which leaves it unreachable from outside; Leaseweb documents, for colocation, that its always-on protection mitigates by nulling and scrubbing and cannot be disabled, and that a null route stops an IP’s traffic at its core router. Ask yours: is my IP scrubbed or null-routed, and since when?

Once the evidence says attack: note the window, save the dashboard and your readings, give the host the window, the IP and the port, and do not restart repeatedly or announce a new address.

When protection will not help

A proxy or a filtering service works on traffic before it reaches your server. It does not speed up a script, shrink a network event, add CPU, open the game port in a firewall or fix a listing setting. If the three questions point inside the process or the machine, the fix is there, and some guides say plainly in their verdict box that FiveShield does not help.

A proxy set up wrongly can also cause the errors you are chasing: the proxy documentation says a proxied server endpoint needs a raw TCP/UDP proxy on matching ports, so in our reading a proxy that does not forward UDP would leave the client’s UDP info request unanswered, which ends in Failed to get info from server (tried 3 times).

Frequently asked questions

How do I tell a DDoS from a thread hitch?

A hitch is measured inside the process: the console prints server thread hitch warning: timer interval of N milliseconds when two ticks of the main loop were more than 150 milliseconds apart. A DDoS is measured outside it: a host notice, a scrubbing centre log entry or an inbound graph far above normal. Warnings with a flat host graph point to a stall; a host notice with a quiet console fits traffic that was dropped before it reached the process (our reading), and it may or may not be what hurt your players. With both, see which started first.

Are hitch warnings always a sign of a DDoS?

No. FXServer prints them when one of its own loops runs late, and the source does not record why. In the forum threads we read, owners trace them to scripts, large network events, a slow server or a faulty VPS CPU. A flood contributes only if its traffic reaches your machine (our reading); your host’s graph shows whether inbound traffic rose at all.

Why does everybody time out at the same moment?

The source sets a hard timeout of 30 seconds on both client and server, so when a stalled server or a dead path is the cause, a mass Client -> server connection timed out follows roughly half a minute without a reply for many players at once; in our reading a shorter stall shows as lag and loss. The client can also show this dialog when its connection to the server ends for another reason, so in our reading a crash or a restart can look like a timeout: check txAdmin’s restart reasons. Pending commands: N replaces the plain Last seen reason only when the player was seen less than 1.5 seconds before the drop and reliable commands were still waiting for an acknowledgement; its Command list: names the biggest of them (up to seven) with their sizes, which points at oversized or looping events (our reading).

Verified against, and sources

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

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