How to troubleshoot packet loss

Quick answer: Measure with mtr over at least 100 cycles in both directions. Loss that appears at one middle hop but not at the destination is usually harmless ICMP rate-limiting; real packet loss shows at the final hop and every hop after the problem point. Collect the reports and send them to support if the loss is genuine.

Overview

Packet loss makes connections stall, SSH stutter and calls break up. But most "loss" reported by traceroute is an artifact: routers deprioritize ICMP replies about themselves while forwarding real traffic perfectly. The skill is separating cosmetic loss from real loss — and MTR run correctly does exactly that.

Before you start

• Install mtr on both ends if possible: sudo apt install -y mtr-tiny (Debian/Ubuntu) or sudo dnf install -y mtr (Alma/Rocky). Windows: use WinMTR.
• Note exact timestamps and your public source IP — support needs both.

Step-by-step guide

1. From your side to the server:

   mtr -rwbzc 100 SERVER_IP

   (-r report, -w wide, -b both names+IPs, -z AS numbers, -c 100 cycles.)
2. From the server back to you (return path often differs):

   mtr -rwbzc 100 YOUR_PUBLIC_IP

   Find your public IP with curl -4 ifconfig.me on your workstation.
3. Read the Loss% column: ignore isolated loss at middle hops if later hops are clean; loss is real when it starts at some hop and persists to the destination.
4. Check the server itself: CPU saturation or conntrack overflow mimics loss —

   uptime; ss -s
   ip -s link show eth0   # RX/TX errors and drops

5. If real loss persists across time and both directions, report it with both MTR outputs.

Common issues

• "50% loss at hop 3!" but 0% at destination = router ICMP throttling, not a problem.
• Testing during a spike only: confirm the pattern over several runs/hours — transient congestion happens on any network.
• Wi-Fi as the first hop: loss starting at hop 1–2 is your local network; test wired or from another connection.

When to contact support

Persistent end-to-end loss (destination Loss% > 0 over 100+ cycles, both directions, multiple times) is ours to chase — open a ticket with both reports, timestamps and your source IP.

Frequently asked questions

MTR shows loss at a middle hop but 0% at the end — is that a problem?

No. Routers deprioritize ICMP replies about themselves while forwarding traffic normally. Loss is real only when it persists to the final hop.

Why test in both directions?

Internet routing is asymmetric — the return path can differ and carry the actual problem. Run MTR from your side and from the server.

How many MTR cycles are enough?

At least 100 cycles (-c 100), which takes about two minutes — shorter runs produce statistical noise that looks like packet loss but is not.

Related articles

• How to check traceroute / MTR
• How to troubleshoot slow network speed
• How to report network issues to support
• How to check latency to Cloud2Y locations

Need a hand? Contact Cloud2Y support →