> ## Documentation Index
> Fetch the complete documentation index at: https://docs.edisglobal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Understanding Packet Loss in Traceroute & MTR 

> Interpret packet loss in traceroute and MTR results from a virtualized VPS. Learn why intermediate-hop loss is often a false alarm caused by ICMP throttling.

export const CtaButton = ({label, link, openInNewTab}) => <button className="custom-cta-button">
    <a href={link} target={openInNewTab ? "_blank" : "_self"}>
      {label}
    </a>
  </button>;

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

**If the final destination shows 0% packet loss and stable latency, your connection is usually healthy.**

***

## 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 the test was run correctly.

### Using traceroute and MTR

Follow our step-by-step guide:

👉 <CtaButton label="Traceroute & MTR guide" link="./debugging-packet-loss-traceroute-mtr-windows" />

Run MTR for at least **100 cycles** to get meaningful statistics.

### Using ping.pe

For external verification from multiple locations:

👉 <CtaButton label="Ping.pe connectivity check" link="./ping-pe-connectivity-check" />

This helps confirm whether an issue is local or global.

***

## How to interpret MTR output

### Scenario 1: Loss on intermediate hops only

Example:

```text theme={"system"}
Hop 1   80% loss
Hop 2   100% loss
Hop 3   0% loss
Final   0% loss
```

This usually means:

* Intermediate routers are rate-limiting ICMP
* Traffic forwarding is unaffected
* There is **no real packet loss** to the destination

If the final hop shows **0% loss**, the connection is working.

**If packet loss does not reach the final hop, your VPS is not losing packets.**

***

### Scenario 2: Loss continues to the final hop

Example:

```text theme={"system"}
Hop 1   0% loss
[..]
Hop 3   10% loss
Hop 4   10% loss
Final   10% loss
```

This indicates **real packet loss**, because it propagates to the destination.

Possible causes:

* Network congestion
* Faulty links
* Host or hypervisor issues

This is when investigation is required, because real traffic is affected.

***

### Scenario 3: High latency spikes without final loss

Occasional latency spikes on intermediate hops are common and often harmless if:

* The final hop latency is stable
* There is no packet loss at the destination

Routers may prioritize forwarding over responding to probes.

***

## 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, your connection is healthy — **even if earlier hops look alarming.**