Ping answers one question — is this host reachable, and how long does a round trip take. Traceroute answers a different, more specific one: what is the path between here and there, and which hop along it is where things actually slow down or stop. Where ping gives a single number, traceroute gives a map.
How Traceroute Works
Every IP packet carries a time-to-live (TTL) field that a router decrements by one each time it forwards the packet. When TTL reaches zero, the router drops the packet and sends back an ICMP "Time Exceeded" message to whoever sent it — normally an error condition, but traceroute turns it into a measurement technique. It sends a series of probes with TTL set to 1, then 2, then 3, and so on. The TTL-1 probe dies at the very first router, which reports itself with a Time Exceeded message; the TTL-2 probe makes it one hop further before dying at the second router; and so on, one hop revealed per probe, until a probe finally reaches the destination itself and gets a real reply instead of a Time Exceeded error.
This is a deliberately different mechanism from ping, which just sends one packet and waits for one reply — traceroute exploits how routers handle TTL expiry to reconstruct the entire path, one router at a time.
Reading a Hop List
Each row in a traceroute result is one router along the path, in order from the nearest to the farthest:
- Hop number — how many routers away this one is, counting from this site's own server.
- IP address / hostname — the router that replied at this hop, with its hostname shown when a reverse DNS record exists for it. Many routers, especially inside an ISP's own backbone, simply don't have one — a bare IP at a hop is normal, not an error.
- Round-trip time — how long this specific hop took to reply, not the cumulative time to reach it. A single slow hop followed by fast ones downstream is the signature of one congested or distant link, not a broadly degraded path.
- Destination reached — marks the final hop once a probe actually gets a reply from the target itself, rather than a Time Exceeded message from an intermediate router.
Why Some Hops Show No Reply
A run of Request timed out rows in the middle of an otherwise-successful trace is extremely common and usually means nothing is actually wrong. Many routers, particularly at ISP and backbone level, are configured to rate-limit or ignore the ICMP Time Exceeded messages traceroute depends on — it costs a router real CPU time to generate one for every expiring packet, so operators frequently deprioritize or disable it entirely as a matter of policy, while continuing to forward normal traffic through that same router without any issue.
The signal to actually pay attention to is different: silent hops that resolve into a successful reply from the destination at the end (traceroute simply couldn't identify those particular routers by name) are normal. A trace that runs all the way to the maximum hop count without ever reaching the destination is the real problem worth investigating — either the host is genuinely unreachable, or something in the path is dropping the traffic entirely rather than just declining to report itself.
A Slow Site vs. a Slow Path
This is the specific distinction traceroute exists to make. If round-trip times stay low and consistent across most of the hop list and only jump sharply at the very last one or two hops, the delay lives at or near the destination itself — an overloaded server, not the network. If latency climbs steadily, hop after hop, long before the destination is reached, the problem is somewhere in the network path itself — a congested link, a poor routing decision, or physical distance the traffic has to travel through. The same overall ping time can come from either cause, and only a hop-by-hop trace tells them apart.
When to Use Traceroute
- A host is slow or unreachable and a plain ping test alone doesn't explain why.
- Confirming which network — this site's own server, an ISP's backbone, or the destination's own network — a slowdown actually lives in, before escalating to the wrong party.
- Investigating a routing change after a network reconfiguration, a new CDN, or a multi-homed connection failing over.
- Checking reachability from a different vantage point than the local machine — this trace runs from this site's own server, not the browser.
Frequently Asked Questions
Why does my trace show "Request timed out" for several hops in a row?
Almost always normal. Many routers, especially inside ISP backbones, are configured to ignore or deprioritize the ICMP messages a trace depends on to identify each hop, while still forwarding normal traffic through that router without issue. It only signals a real problem if the trace never reaches the destination at all.
What's the difference between ping and traceroute?
Ping answers whether a host is reachable and how long a single round trip takes. Traceroute answers where along the path a problem actually is, by revealing every router in between, one hop at a time. Ping is faster and is usually the first check; traceroute is what to run next once ping alone doesn't explain a slow or failed connection.
Why doesn't a hop show a hostname, only an IP address?
Not every router has a reverse DNS record configured for its IP — this is especially common inside an ISP's own backbone infrastructure, which is rarely user-facing. A bare IP address at a hop is normal and doesn't indicate a problem.
The trace never reaches the destination — is the site down?
Not necessarily on its own, but worth confirming — a trace that runs out of hops without ever getting a reply from the destination often does mean the host is unreachable along this path, but the same ICMP filtering that causes silent intermediate hops can also apply at the destination itself. Confirm with a ping test or, for a web service specifically, Is My Site Down, since both check over different protocols than the ICMP traceroute relies on.
Why is one specific hop so much slower than the ones around it?
That single jump in round-trip time is usually exactly where the actual delay is introduced — a congested link, a router under load, or a long physical distance covered in that one hop (for example, an undersea cable crossing between continents). Hops after it inheriting that higher baseline time, without adding much further delay themselves, confirms the slowdown happened at that specific point and not gradually along the whole path.
Trace the path to any host with the traceroute tool.