Diagnosing Packet Loss on a Game Server VPS (mtr)

Players say the server "lags" or "rubber-bands" and you need to know whether the problem is the network dropping packets or the server itself choking. These are completely different fixes, and confusing them wastes hours. mtr — a continuous traceroute that pings every hop repeatedly — is the right tool for the network half. The trick is reading it correctly, because mtr lies to you about intermediate hops unless you know how it works.

1. Install and run mtr

apt install mtr-tiny        # Debian/Ubuntu
mtr --report --report-cycles 100 YOUR.SERVER.IP

--report runs a fixed number of cycles and prints a table instead of the live view; --report-cycles 100 gives 100 samples per hop, enough to see real loss. Run it from a client toward the server and, separately, from the server toward a known-good target — loss can be one-directional, and testing both ways tells you which.

2. Read the report

A typical line looks like:

HOST: client                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.1.1                  0.0%   100    0.4   0.5   0.3   1.1   0.1
  5. core-router.isp.net         12.0%   100   14.2  15.0  13.8  40.1   3.2
  9. YOUR.SERVER.IP               0.0%   100   38.5  39.1  37.9  55.2   2.1

The columns that matter: Loss% (drops at that hop), Avg (mean latency), and Wrst/StDev (jitter). The final line is your server — that is the number that actually affects gameplay.

3. The golden rule: only the last hop's loss counts

The example above shows 12% loss at hop 5 but 0% at the final hop. That intermediate loss is almost always a lie: routers deprioritize or rate-limit the ICMP replies mtr depends on, so they report loss while still forwarding your actual game traffic perfectly. The rule:

Loss that appears at an intermediate hop but clears at every hop after it — including the destination — is ICMP rate-limiting, not real loss. Ignore it.

Real, gameplay-affecting loss shows up at the final hop and persists. If the last line reads 0.0%, the path is clean no matter how alarming the middle looks. If the last line reads 8.0% and every hop after a certain point also shows loss, that is genuine and you have found roughly where it starts.

4. Test UDP on the game port

CS 1.6 is UDP, and some paths treat ICMP and UDP differently. Point mtr at the actual game port to test a path closer to what the game uses:

mtr --udp --port 27015 --report --report-cycles 100 YOUR.SERVER.IP

If ICMP mtr is clean but the UDP test to 27015 shows persistent loss at the destination, suspect something port-specific — a firewall, a DDoS-scrubbing filter mishandling game traffic, or the firewall on the box.

5. Rule out server-side choke first

Before blaming the network at all, check whether the "loss" is actually the server choking — they look identical to a player but are unrelated. In-game, read the scoreboard's choke and loss fields:

• High choke, low network loss — the server is hitting a rate cap and cannot send fast enough. Fix sv_maxrate/sv_maxupdaterate, not the network. See choke and loss explained.
• Loss with a clean scoreboard-choke and a clean mtr — look at the box: ip -s link show eth0 for NIC dropped/errors, and ss -u -a for socket buffer overruns.

Common mistakes

• Panicking over mid-path loss — intermediate-hop Loss% that clears at the destination is ICMP rate-limiting, not real loss. Read the last hop.
• Testing only one direction — loss can be asymmetric. Run mtr both from the client to the server and from the server outward.
• Confusing choke with network loss — scoreboard choke is the server's rate cap; only mtr loss at the destination is the network.
• Too few cycles — a 5-sample run is noise. Use --report-cycles 100 for a verdict.

Verification

You have diagnosed it correctly when the numbers agree. Run a 100-cycle mtr to the server and confirm the final hop reads near 0.0% loss with steady Avg and low StDev; intermediate loss you can now ignore with confidence. Cross-check the in-game scoreboard: if network loss is clean but players still see loss or choke, the problem is on the server, not the path, and you take it to the choke/loss guide. When both the destination hop and the scoreboard are clean and the complaints stop, the path is genuinely healthy — and if lag persists despite that, it is CPU or steal, not the network.