Traceroute Explained: Network Path, Hops, and Latency
Traceroute shows which routers your traffic passes through on the way to a destination and where latency starts to rise along that path. If a website, API, or server is slow or unreachable, traceroute helps you see whether the problem begins near your network, inside a provider, or close to the destination.
What traceroute actually shows
A traceroute lists the intermediate routers, usually called hops, between your device and the target host. For each hop, it measures how long it takes to receive a response. That makes it possible to see whether delays begin close to your network edge, deeper inside an ISP, or near the destination.
The result is not just a yes-or-no connectivity test. It gives you a rough map of the route plus timing data. This is why traceroute is often used together with ping when diagnosing slow websites, unstable APIs, or intermittent packet loss.
When people use traceroute
A website or API feels slow
Traceroute helps you check whether the slowdown starts near your local network, appears at a specific upstream provider, or only happens close to the target service.
A service is reachable from one place but not another
Comparing traceroutes from different regions can reveal routing differences, peering issues, or a provider-specific problem.
You need to separate local and external issues
If the first hops already show high latency or packet loss, the problem is likely close to your device or ISP. If the early hops look fine and issues appear later, the root cause is probably elsewhere.
You want evidence for a network ticket
A traceroute output can provide concrete timing and path details when reporting a routing problem to an ISP, hosting provider, or infrastructure team.
How traceroute works
It starts with a very low TTL
Traceroute sends a probe packet with a TTL, or time to live, set to 1. Each router that forwards the packet decreases the TTL by one.
Each router exposes one hop
When the TTL reaches 0, the router drops the packet and typically sends back an ICMP time exceeded message. That reply tells traceroute which hop the packet reached.
The TTL is increased step by step
Traceroute repeats the process with TTL 2, then 3, then 4, and so on. This gradually reveals the path hop by hop until the packet finally reaches the destination.
Round-trip time is measured for each probe
For every hop, traceroute records how long the reply took to come back. That timing is what helps you spot latency jumps or unusual delays in the route.
How to read traceroute output
A typical traceroute line contains the hop number, a hostname or IP address, and several measured response times. Here is a simplified example:
traceroute to example.com (93.184.216.34), 30 hops max 1 router.home (192.168.1.1) 1.1 ms 0.9 ms 1.0 ms 2 isp-gateway (203.0.113.1) 8.4 ms 8.1 ms 8.5 ms 3 * * * 4 core1.provider.net 18.9 ms 19.2 ms 18.7 ms 5 example.com (93.184.216.34) 24.3 ms 24.0 ms 24.1 ms
Hop number
The number at the start of the line shows how far the probe traveled. Hop 1 is usually your local router, then upstream ISP routers, then transit networks, and eventually the target.
Hostnames and IPs
Traceroute may show a reverse DNS hostname, an IP address, or both. Missing names are common and do not automatically indicate a problem.
Three timings
Most traceroute tools send multiple probes per hop. That is why you often see three timings. Small variation is normal; large variation can indicate congestion or inconsistent routing.
The final hop
If the destination answers, the last line shows that the probes reached the target. If it never appears, the destination may block replies or the route may break before arrival.
What stars and timeouts mean
A line with `* * *` means traceroute did not receive a reply for that probe in time. This does not automatically mean traffic is failing at that hop.
Many routers rate-limit traceroute responses, deprioritize ICMP, or block certain probe types entirely. If later hops continue to respond normally, that silent hop is usually not the actual problem.
Traceroute vs ping
| Topic | Traceroute | Ping |
|---|---|---|
| Primary question | Where along the path do packets travel, and where do delays start? | Does the target respond, and what is the overall round-trip time? |
| Best for | Routing analysis, hop-by-hop troubleshooting, provider path issues. | Quick connectivity checks, packet loss checks, latency verification. |
| Output style | Multiple hops with separate timings for each step in the route. | Repeated replies from one destination only. |
Need a faster first check before traceroute?
Ping is the quickest way to test basic reachability, round-trip latency, and packet loss before you move to hop-by-hop route analysis.
Read the ping guide βHow to interpret common scenarios
Latency jumps at hop 8 and stays high afterward
If response times become much higher at one hop and remain high for all following hops, that hop or the network after it may be introducing real delay.
One middle hop shows stars, but later hops are fine
This usually means the router is not answering traceroute probes, not that user traffic necessarily stops there.
Only the last hop fails to answer
The destination may block ICMP or UDP replies while still serving the application. In that case, traceroute alone cannot prove the service is down.
Routes differ between regions
Different source locations can take different providers or peering paths. That is why a service may look healthy from one place and degraded from another.
Important limitations
- β Traceroute shows the forward path of its probes, but return traffic may take a different route.
- β Routers often treat diagnostic traffic differently from real application traffic.
- β Some networks filter ICMP, UDP, or TCP probes, which can hide hops or distort the picture.
- β A slow response from one router does not always mean it is forwarding production traffic slowly.
How to run traceroute
traceroute example.com The classic traceroute command usually sends UDP probes by default, depending on the platform.
tracert example.com Windows uses the command name tracert and typically sends ICMP echo requests.
mtr example.com MTR combines ideas from ping and traceroute and is useful when you want a continuously updated view of packet loss and latency.
Frequently asked questions
Traceroute helps with one investigation. Monitoring helps before users notice.
Traceroute is excellent for manual diagnosis when something already feels wrong. nsmon complements that by checking availability and latency continuously from multiple probe locations, so you can see problems earlier and compare behavior across regions.