Traceroute
Trace the network path and latency to a destination host.
Traceroute reveals the path packets take from our server to the target, hop by hop. Each hop
is one router along the way, with the round-trip latency to that router. Use it to identify
where latency suddenly increases, where packets get dropped, or which transit providers a
destination's network depends on.
Running... (this may take a moment)
How to read the output
- Each line is one hop — a router that decremented the TTL to zero and replied. The first hops are typically our datacenter's edge; later hops cross transit providers and IXPs before reaching the destination network.
- The ms columns are round-trip times per probe. Three numbers per row means three probes per TTL.
* * *means a router rate-limited or didn't reply to the probe. A single missing hop in the middle is almost always benign if later hops respond normally.- Latency jumps are the interesting signal: a hop that takes 100 ms more than the previous one points at a slow link or congested router right there.
What you can learn from it
- Where is it slow? Find the hop where latency spikes and stays elevated for the rest of the path.
- Which ISP boundaries does traffic cross? Map each hop's IP to an ASN (our ASN lookup can help) to see the transit chain.
- Does the destination block your protocol? If all hops time out, the destination may block ICMP/UDP; TCP-mode traceroute (via curl with verbose output, for example) often succeeds where ours doesn't.
Caveats
- Traceroute paths are asymmetric — reply packets may take a different route than outbound. The latency you see is the full round-trip via both directions.
- Many routers deliberately rate-limit ICMP responses. Mid-path
* * *is normal; end-of-path* * *for many hops in a row is a real signal. - A single traceroute is one snapshot. For intermittent issues, use a continuous tool like
mtr. Background reading: Use traceroute to understand network latency.