What is MTR traceroute and how does it work?

MTR (My Traceroute) combines ping and traceroute into a single diagnostic. It sends packets with incrementing TTL values, causing each router on the path to return a time-exceeded message. This reveals every network hop between the probe node and your server, with latency and packet loss measured at each individual hop.

How do I read an MTR result?

Each row represents a network hop. The Host column shows the router IP or hostname, Loss% shows packet loss at that hop, and Avg shows average latency. If a middle hop shows high loss but subsequent hops respond fine, that hop is rate-limiting ICMP replies — not actually dropping real traffic. Actual packet loss that affects users shows at the final destination hop.

Can I run an MTR traceroute from a specific country?

Yes. Use the country-specific node pages (e.g. /mtr/germany or /mtr/singapore) to run an MTR diagnostic from nodes in that specific country. Running from multiple countries simultaneously helps identify whether routing issues are path-specific or affect all global traffic to your server.

MTR Traceroute Online — Visual Network Diagnostic from 50+ Locations

Advanced Settings

Show world map

Info Ping HTTP TCP UDP MTR DNS

Check MTR: Global Network Diagnostic & Traceroute

Enter a domain or IP address above to begin the global MTR diagnostic.

Examples: 1.1.1.1 tarnkappe.info google.com

Global MTR (My Traceroute) & Routing Diagnostic Tool

MTR works by sending packets with incrementing TTL values. The first packet expires at the first router, the second at the second, and so on — each router that drops a packet sends back an ICMP time-exceeded message that reveals its address and latency. The result is a hop-by-hop map from the probe node to your destination, with latency and packet loss measured at each step.

Hop-by-Hop Packet Loss and Latency

Ping only tells you whether the destination answered and how long it took. MTR shows you every router on the path in between. If the 8th hop out of 14 suddenly shows 40% packet loss and higher latency, and all subsequent hops look normal, the problem is almost certainly at that specific router or the link immediately after it — not at your server. That level of precision cuts diagnosis time significantly compared to ping alone.

BGP Routing and Suboptimal Paths

BGP selects routes based on AS path length and local policies, not physical distance or link speed. Traffic from one country to another sometimes crosses unexpected continents because of peering agreements between carriers. Running MTR from multiple locations reveals whether different ISPs take different paths to the same destination, and whether any of those paths are significantly longer or more congested than they should be.

Reverse DNS (PTR) Resolution

Each hop IP is resolved to a hostname via reverse DNS. Carrier hostnames often encode the location and provider — something like "ae-3.r21.frnkge04.de.bb.gin.ntt.net" tells you this is NTT's backbone in Frankfurt. This makes it straightforward to identify which transit provider owns each segment of the path. One thing to keep in mind: a hop showing 100% loss while subsequent hops respond normally is almost always ICMP rate-limiting, not a real outage — the router is forwarding traffic fine but deprioritizes generating TTL-exceeded replies.