FiveM rubber banding, high ping and packet loss: is it a DDoS?

Updated

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

VerdictCould be a DDoS: the evidence decides

It can be a DDoS or host mitigation, but cheaper causes come first: a late server tick, oversized network events, or one region’s route.

FiveShield helps only if an attack is confirmed

FiveShield helps only if the evidence shows an attack on the path or host mitigation filtering real players, never with a late tick or a script.

Players say rubber banding when a car or character snaps back to where it was a moment ago. That is a description, not a measurement: the client console documents Ping and PL (packet loss), and the server prints hitch warnings. Together they show whether the cause is the server’s loops, what your scripts send, or the path to your players.

First check, two minutes: find the hitch warnings in the console at the minute it happened, and ask three to five players in different places for Ping and PL from cl_drawperf true, with the time. Hitch lines point at your server (causes 1 to 3); everyone high with a quiet console, at the link or host (causes 4, 6, 7); one player or one ISP, at the player or the route (cause 5).

Suspect a DDoS only when evidence from outside the server says so: a host record, an inbound traffic spike, or scattered sources in a capture. Symptoms alone never prove one.

What the numbers actually mean

cl_drawperf, a user command any player can run, documents Ping (ms) as “How long it takes to get a response from the server (round trip time).” and PL (%) as “How many packets failed to reach their destination in time.”

The server reports its own lateness (GameServer.cpp). When the gap between two ticks of the main or network loop exceeds 150 ms it prints server thread hitch warning: timer interval of %d milliseconds or network thread hitch warning: timer interval of %d milliseconds; for the sync loop the limit is 100 ms and the line is sync thread hitch warning: timer interval of %d milliseconds. The number is that gap in milliseconds, not network latency.

The network thread also sends the packets queued for players and polls for what they sent (GameServer.cpp, GameServerNet.ENet.cpp), so when that loop runs late, sending and receiving both wait. The documentation does not say how this shows in Ping: our reasoning is that Ping and PL alone cannot tell a late server from a bad path, and that a hitch line at the minute of the complaint can.

Check this first (two minutes)

Three questions separate a server problem from a network problem.

  1. Who is affected: everyone, a group, or one player?

    status in the server console lists each player’s endpoint and ping (rconlog resource). Ask three to five players in different places for Ping and PL from cl_drawperf true, with the time.

    status

  2. What does the server console say at that minute?

    Search the console log for the hitch lines, with times. If players were dropped, the reason the server gave them can read Server->client connection timed out. Pending commands: %d.

  3. What does a graph from outside the machine say for the same minute?

    Open your host’s traffic graph, if it has one, and any attack or mitigation record (OVHcloud: Network > Network Security Dashboard; elsewhere, ask support about those minutes).

Causes, ranked

Cheap checks come first; the attack case comes last because claiming it needs evidence from outside the server.

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. The server tick is late

    Documented

    The main server loop prints server thread hitch warning when the gap between two of its ticks exceeds 150 ms, so whatever waits on it waits on the slow resource, blocking call or starved CPU behind it. The warning, its threshold and the profiler are documented; how a player feels it is our reasoning.

    How to confirm

    Run profiler record 500 in the server console, then profiler view (copy the link into Chrome) or profiler saveJSON filename.json: CPU time spikes are the slow frames, and the resource tick breakdown shows the script thread and file behind them. If the profile is flat while the lines continue, check the machine’s CPU next (our reasoning).

    What to do

    Fix, throttle or remove the resource the profile names, then watch whether the lines stop.

  2. Oversized or runaway network events

    Documented

    The documentation on latent client events says “sending a large amount of data blocks the network for the client, and if blocked for too long, will result in the client timing out.” Big payloads therefore block each receiving player’s network; we reason this shows as rubber banding before any timeout.

    How to confirm

    On a client in developer mode (+set moo 31337, or a non-production update channel), neteventlog true lists each network event with direction, name and size. A timed-out player’s drop reason (also passed to playerDropped) can read Server->client connection timed out. Pending commands: %d. then Command list: with up to seven of the largest queued commands (name, size, age).

    What to do

    Send large payloads with TriggerLatentClientEvent or TriggerLatentServerEvent and a sensible bps: the default (-1 or 0) is 25000 bytes per second per target, so sending to everyone costs bps times the player count each second, and around 10 000 000 and above may cause connectivity and performance issues.

  3. OneSync load

    Documented

    OneSync sends each player updates about nearby entities; culling exists so the server avoids “sending a lot of unneeded data to and from the server”. The sync thread warns above a 100 ms gap. More players and entities mean more work per tick (our reasoning).

    How to confirm

    Note whether sync thread hitch warning lines follow the player count or busy areas.

    What to do

    Cut entities first (vehicles and peds your scripts spawn and never delete), and keep onesync_distanceCulling at its default, true.

  4. Server uplink or host congestion

    Our inference

    Everything players receive leaves through the machine’s network interface, then your host’s network. If either is full, or other services share it, packets queue and drop for everyone while the game server looks healthy.

    How to confirm

    Read outbound as well as inbound: on Linux sar -n DEV 1 10 prints txkB/s beside rxkB/s, plus %ifutil, and sar -n EDEV 1 10 adds txdrop/s; on Windows the Network Interface counters include Bytes Sent/sec and Packets Outbound Discarded. None of them sees congestion beyond your machine.

    What to do

    Move heavy services (voice, web, backups) off the machine or away from peak, and ask your host whether the node is congested. A link full of legitimate traffic needs bandwidth, not a filter.

  5. One player’s or one ISP’s connection or route

    Our inference

    Wi-Fi, a congested home connection, a VPN or a PC that cannot hold its frame rate feel like rubber banding to one player. Packets from one ISP or area also cross networks you do not control, so a congested or broken route can hurt only that group.

    How to confirm

    Compare the player or group with others online at the same time. cl_drawperf true shows FPS, CPU and GPU usage beside Ping and PL; ask for country, ISP, a wired connection and the VPN off.

    What to do

    Server settings do not fix it. Low FPS with CPU or GPU near its limit points to the PC, and high Ping or PL with healthy FPS to the connection or route (our reasoning): send your host the comparison.

  6. Host mitigation or a game firewall hurting real players

    Documented

    OVHcloud’s Network Security Dashboard guide says the system “may need additional tuning”. Its Game firewall guide recommends “Default Deny”, which blocks all traffic matching no rule, so a missing rule for your game port would block real players, and it asks owners who see “false positives from Anti-DDoS Infrastructure systems” to contact support.

    How to confirm

    In the OVHcloud panel open Network > Network Security Dashboard with Advanced mode on: Mitigation reads Forced while the scrubbing centre acts, and the log gives each Detection time and End time. On a Game server, check under Network > Public IP Addresses that the Game firewall has a rule for your game port.

    What to do

    Add the missing rule. If mitigation was active and real players suffered, open a ticket with what OVHcloud asks for: start and end of the attack, IPs affected, whether legitimate traffic is dropped.

  7. A flood that degrades the link without taking it down

    Our inferenceThe DDoS case

    A flood aimed at your game port or the link can fill the interface, or the network thread’s work, with traffic that is not players’. Legitimate packets queue or drop, which players see as high Ping and PL, while the process stays up and nobody times out.

    How to confirm

    A host record of an attack overlapping the complaint is the strongest piece. Without one, look for an inbound rate far above your quiet-day baseline and many scattered sources in a short capture. OVHcloud’s traffic chart exists only during detection events, so a missing record does not prove a quiet link.

    What to do

    Save the evidence, then follow the attack branch below: do not restart repeatedly or announce a new IP.

