Packet loss: first steps

Quick answer: Run mtr in BOTH directions (from you to the server and from the server back to you) with at least 100 cycles, and read only the last hops: loss that appears at a middle hop but not at the destination is usually harmless ICMP de-prioritization. Real packet loss shows at the final hop and in both directions — that is the report support needs.

Overview

Packet loss makes SSH stutter, downloads stall and calls break up, but measuring it wrong leads to false alarms. This quick guide produces trustworthy evidence in ten minutes and tells you when it is your ISP, the transit path or the server side.

Before you start

• mtr on both ends (apt install mtr-tiny; WinMTR on Windows).
• Your public IP (visible at any "what is my IP" service) for the reverse test.

Step-by-step guide

1. Forward test from your machine:

   mtr -rwzbc 100 YOUR_SERVER_IP

2. Reverse test from the server to your public IP:

   mtr -rwzbc 100 YOUR_HOME_IP

3. Interpret: loss at hop 3 that disappears by the final hop = routers rate-limiting ICMP, not real loss. Loss that persists to the last hop = genuine.
4. Locate the start: the first hop where persistent loss begins tells whose network it is — your ISP (first hops), transit (middle), or near the server (last hops).
5. Repeat at a different time of day — congestion-driven loss is time-dependent, and two samples make the report far stronger.

Common issues

• Misreading middle-hop loss: the most common false alarm — only end-to-end loss counts.
• Wi-Fi at your end: test wired; local wireless loss contaminates every measurement.
• Server firewall rate-limiting ICMP: the reverse test then needs TCP mode (mtr --tcp -P 443).
• One-direction-only loss: asymmetric routes are normal; that is why both directions matter.

When to contact support

Persistent end-to-end loss in either direction, especially starting at hops near the data center, is exactly what to report: attach both MTR reports, timestamps with timezone and your connection type — see reporting network issues.

Frequently asked questions

MTR shows loss at hop 4 but 0% at the destination — is that real loss?

No. Routers often de-prioritize ICMP replies addressed to themselves while forwarding traffic perfectly. Only loss that persists through to the final hop affects your connection.

Why must I test from both directions?

Internet routes are frequently asymmetric — the return path differs from the forward one. Loss can exist in only one direction, so a single-sided MTR can completely miss the problem.

Related articles

• How to troubleshoot packet loss
• How to check traceroute / MTR
• Network speed is lower than expected
• How to report network issues to support

Need a hand? Contact Cloud2Y support →