FiveM Client -> server connection timed out: DDoS or something else?

Updated

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

VerdictCould be a DDoS: the evidence decides

It can be a DDoS, but a stalled server thread, oversized network events or a bad route give the same dialog. One piece of evidence from outside the machine decides.

FiveShield helps only if an attack is confirmed

FiveShield helps only if your host or traffic graph confirms an attack. It cannot fix network-event spam or a hung server thread.

The client lost its connection to the server. FiveM sets a 30-second hard timeout on both ends, and the dialog does not say why traffic stopped: a stalled server thread, oversized network events, a host fault, a bad route and a DDoS all produce it.

Start with the drop reasons of the affected players. Pending commands: N with a Command list: names commands the server sent and never saw acknowledged, such as network events: look at scripts first. A plain Last seen N msec ago near hitch warning or seems hung lines points to a stalled server. The same plain line with a quiet console and a txAdmin that stayed online: look outside the machine.

Call it a DDoS only with proof from outside: your host’s notice for the same minutes, or an inbound traffic jump your player count does not explain.

Messages you may see

  • Client -> server connection timed out. Please try again later.

    In the player’s connection dialog

  • Timeout info: game=%s, recv=%s, send=%s

    Under the dialog: for game frames, received data and sent data, the average gap over the last 16 events, a standard deviation and the time since the latest one

  • Server->client connection timed out. Last seen %d msec ago.

    As the drop reason given to playerDropped and filed by txAdmin under timeout; the player’s dialog may show it too

  • Server->client connection timed out. Pending commands: %d.

    As the drop reason, followed by the largest commands the server sent and never saw acknowledged

What it actually means

The client shows Client -> server connection timed out. Please try again later. when, in game, its network layer reports the server connection as timed out or gone (NetLibrary.cpp, NetLibraryImplV2.cpp). If the server’s own drop reason reaches the player first, the same Timed out dialog shows that text instead. Each value of its Timeout info: game=%s, recv=%s, send=%s line is an average gap in milliseconds over the last 16 events, then, after ±, a standard deviation and, after ~, the milliseconds since the latest event.

Client and server each set a hard timeout of 30 seconds (NetLibraryImplV2.cpp, GameServerNet.ENet.cpp), and the client’s source comment calls it equivalent to the server-side check. Our reading: a hiccup of a few seconds shows as lag and loss, not a timeout; many players timing out together means something stayed silent for about half a minute, or a queue never drained.

The server drops the player with Server->client connection timed out. Last seen %d msec ago. or, when the player was last seen under 1,500 ms before the drop and sent commands were still unacknowledged, Server->client connection timed out. Pending commands: %d. plus a Command list: of up to the seven largest, each with its name, size in bytes and milliseconds since it was sent (GameServer.cpp, GameServerNet.ENet.cpp). txAdmin files both under timeout (classifyDropReason.ts). Neither says why traffic stopped; the checks below tell a silent server from a silent path.

Check this first (two minutes)

Each step ends in a destination. Note the time players dropped, with your time zone.

  1. One player, a few from one region, or everyone at once?

    Ask your Discord who dropped and when. Everyone within seconds is a server or path event; one player, or a few on one ISP, points at their own connection. In their dialog, large game= figures mean their own game froze; large recv= with a normal game= mean nothing arrived from the server (our reading).

  2. Read the drop reasons of the affected players

    Open the server console log, or wherever you record playerDropped, for the minute of the drops. Copy the reasons before any restart.

  3. Look for a stall in the server console

    Search around the drops for hitch warning and seems hung. The figure in server thread hitch warning: timer interval of %d milliseconds is an interval between two ticks, not latency. If they recur, profile:

    profiler record 500

  4. Did txAdmin, the process and the machine stay up?

    In the txAdmin console and logs look for txAdmin was frozen for N seconds and Restarting server: lines (Server is not responding, Server process close detected). An online txAdmin proves little: its health check is a request from the same machine to the server’s own address (0.0.0.0 becomes 127.0.0.1), so it never crosses the path players use.

  5. Check the machine and the host for the same minutes

    Check CPU, memory, disk and network per process, other services included (voice, web, database), then your host’s panel for a notice, a mitigation entry or an inbound graph.

Causes, ranked

