When ping shows high latency or packet loss but gives no clue about the cause, MTR is the natural next step. It maps every router between source and destination, measures latency and loss at each hop, and runs continuously so you can catch intermittent problems.

What MTR Actually Does

MTR (originally "Matt's Traceroute") combines two classic tools:

Traceroute maps the route by sending packets with incrementing TTL values. Each router that hits TTL=0 sends back an ICMP "Time Exceeded" message, revealing its IP address and position in the path.

Ping measures round-trip time and packet loss.

A standard traceroute gives you a single snapshot of the path. MTR runs continuously and builds statistics — average latency, minimum, maximum, and loss percentage — at each hop. This makes intermittent problems visible.

How to Read the Output

Each row is one hop in the path. The columns that matter most:

• Host — IP or hostname of the router at that hop. ??? means the router does not respond to TTL-exceeded probes (common on transit routers — this does not mean the link is broken).
• Loss% — percentage of probes that got no reply from that hop.
• Avg — average round-trip time in milliseconds.
• Wrst — worst (highest) round-trip time seen. Spikes here indicate occasional congestion.

The most important rule: packet loss at a middle hop that does not persist in subsequent hops is almost always a router de-prioritizing ICMP probes, not real loss. If hop 5 shows 20% loss but hops 6 and 7 show 0%, traffic is flowing fine — hop 5 is just rate-limiting your probes.

Real packet loss appears at a hop and stays at that level or higher for all hops after it.

A Real-World Example

 1. 192.168.1.1           2ms   2ms   2ms   (home router)
 2. 10.200.0.1            6ms   6ms   7ms   (ISP edge)
 3. core1.isp.net         8ms   8ms   9ms
 4. ???                   ???              (no ICMP — normal)
 5. peer.transit.net    210ms 215ms 240ms   (jump: +200ms)
 6. edge.target         215ms 218ms 245ms

Hops 1–3 are fine. Hop 4 does not respond (normal). Hop 5 suddenly shows 210ms, and hop 6 is similar. The problem is the link between hop 3 and hop 5 — a congested or poorly peered transit link is adding ~200ms of latency.

Why Run MTR from Multiple Locations?

Running MTR from your own machine shows the path from your ISP. But the MTR tool on Check-Host runs from 50+ global nodes, which is the right tool for diagnosing issues affecting specific regions:

• A server in Frankfurt might have 10ms latency from Germany but route through New York for Singapore traffic.
• A CDN misconfiguration might send Asian users to a European data center.
• A peering dispute between your hosting provider and a large ISP might cause poor routes from specific networks.

Always run MTR from the region where users are complaining, not from where you are.

Sharing MTR Results with Your Provider

When you contact a hosting provider or network operations center about a routing problem, an MTR report from the affected region is exactly what they need. It shows where in the path the problem is, which narrows down responsibility immediately.

Check-Host generates a permanent report link for every test — paste it into your support ticket instead of copying and pasting raw output.