Even a few percent of packet loss makes a server feel broken. Pages load slowly because TCP waits for retransmissions, SSH stutters, game servers rubber-band, and voice calls break up. The hard part is finding where packets are lost: on your machine, at your ISP, somewhere in between, or at the server. Here’s a methodical approach.

Measure first

ping -c 100 -i 0.2 203.0.113.10
100 packets transmitted, 97 received, 3% packet loss, time 19803ms
rtt min/avg/max/mdev = 152.1/158.4/221.9/9.8 ms
  • 0% is normal.
  • Under 1%, occasionally, is often tolerable.
  • 1–2% or more, sustained, is noticeable. 5%+ is badly broken.
  • A high mdev (jitter) often accompanies loss.

Test in both directions (from your computer to the server, and from the server to your network or a nearby public IP), and at different times. Loss in the evening only usually means congestion.

Use mtr to locate it

mtr combines traceroute and ping, measuring loss and latency at every hop:

mtr -rwzc 200 203.0.113.10
HOST                                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. AS???  192.168.1.1                0.0%   200    1.1   1.3   0.9   4.2   0.4
2. AS64500 100.64.0.1                0.0%   200    8.2   8.9   7.5  22.1   1.8
3. AS64500 isp-core.example.net      0.0%   200   11.0  11.4  10.2  25.4   1.5
4. AS3356 ae-1.carrier.net          42.0%   200   60.3  61.0  59.8  70.2   1.1
5. AS3356 ae-7.carrier.net           0.0%   200  148.9 150.2 148.1 160.3   2.1
6. AS65010 edge.hosting.example      2.5%   200  151.2 153.1 150.8 190.2   5.6
7. 203.0.113.10                      2.5%   200  152.0 154.0 151.0 195.3   6.2

How to read it

  • Loss at one intermediate hop that doesn’t continue (hop 4: 42%, but hop 5: 0%) is not real loss. That router rate-limits ICMP replies to traceroute probes, while forwarding traffic normally. Ignore it.
  • Loss that starts at a hop and continues to the destination (hop 6: 2.5%, hop 7: 2.5%) is real. It begins at or just before hop 6. Here that’s at the hosting provider’s edge, or on the link into it.
  • Only the final hop’s loss counts for the end-to-end experience.
  • Latency jumps (hop 4 → 5: 60 → 149 ms) usually mean long-haul links, such as ocean crossings. That’s normal.

See ping, traceroute and mtr. Use TCP mode when ICMP is filtered: mtr -T -P 443 example.com.

Rule out local causes on the server

Packet loss can happen inside the server too.

Interface drops and errors:

ip -s link show eth0          # look at RX/TX errors, dropped, overrun

Steadily increasing dropped counts under load can mean the server can’t keep up: CPU saturation, or small ring buffers on dedicated hardware.

Connection tracking table full:

sudo dmesg -T | grep -i conntrack
sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

table full, dropping packet means new connections are silently dropped. Raise the limit, or find the flood. See sysctl tuning.

Firewall rate limits: rules that drop excess ICMP or SYNs can look like loss in tests. Check ufw status verbose or nft list ruleset.

CPU steal or overload: heavy load can delay packet processing. Check top (si, st). See high CPU usage.

UDP socket buffers for high-rate UDP services (game servers, VoIP, DNS):

netstat -su | grep -i -E 'receive buffer errors|packet receive errors'

Raise net.core.rmem_max and the application’s socket buffer if needed.

Rule out the client side

  • Wi-Fi is a classic cause. Test from a wired connection.
  • Home routers under load, bufferbloat, and VPN clients.
  • Run mtr from the client to its own gateway first (hop 1). Loss there is local.

Path problems you can’t fix yourself

If the loss is on the path (carrier networks, ocean links) or at the provider edge:

  1. Collect evidence: mtr -rwzc 500 in both directions (client → server and server → client), with timestamps, run at the time of the problem. Routing is often asymmetric, so the return path can differ.
  2. Send it to your provider’s support with the source and destination IPs. Hosting providers can open tickets with upstream carriers, or adjust routing.
  3. Consider a different location or route: if users in one region suffer consistently, a server or relay closer to them, or a provider with better routes to that region, helps more than any tuning. For mainland China, optimised routes such as CN2 are designed for exactly this. See latency vs bandwidth and choosing a VPS location.

Living with some loss

For TCP services over lossy long-distance paths, TCP BBR keeps throughput much higher than the default congestion control. See TCP BBR. For real-time apps, choose locations that minimise distance.

Quick reference

Task Command
Measure loss ping -c 100 -i 0.2 host
Locate it mtr -rwzc 200 host
TCP-based mtr mtr -T -P 443 host
Interface drops ip -s link show eth0
conntrack full dmesg -T | grep conntrack
UDP buffer errors netstat -su

Related: Linux network troubleshooting and tcpdump.

  • Networking
  • Troubleshooting
  • Performance