The DDoS is cause 6 because it needs proof from outside the machine, not because it never happens.

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. Oversized or looping network events

    Documented

    The documentation says that sending a large amount of data through ordinary events blocks the client’s network, and if it stays blocked too long the client times out. A latent event sent to -1 goes to every player at bps bytes per second: bps times the player count, per second.

    How to confirm

    Read the Command list: in the drop reasons: the same event name, with a large size, for many players. reliable network event overflow reasons are another mechanism: txAdmin files them under security, not timeout. On a developer-mode client, neteventlog true shows each event’s direction, name and size.

    What to do

    Send big payloads with TriggerLatentClientEvent or TriggerLatentServerEvent, keep bps modest (default 25000; the documentation warns about roughly 10,000,000 and above) and stop broadcasting to -1 what one player needs. Raising rateLimiter_netEvent_* does not make a script send less.

  2. The server thread stalls

    Owners report

    FXServer runs several loops, among them svMain, svNetwork and svSync. The main one prints server thread hitch warning: timer interval of %d milliseconds when two ticks were more than 150 ms apart, and the watchdog prints Loop %s seems hung! (last checkin %d seconds ago) after 45 seconds. The documentation does not say which loop’s stall reaches the connection; owners report mass timeouts with hitch warnings, traced in some threads to scripts.

    How to confirm

    Search the console around the drops for hitch warning (the server, network and sync threads each print their own) and seems hung. The watchdog speaks after 45 seconds, later than the 30-second timeout, so look for the hitch warning printed when the loop resumes (our reading). Profile with profiler record 500, then profiler view.

    What to do

    Find the resource in the profile and fix or remove it. A proxy changes nothing about how fast a thread runs.

  3. A fault at the host, or a heavy neighbour on the same machine

    Owners report

    The server can be fine while the machine under it is not. Owners report a VPS CPU fault the provider fixed, a network-event flood that tripped the host’s security and got repeated packets dropped, and, in a mass-timeout thread, one reply crediting a dedicated machine for voice. txAdmin prints txAdmin was frozen for N seconds for unknown reason (random issue, VPS Lag, DDoS, etc). when its monitor stalls for over 10 seconds. OVHcloud’s Game firewall guide, for its Game servers, recommends "Default Deny", which blocks all traffic matching none of your rules: a missing UDP rule would cut players off.

    How to confirm

    Search the txAdmin console and logs for txAdmin was frozen, compare per-process load for the exact window, ask your host about incidents, and check your game firewall has a rule for the UDP game port.

    What to do

    Open a ticket with timestamps and the exact drop lines, restore any rule you changed, and move a heavy neighbour (voice, database, web panel) to its own machine or cap its share.

  4. A restart or crash that only looks like a timeout

    Our inference

    A clean shutdown (quit with a reason) drops players with Server shutting down: <reason>. A killed process sends nothing, so clients probably hit their own 30-second timeout (our reading); on Windows, FXServer may send the same message when it ends abnormally (GameServer.cpp). txAdmin restarts a server whose heartbeats stop for 60 seconds or whose health check fails for 180, logging Restarting server: Server is not responding.

    How to confirm

    Compare the first drop time with the txAdmin log.

    What to do

    Fix what stopped the process and move scheduled restarts off peak hours. A hung server that txAdmin has to kill is cause 2 again.

  5. One player’s connection, or one region’s route

    Owners report

    One player’s Wi-Fi, VPN, antivirus or overloaded PC gives the dialog on their screen only; a routing fault between an ISP or country and your host hits everyone behind it.

    How to confirm

    Count affected players per ISP and country. Ask one to leave cl_drawperf true on: Ping (ms) and PL (packet loss, %) show whether loss climbed before the drop.

    What to do

    One player: their network, VPN or PC. A region: give your host the ISP, country and minutes, and ask for a route check.

  6. A DDoS, a null route or a host mitigation false positive

    DocumentedThe DDoS case

    OVHcloud emails when an attack is detected and traffic is rerouted through its Anti-DDoS infrastructure, and its guides ask owners who see false positives to contact support for tuning. Leaseweb says, for colocation, that mitigation by nulling cannot be disabled; TransIP nullroutes an address under a multi-Gbit/s attack, which is then unreachable from outside. The established connection stops receiving, hits the 30-second timeout, and every player gets the dialog together (our reading).

    How to confirm

    Look for outside proof for the same minutes: your host’s email or notice and, on OVHcloud, Network > Network Security Dashboard, whose scrubbing-centre log shows "Detection time", "End time", "Destination IP" and "Attack vectors".

    What to do

    With proof, keep it, tell your host and follow the branch under "When protection is, and is not, the answer". If the host’s own mitigation hit real players, ask support to tune it.

