Diagnosing packet loss

Packet loss is not slowness. A delayed packet arrives late, a lost one never arrives and the client fills the gap with a guess. That difference is the whole problem: rubber-banding, players teleporting, and shots that do not register are what a guess looks like when it turns out to be wrong.

What loss does to a game server specifically

Most game traffic is UDP, and UDP does not retransmit. When a position update is lost, the client keeps predicting from the last one it had and then snaps when the truth arrives. Direction matters:

• Loss from player to server. Their inputs go missing. Movement feels ignored, actions do not fire, and the player is the only one who notices.
• Loss from server to player. Their world stops updating for a moment. Other players teleport and events arrive in a clump. Everyone on the affected path sees it, and nothing looks wrong to the player who caused it.

Services on TCP behave completely differently. Minecraft Java, RCON, SFTP, and a web panel all retransmit anything lost, so loss shows up first as latency spikes and stalls, not as missing data, and only becomes a disconnect once it persists. A TCP service that feels laggy in bursts and a UDP game that warps can be the same underlying loss.

Measure over a window that means something

A ping left running for five seconds sends four or five packets. One drop reads as 20% loss and no drops reads as 0%, and neither is a measurement. Loss needs a denominator large enough that a single packet does not move the figure.

On Windows, 600 packets at roughly one per second, saved to a file:

ping -n 600 203.0.113.10 > loss.txt

ping -t runs until you stop it, and pressing Ctrl+C prints the summary for what it has sent so far.

On macOS and Linux:

ping -c 600 203.0.113.10 | tee loss.txt

The summary line at the end is the number that matters, and it looks like 600 packets transmitted, 597 received, 0.5% packet loss. Ctrl+C prints it early.

Three rules for the measurement to be worth anything:

1. Run it while the problem is happening. Loss measured afterwards is a measurement of a working connection.
2. Run it for at least ten minutes, and longer if the problem is intermittent. If it comes and goes every few minutes, an hour is not excessive.
3. Prefer an MTR to a ping, because it gives you the same figure plus per-hop attribution in the same run. See How to run an MTR, and read its per-hop numbers with the rule that only loss reaching the final line counts.

Measure the port that matters, not only ICMP

Ping and traceroute use ICMP, which every device on the path is free to treat differently from your game traffic, in either direction. Loss in a ping is a lead, not a verdict, and a clean ping does not clear the path either.

• For a TCP service, probe the real port: sudo mtr -T -P 25565 -rwc 600 203.0.113.10.
• For a UDP game there is no generic way to probe the port from outside, because only the game itself knows how to answer. Use the loss counter the game client reports, plus the server's own socket counters below.
• Protection sits in front of the server, so a packet dropped there is loss from the player's point of view and leaves no trace on the machine. Run Address lookup on the Attacks tab with the affected player's address to see whether that source was filtered and by what. When players cannot connect covers that lookup and what each answer means.

Isolate it: the player, the route, or the server

Work outwards from the player. Most loss is found before you reach the route.

The player's own network

By far the most common answer, and the quickest to prove. Ask them to ping their own router first, then the server:

ping -n 100 192.168.1.1

ping -c 100 192.168.1.1

Windows first, macOS and Linux second, using whatever their router's address actually is.

• Loss to their own router means the problem is inside their home, and the usual cause is Wi-Fi. A wired test settles it in a minute.
• No loss to the router but loss to the server moves the question outward, to their line or the path.
• Loss that only appears when the household is busy is their connection saturating. It usually shows as latency under load with little or no loss, and it is not something you can fix from the server.
• A hotspot test is the strongest single piece of evidence a player can give you, because it changes the ISP and the entire path at once. Clean on a hotspot and lossy at home is a home problem.

The route

Two MTRs, one from the player to the server and one from the server back to their public IP address, taken in the same window and run for at least 300 cycles. Then apply the reading rule: loss counts when it starts at a hop and persists to the final line. Loss at a middle hop that the destination does not show is that router rationing its replies, and it is not costing you anything. That rule, with a worked example, is on How to run an MTR.

Two or three players on different ISPs make the difference between "the route is bad" and "one ISP's route is bad", which are different tickets with different owners.

The server itself

A perfect path still loses packets if the machine cannot take them off the wire fast enough. On Linux:

ip -s link show

Read the RX block for errors, dropped, and overrun. Counters that climb while players report loss point at the machine, not the network. Name the interface directly if there are several, as in ip -s link show eth0.

netstat -su

Under Udp:, two lines matter: packet receive errors and receive buffer errors. Both count datagrams the kernel had in hand and threw away because the application was not reading its socket fast enough. That is a server problem wearing a network problem's clothes, and it is the single most useful counter on this page. netstat comes from net-tools, which is not on a minimal Debian or Ubuntu image, so install it with sudo apt install net-tools or read the same values with nstat -az | grep -i Udp.

ss -ulnp

For the listening UDP socket your game uses, Recv-Q should be at or near zero whenever you look. A value that is persistently large means the game process is falling behind on draining its own socket, which produces loss no router is responsible for. The fix for that is on the server side: give the process more CPU, reduce what it does per tick, or raise its receive buffer if the software exposes that setting. See Diagnosing high latency for the load side.

Also check the si (software interrupt) figure on top's %Cpu(s) line. A core pinned there is a machine that cannot keep up with the packet rate itself.

On Windows, the equivalent summary is:

netstat -s -p udp

Receive Errors climbing is the same signal as the Linux counter above.

What to gather before opening a ticket

Loss reports are acted on when they contain a measurement and a window, and they stall when they contain a screenshot of four pings. Include all of this:

1. The server's IP address, the port, and the protocol. UDP and TCP on the same port are different paths through the filtering in front of the server.
2. The affected player's public IP address, and one unaffected player's address for contrast.
3. An MTR from the player to the server, at least 300 cycles, as text, taken while the problem was happening.
4. An MTR from the server back to that player's address, same length, same window. Without it half the path has never been measured, and the return path is where a surprising share of loss lives.
5. The ping summary line with the totals, from a run of at least 600 packets.
6. Times and dates with a time zone, how long each episode lasts, and whether it repeats or correlates with player count.
7. What the player actually experiences, in plain words. Warping, hits not registering, and timing out entirely point at different things.
8. What you have already ruled out: the wired test, the hotspot test, a second player on another ISP, the server's load figures, and the socket counters above.
9. The Address lookup result for the affected address, if protection could be involved, quoted exactly.

See Opening a ticket for where that goes, and Platform status if you want to check the panel's own systems first, remembering that it reports on those systems and not on your server.

Related