Traceroute

Q: What's the difference between traceroute and MTR?

Classic traceroute sends one or three probes per hop and shows you a single snapshot. MTR runs continuously, accumulating statistics over many probes per hop, so transient packet drops don't look like permanent failures. We use MTR-style: multiple probes per hop, percentage statistics per hop.

Q: How do I know if a high-latency hop is the actual problem?

Check the hop after it. If hop 5 shows 200ms and hop 6 shows 30ms, hop 5 is just slow to generate ICMP replies — actual traffic passes through fast. If hop 5 shows 200ms and hop 6 also shows 200ms+, then yes, that hop is genuinely adding latency to all traffic.

Trace the network path hop by hop with per-hop latency (MTR-style).

Result

No result yet

Enter the inputs above and press Run. Results appear here in a moment.

Monitor this 24/7 — get alerts on the first failure.

Start free

Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.

What is Traceroute?

Traceroute reveals the hop-by-hop network path packets take from us to your target — which routers they cross, how long each hop takes, where loss starts. When a service "works from here but not from there," traceroute is the diagnostic that tells you where in the path things go wrong. Not just that they go wrong.

This tool runs an MTR-style probe (RFC 1393 spirit): sequential probes with incrementing TTLs, multiple probes per hop, percentages computed per hop. The output shows you a clean per-hop table — hostname/IP, round-trip time, packet loss at that hop and beyond — instead of the single-shot, often misleading classic traceroute output where one bad packet looks like a black hole.

How it works

MTR-style probing is just clever use of the TTL field:

