Skip to main content
Customers often report packet loss after running traceroute or MTR tests and seeing 80% or even 100% loss on intermediate hops. In many cases, however, the final destination shows no packet loss at all. This article explains how to correctly interpret MTR results and how to distinguish between real connectivity problems and harmless artifacts of how routers handle diagnostic traffic.

​
Quick summary

  • Packet loss on intermediate hops does not automatically mean a problem
  • The final hop (your VPS or target host) is what matters most
  • Many routers de-prioritize or rate-limit ICMP responses
  • Virtualized environments add additional layers where diagnostic ICMP traffic may be handled differently from normal application traffic
Start with the final destination, then check the application. Zero destination loss in one probe sample is reassuring, but it does not rule out intermittent problems or issues affecting other protocols.

​
How packet loss measurements actually work

Tools like traceroute and MTR send diagnostic packets (usually ICMP or UDP) and measure how routers respond. Think of traceroute and MTR as asking every router along the path:
“Can you reply to me right now?”
Some routers choose not to answer, but they still forward real application traffic perfectly. Important: routers are optimized to forward traffic, not to respond to diagnostic probes. When under load, they may:
  • Rate-limit ICMP replies
  • Drop diagnostic packets
  • Respond inconsistently
This can appear as packet loss in MTR even when real user traffic flows normally.

​
How to run proper tests

Before interpreting packet loss, make sure you ran the test correctly.

​
Using traceroute and MTR

Follow our step-by-step guide: 👉 Run MTR for at least 100 cycles to get meaningful statistics.

​
Using ping.pe

For external verification from multiple locations: 👉 This helps confirm whether an issue is local or global.

​
How to interpret MTR output

The examples below are illustrative, shortened to the columns that matter. Each row represents 100 probes; latency is in milliseconds. Read the destination row first, then compare the earlier hops.

​
Scenario 1: Loss on intermediate hops only

01 · No destination loss observed

Destination: 0% loss. Earlier missing replies do not carry through to the destination in this test.
What stands out: Router 2 does not reply at all, but later hops and the destination do. Its silence is not evidence that it drops all forwarded traffic.What to do: If the application also works normally, intermediate-hop loss alone is not a reason to report an outage. Routers may filter or rate-limit diagnostic replies.

​
Scenario 2: Loss continues to the final hop

02 · Destination loss needs investigation

Destination: 10% loss. The test is missing replies from the destination too. Repeat the test and compare it with the affected application.
What stands out: The loss persists through the destination, so it cannot be dismissed as one intermediate router not answering.What to do: Save the complete report, repeat from another source or in the reverse direction where possible, and test the application’s protocol and port. Congestion, a faulty link, host issues, or filtering/rate-limiting of probes may be involved. This pattern alone does not identify the exact faulty link or prove that application traffic loses the same percentage.

​
Scenario 3: High latency spikes without final loss

03 · An intermediate spike is not the end-to-end delay

Router 2 peaks at 250 ms; the destination peaks at 23 ms. The spike is not visible at the destination in this sample.
What stands out: Later hops respond faster than the router with the spike. Each row measures separate probe replies; hop timings are not added together.What to do: Judge latency at the destination and in the application. Routers may answer probes slowly while forwarding traffic normally. If the destination also slows down, investigate that separately.
For background on probe responses and router rate limits, see the MTR project and Cloudflare’s explanation of MTR.

​
Packet loss in virtualized environments

In virtualized environments, network traffic passes through:
  • Guest virtual interfaces
  • Hypervisor networking layers
  • Host networking stacks
These layers may treat diagnostic ICMP differently from normal traffic. As a result:
  • Intermediate packet loss may appear exaggerated
  • Real application traffic may remain unaffected
Always judge connectivity based on the final hop and application behavior, not intermediate ICMP statistics alone.

​
When to contact support

Please contact our support team if you observe:
  • Packet loss on the final hop
  • Persistent high latency to the destination
  • Application-level connectivity issues
When reporting issues, include:
  • Full MTR output
  • Test timestamps (UTC)
  • Source and destination IP addresses
  • ping.pe results if available
This helps us diagnose problems quickly.

​
Final takeaway

MTR is a powerful tool, but it is often misunderstood. 👉 Packet loss on intermediate hops alone is not a reliable indicator of network problems.
👉 The final destination’s statistics are what truly matter. If the destination shows stable latency and no loss, the test shows no destination loss during that sample, even if earlier hops look alarming. Check application behavior before drawing a broader conclusion.
Last modified on September 30, 2026