What a DDoS looks like here

An attack is a change at the network edge, so its proof sits outside the FXServer process: your host’s notice, an inbound graph, captured packets.

What a DDoS looks like here

  • Many players drop within seconds, with the plain Last seen N msec ago. reason, not Pending commands.
  • No hitch warning or seems hung line, and txAdmin stays online (its health check never leaves the machine). That fits a dead outside path but does not prove one.
  • Your host reports it: an email about rerouting to mitigation, a log entry for the same minutes, or a note that the address was null-routed.

Evidence you can collect

  • Your host’s record

    OVHcloud keeps the scrubbing-centre log for a year and the traffic chart for two months, per its documentation: save what you need soon. Other hosts differ: ask yours.

  • Inbound traffic on the server (Linux)

    Take a baseline on a quiet day. rxpck/s and rxkB/s are packets and kibibytes received per second; sar -n EDEV 1 10 reports rxdrop/s. A flood filling the link before the machine can look normal here: the host’s graph comes first.

    sar -n DEV 1 10

  • Inbound traffic on the server (Windows)

    The same counter set has Packets Received Discarded. Compare with a quiet-day baseline.

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

  • A sample of who is sending

    Needs root; replace 30120 with your game port. A handful of addresses matching your players is normal; many distinct, widely scattered sources far above your player count suggest a flood. Use it to confirm, never to ban: OVHcloud documents that sources are usually spoofed.

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

What it does not look like

  • Hitch warnings or seems hung alone: they fit scripts and an overloaded CPU, and count toward an attack only with inbound traffic shown by your host or a graph.
  • A bandwidth rise after a restart: re-joining players can download changed resources, which is outbound. An attack is inbound.

When protection is, and is not, the answer

Protection is the answer when

  • Your host’s notice, dashboard or an inbound graph shows attack traffic at the minutes players dropped, and it recurs.
  • Your host null-routed the address, or its mitigation keeps filtering real players: you need game traffic filtered and the origin kept private.
  • The attacker already knows your address, so the origin must change too.

Protection is not the answer when

  • Pending commands and a command list: a proxy forwards the same events.
  • Hitch warnings or seems hung and no host event: a proxy does not change how fast a thread runs.
  • Your host shows nothing and the inbound graph is flat at the minutes of the drops.

If the evidence says it is an attack

Keep the evidence first: your host’s log or graph, the drop lines with timestamps, any inbound capture. Do not restart repeatedly, do not announce a new address to players, and do not ban source addresses, which are usually spoofed.

Then decide which layer is missing. Your host’s mitigation absorbs volume on its own network; a protection layer in front of the server also keeps the origin address private, which means changing the origin address once, after the protection is in place.

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

Paste text, not screenshots, with the time zone of every timestamp. Remove player identifiers and IP addresses first.

  • FXServer build, txAdmin version, operating system, and VPS, dedicated server or home connection.
  • The full dialog from two or three affected players, Timeout info line included.
  • The server console, and your playerDropped records if you keep any, from a minute before the first drop to a minute after: every Server->client connection timed out. reason (whole Command list: included) and every hitch warning or seems hung line.
  • From the txAdmin console or logs, any Restarting server:, txAdmin was frozen or HealthChecks failing for the past line in that window.
  • How many players dropped, within how many seconds; your host’s notice or graph for the window; what changed in the previous 24 hours.

Frequently asked questions

Is one player timing out a DDoS?

On its own, no. A flood aimed at your address usually reaches every connected player, so it shows as many players at once. One player points first at their PC, VPN, Wi-Fi or ISP.

Why do timeouts start at peak hours?

Peak hours raise everything that scales with players: network events (a latent event sent to -1 sends bps bytes per second to every player), entity sync, script work. A flood can land at peak hours too: compare the drop reasons with your host’s graph.

Why does restarting the server fix it for a while?

A restart clears queued events, entities and script memory, so a cause that builds up with uptime vanishes, then returns. A cause outside the process, like a route or a host fault, ignores restarts, which is a clue in itself.

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.