1Send a packet with TTL=1 — Every IP packet has a Time-To-Live field. Each router decrements it; when it hits 0, the router drops the packet and sends back an ICMP TTL Exceeded reply. By starting with TTL=1, we force the first hop to identify itself.
2Increment TTL, repeat — TTL=2 reveals the second hop, TTL=3 the third, etc. Continue until either the target replies (we've reached the destination) or we hit our max hops limit (default 30).
3Multiple probes per TTL — Default 3 probes per hop. This is why MTR-style is more useful than classic traceroute — one probe might miss, three give you a percentage. A hop that drops 1/3 probes consistently is doing rate limiting on ICMP, not actually broken.
4Aggregate per-hop statistics — For each hop we report: hostname/IP if reverse-DNS resolves, loss% (probes that didn't return), best/avg/worst RTT. Some hops report no hostname — that's normal, many routers don't publish PTR records.

When you'd use it

"Why is the site slow only for some users?"

A customer in Frankfurt says your US-hosted site is slow. Traceroute from a similar geographic origin to your service. The latency jump usually shows up at one specific hop — the transatlantic cable hand-off, a congested ISP peering point, a misconfigured BGP route. Now you know where to point the network team.

Spotting routing changes

Things were fine yesterday, broken today. Same target. Traceroute reveals a new hop in the path — usually means a BGP change rerouted you through a different ISP. Sometimes that's intentional (failover); sometimes it's a misconfigured route that needs reverting.

Verifying CDN edge selection

Your CDN is supposed to serve users from the nearest edge. Traceroute from a target region — does the final hop's IP belong to a CDN node geographically close to the source? If not, your CDN's routing isn't doing what you think, and you'll want to investigate the GeoDNS or BGP anycast configuration.

Tracking packet loss to specific hops

End-to-end you see 5% packet loss. Where? Run traceroute. If hops 1-4 are 0% and hop 5 starts showing 5%+ loss that persists through hop 6, 7..., the problem is at or near hop 5. Contact whoever runs that hop — they're usually an ISP whose abuse address is in Whois on their IP block.

Verifying inter-region cloud latency

Multi-region application, trying to decide whether to run regional or to fall back to a central database. Traceroute between your regions tells you the physical path latency — much more honest than the cloud provider's advertised "low-latency inter-region links."

Reading the result

Hop number

The position in the path, starting at 1 (your direct upstream). Hops 1-3 are usually your prober's ISP. Middle hops are tier-1 backbone providers. Last few hops are the destination network's ISP and the destination itself.

Hostname / IP

Reverse DNS lookup of each hop's IP. Some routers don't publish PTR records and show as just IP. Sometimes the hostname embeds useful info — ae-1.cr1.fra.de tells you Frankfurt; xe-0-1-0.r01.lax02 tells you LA. ISPs often follow naming conventions you can decode.

Per-hop loss %

Probes sent to this TTL that got no reply. Cumulative reading: 50% loss at hop 5 followed by 0% at hop 6 means hop 5 is rate-limiting ICMP (responding only sometimes) but actually forwarding traffic fine. If loss is 0% at hop 5 and 50% at hop 6 onward, hop 5 is the breaking point.

RTT best / avg / worst

Round-trip times across the multiple probes sent to this TTL. Best is closest to the true latency; worst includes jitter and queueing. A hop where best ≈ worst = stable. Best=20ms worst=500ms = the hop is intermittently congested or queue-backing-up.

Why hop latency sometimes drops mid-path

You'll see RTT increase up to a peak then drop back. That's because the prior router is generating the ICMP TTL Exceeded reply on its slow control plane while the actual data plane is fast. The dropped RTT at the next hop is more representative of actual forward latency.

Common pitfalls

"Traceroute shows huge latency at hop X — is X the problem?"

Not necessarily. Routers handle ICMP-generating tasks on a slow control-plane CPU; data-plane forwarding is on dedicated ASICs that are much faster. A 200ms RTT at hop X doesn't mean traffic through X takes 200ms — it means X took 200ms to generate the diagnostic reply. Look at whether hop X+1's RTT also jumps; if not, X is fine, it just hates ICMP.

Path has timeouts at hops 5-7 then resumes

Some routers drop or ignore ICMP TTL Exceeded entirely (security policy). Doesn't mean the packet didn't make it through — the next hop with a sensible config will reply normally. If your target ultimately responds, the path works despite the diagnostic gap.

Path different than `traceroute` from your laptop

Expected. Your laptop's path starts from your ISP; ours from our prober's ISP. They merge at some backbone provider but the first hops differ entirely. For diagnosing your users' path, use a prober region close to them.

Traceroute completes without reaching the target

Either: (1) target blocks ICMP entirely (so our probes get to it but it doesn't reply) — verify with a TCP port check; (2) target is more than 30 hops away (rare in practice, increase max_hops if your tool supports it); (3) there's a routing black hole en route.

Run Traceroute on every change, not just once.

Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.

Start free

Frequently asked questions

What's the difference between traceroute and MTR?

Classic traceroute sends one or three probes per hop and shows you a single snapshot. MTR runs continuously, accumulating statistics over many probes per hop, so transient packet drops don't look like permanent failures. We use MTR-style: multiple probes per hop, percentage statistics per hop.

Why do some hops show as * * *?

The router at that hop didn't reply to our probe within timeout. Three usual reasons: (1) the router is configured to silently drop ICMP TTL Exceeded for security, (2) the router is overloaded and rate-limiting ICMP, (3) the probe was lost in transit. If hops before and after respond normally, the unresponsive hop is usually just policy, not broken.

Can traceroute help me debug a slow website?

Partly. It shows network-level latency along the path to the server. If the path itself is slow or has loss, that's part of the story. But application-level slowness (slow database queries, large page weight) won't show up in traceroute — use HTTP Headers tool for the application response timing breakdown.

Why does the same traceroute give different paths on different runs?

ECMP routing. Many ISPs use Equal-Cost Multi-Path routing — multiple equally-good paths exist between two points, and traffic is balanced across them, often hashed by 5-tuple (src IP, dst IP, src port, dst port, protocol). Different runs can hash to different paths.

What does 100% loss at the final hop mean?

The destination IP isn't responding to ICMP. The path to it works (all middle hops respond) but the target itself blocks ICMP or doesn't reply. Verify the host is actually serving on its real ports with a TCP check.

How do I know if a high-latency hop is the actual problem?

Check the hop after it. If hop 5 shows 200ms and hop 6 shows 30ms, hop 5 is just slow to generate ICMP replies — actual traffic passes through fast. If hop 5 shows 200ms and hop 6 also shows 200ms+, then yes, that hop is genuinely adding latency to all traffic.

Can I traceroute to an IPv6 address?

Currently we run IPv4 by default. IPv6 traceroute (using ICMPv6 Hop Limit Exceeded) is on the roadmap — the prober already supports it for paid monitoring.

What's a good max-hops value?

Default 30 is enough for 99.9% of internet paths — the actual mean hop count between two random internet endpoints is around 15-20. Increase to 64 only if you suspect an unusually long path or are tracing through multiple VPN/tunnel layers.