What a DDoS looks like here

Only evidence from outside the server shows an attack: your host’s record, an inbound traffic graph or captured packets.

What a DDoS looks like here

  • Ping and PL rise for players in many places at once, and start and stop with an attack record from your host.
  • Inbound packets or bits per second jump far above a quiet-day baseline while CPU and tick time stay normal. A flood the process must parse could also delay the network thread (our reasoning), so network thread hitch warning lines do not by themselves rule an attack out.

Evidence you can collect

  • Your host’s record

    On OVHcloud the scrubbing centre log lists Detection time, End time, Destination IP and Attack vectors for 1 year; the traffic chart is kept 2 months and filled only during detection events, so save a copy early and keep your own counters. Source addresses are not shown (usually spoofed): do not ban addresses.

  • Inbound packet rate on Linux

    Read rxpck/s and rxkB/s, and rxdrop/s from sar -n EDEV 1 10. Capture a quiet day first: a baseline makes one number meaningful.

    sar -n DEV 1 10

  • Inbound packet rate on Windows

    Watch your adapter; Packets Received Discarded is the matching drop counter.

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

  • Who is sending

    Needs root or equivalent privileges; replace <iface> and the port. A few addresses matching your players is normal; many scattered ones far above your player count point to a flood (our reasoning).

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

What it does not look like

  • Only one player, one ISP or one country is affected.
  • Traffic that jumps right after a restart is usually outbound, players downloading resources; an attack arrives inbound.

When protection is, and is not, the answer

Protection is the answer when

  • Your host’s record shows an attack on your IP in the minutes players reported, and inbound traffic on the machine rose with it.
  • Your host’s mitigation was active, real players lost packets, and a tuning request to your host did not fix it: only then is a filter in front of the host worth weighing.

Protection is not the answer when

  • The console shows hitch warnings, or a drop reason with Pending commands, and nothing outside the server shows an attack: look at your threads and scripts first, because a proxy changes neither.
  • One player, ISP or region is affected: that is a player or a route first, and a proxy is not promised to change a route.

If the evidence says it is an attack

Do not restart repeatedly or announce a new IP: a restart does nothing about traffic arriving at the address, and a new address posted publicly is visible to whoever is attacking.

Save the evidence first: the host’s records and traffic chart, the sar or Get-Counter output, a short capture, the players’ Ping and PL with times.

If your host’s own mitigation is what hurts real players, start with the tuning request in cause 6. Then decide where filtering sits: your host’s mitigation absorbs volume, and OVHcloud documents a FiveM profile for its recent Game servers; if that is not enough, put a proxy in front first, then move the origin to a new IP only the proxy knows.

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 these in this order, after removing IP addresses, identifiers and your sv_licenseKey.

  • Your FXServer build number, onesync and sv_maxClients.
  • The hitch lines for the minute of the problem, unedited, with times, and any drop reason with Pending commands.
  • Three to five players’ Ping, PL and FPS from cl_drawperf true, with time, country and ISP.
  • Your host and plan type, its record for those minutes, and sar -n DEV 1 10 output from the event and a quiet day.

Frequently asked questions

Is rubber banding a sign of a DDoS?

Not by itself: a late server loop, oversized events, a bad route or a player’s connection can cause it too. Only evidence from outside the server points to an attack.

How do I measure ping and packet loss on FiveM?

In the F8 console run cl_drawperf true: it shows Ping, PL, FPS, CPU and GPU usage. netgraph true and net_statsFile metrics.csv go further but are developer commands (they need +set moo 31337 or a non-production update channel).

Will a proxy lower my ping?

This page makes no such claim. A proxy does nothing for a late tick or a script; it fits an attack on the path, or host mitigation that filters real players, once the evidence shows one.

Verified against, and sources

Verified against FXServer build 35245 (recommended), 37150 (latest), 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.