Summarise this article with:
Traceroute results tell you exactly where in the network path your traffic is slowing down or failing - but only if you know which patterns to ignore. Most people misread traceroute because they treat every high-latency hop or asterisk as a problem. The fundamental rule is simpler: a hop only matters if its symptoms persist on every hop after it.
For the TTL mechanics behind how traceroute builds this map, see Traceroute Explained. This post is about reading the output of real traces. You can run a traceroute directly from our Traceroute tool.
Quick command reference:
- Windows:
tracert example.com(add-dto skip DNS) - macOS / Linux:
traceroute example.com(add-nto skip DNS) - Best for intermittent issues:
mtr example.com(continuous, statistical)
Five Traceroute Outputs, Decoded
Each example below is a complete trace, walked hop by hop, with a verdict on where the problem is and where it is NOT.
Output 1: A Clean Baseline
This is what a healthy traceroute looks like. Learn the columns here so you can spot deviations in the next four examples.
traceroute to example.com (93.184.216.34), 30 hops max
1 192.168.1.1 1.2 ms 1.0 ms 1.1 ms
2 10.144.0.1 8.4 ms 8.6 ms 8.5 ms
3 203.0.113.1 (isp-edge.net) 13.2 ms 13.0 ms 13.5 ms
4 198.51.100.1 (core1.isp.net) 17.8 ms 17.6 ms 17.9 ms
5 192.0.2.50 (peer.transit.net) 24.1 ms 24.3 ms 24.0 ms
6 93.184.216.34 (example.com) 29.4 ms 29.2 ms 29.5 msReading the columns. Each row is one router (hop) on the path. The columns are:
- Hop number. Sequential. Hop 1 is your local router. The last is the destination.
- IP address and hostname. Who owns that router. ISPs often embed location codes in hostnames (more on this in Output 4).
- Three RTT measurements. Traceroute sends three probes per hop by default. Each number is the round-trip time in milliseconds for one probe.
What to observe in a healthy trace. Latency increases gradually and stays elevated at every hop after a rise. Hop 3 is 13 ms, hop 4 is 17 ms, hop 5 is 24 ms - each slightly higher, none dropping back. That is expected: each hop adds a bit more physical distance.
Where the problem is NOT. Everywhere. This trace is clean from local router to destination.
Output 2: A Transatlantic Step That Looks Alarming But Isn't
traceroute to bbc.co.uk (151.101.0.81), 30 hops max
1 192.168.1.1 1.1 ms 1.0 ms 1.2 ms
2 10.144.0.1 8.3 ms 8.1 ms 8.5 ms
3 203.0.113.1 (nyc-core.isp.net) 12.4 ms 12.2 ms 12.6 ms
4 198.51.100.10 (ae4.r21.nycmny01.us.bb.gin.ntt.net) 14.1 ms 14.3 ms 14.0 ms
5 192.0.2.88 (ae3.r20.londen12.uk.bb.gin.ntt.net) 88.7 ms 87.9 ms 89.1 ms
6 198.51.100.20 (lon-edge.fastly.net) 90.3 ms 90.1 ms 90.5 ms
7 151.101.0.81 (bbc.co.uk) 92.1 ms 91.8 ms 92.4 msThe jump from 14 ms to 88 ms between hops 4 and 5 is geographic, not a failure. Light travels through fiber at roughly 200,000 km per second. A single transatlantic round trip (New York to London and back, about 11,000 km) has a theoretical minimum of around 55 ms. The 74 ms jump here is physically expected.
Reading the hostname to confirm. Hop 4 is nycmny01.us.bb.gin.ntt.net. Many carriers embed location codes using three-letter IATA airport codes or city abbreviations. nyc is New York City, mny adds metro-NY disambiguation. Hop 5 is londen12.uk - London. The data has crossed the Atlantic. The CAIDA HOIHO project documents how ISPs embed these geohints across hundreds of carriers.
The critical check. Latency at hops 6 and 7 keeps climbing by small increments (90 ms, 92 ms) rather than jumping again. The elevated baseline carries through to the destination, which responds cleanly. That is the signature of a physical distance cost, not congestion.
Where the problem is NOT. Hops 4-5 look alarming but are normal transatlantic latency. There is no problem in this trace.
Common location code examples:
| Code | Location |
|---|---|
| iad / iad1 | Washington D.C. area (Ashburn) |
| ord | Chicago |
| lax | Los Angeles |
| dfw | Dallas |
| ams | Amsterdam |
| fra | Frankfurt |
| lon / londen | London |
| nrt | Tokyo (Narita) |
| sin | Singapore |
| syd | Sydney |
Output 3: High Latency at One Hop, Then Recovery (Not a Problem)
This is the most commonly misread traceroute pattern.
traceroute to cloudflare.com (104.16.124.96), 30 hops max
1 192.168.1.1 1.2 ms 1.1 ms 1.3 ms
2 10.144.0.1 8.4 ms 8.2 ms 8.6 ms
3 203.0.113.1 (isp-edge.net) 13.3 ms 13.1 ms 13.4 ms
4 198.51.100.1 (core1.isp.net) 17.6 ms 17.4 ms 17.8 ms
5 192.0.2.10 (transit-backbone.net) 312 ms 298 ms 321 ms
6 198.51.100.5 (peer-link.net) 19.2 ms 19.0 ms 19.3 ms
7 104.16.124.96 (cloudflare.com) 21.5 ms 21.3 ms 21.6 msHop 5 shows 300+ ms. Hop 6 drops back to 19 ms. The problem is NOT hop 5. This is ICMP deprioritization. The router at hop 5 is handling massive amounts of transit traffic. Its operating system puts ICMP "time exceeded" replies - the packets that traceroute depends on - at the bottom of its processing queue. Actual user traffic flows through at normal speed. The router only generates the diagnostic reply after a delay.
In my testing with various ISP backbones, this pattern shows up regularly on Tier-1 transit routers that carry hundreds of gigabits per second. They are too busy forwarding real traffic to promptly answer diagnostic probes.
How to confirm it is not a real bottleneck. Look at hops 6 and 7. Both sit at 19-21 ms, well below the spike at hop 5. If hop 5 were genuinely congested, its congestion would affect every packet it forwarded, including the probes sent to hop 6. Those packets also pass through hop 5's forwarding engine. If they arrive fast, hop 5 is forwarding fast.
The rule from APNIC: "Unless packet loss or increased RTT is seen on every hop between a given hop and the end of the trace, it is not a problem."
Where the problem is NOT. Hop 5. The network path to the destination is clean.
Output 4: Real Packet Loss vs. Benign Asterisks
These two traces look superficially similar. One shows a real problem; one does not.
Trace A - Benign asterisks (not a problem):
traceroute to github.com (140.82.121.4), 30 hops max
1 192.168.1.1 1.1 ms 1.0 ms 1.2 ms
2 10.144.0.1 8.3 ms 8.5 ms 8.4 ms
3 203.0.113.1 (isp-edge.net) 13.1 ms 12.9 ms 13.3 ms
4 * * *
5 198.51.100.30 (transit-core.net) 22.4 ms 22.2 ms 22.6 ms
6 192.0.2.60 (cdn-edge.net) 27.8 ms 27.6 ms 28.0 ms
7 140.82.121.4 (github.com) 30.2 ms 30.0 ms 30.4 msTrace B - Real packet loss (a problem):
traceroute to github.com (140.82.121.4), 30 hops max
1 192.168.1.1 1.1 ms 1.0 ms 1.2 ms
2 10.144.0.1 8.3 ms 8.5 ms 8.4 ms
3 203.0.113.1 (isp-edge.net) 13.1 ms 12.9 ms 13.3 ms
4 198.51.100.1 (core1.isp.net) 17.5 ms * 17.8 ms
5 * * *
6 * * *
7 * * *The difference is what happens after the asterisks. In Trace A, hop 4 shows three asterisks, but hop 5 responds cleanly and the destination (GitHub) responds at hop 7. The router at hop 4 simply does not send "time exceeded" replies - a common firewall policy, not a failure. Traffic still passes through it.
In Trace B, hop 4 shows one lost probe, then hops 5, 6, and 7 produce nothing. The destination never answers. That is genuine loss starting at or near hop 4. The loss does not recover.
Three causes of benign asterisks:
- The router is configured to drop ICMP diagnostic packets entirely (saves CPU on high-volume backbone routers).
- A firewall policy blocks TTL-exceeded replies outbound.
- ICMP rate limiting is active and the probe arrived during a rate-limited window.
How to tell them apart. If the destination responds (either in your traceroute or with a separate ping), middle-path asterisks are benign. If asterisks run from a certain hop to the end and the destination is silent, the problem is real - and it is between the last clean hop and the first asterisk.
Use our Port Scanner or Ping tool to quickly verify whether the destination is actually reachable when traceroute output is ambiguous.
Where the problem is NOT. In Trace A: nowhere. In Trace B: the problem is between hop 3 and hop 5. Hop 4 shows partial loss, which is the most likely fault point.
Output 5: A Route That Dies Mid-Path and a Routing Loop
Trace A - Route dies:
traceroute to 192.0.2.200, 30 hops max
1 192.168.1.1 1.1 ms 1.0 ms 1.2 ms
2 10.144.0.1 8.4 ms 8.2 ms 8.6 ms
3 203.0.113.1 (isp-edge.net) 13.0 ms 12.8 ms 13.2 ms
4 198.51.100.1 (core1.isp.net) 17.5 ms 17.3 ms 17.7 ms
5 * * *
6 * * *
7 * * *
...
30 * * *Trace B - Routing loop:
traceroute to 198.51.100.100, 30 hops max
1 192.168.1.1 1.1 ms 1.0 ms 1.2 ms
2 10.144.0.1 8.4 ms 8.2 ms 8.6 ms
3 203.0.113.1 (isp-edge.net) 13.1 ms 12.9 ms 13.3 ms
4 198.51.100.1 (router-a.isp.net) 17.4 ms 17.2 ms 17.6 ms
5 192.0.2.10 (router-b.isp.net) 22.1 ms 22.0 ms 22.3 ms
6 198.51.100.1 (router-a.isp.net) 27.8 ms 27.6 ms 28.0 ms
7 192.0.2.10 (router-b.isp.net) 33.2 ms 33.0 ms 33.4 ms
8 198.51.100.1 (router-a.isp.net) 38.5 ms 38.3 ms 38.7 ms
...Trace A: the fault is between hop 4 and hop 5. Hop 4 responds. Everything after it does not. Unlike the benign asterisk case, there is no recovery - the trace runs to hop 30 with nothing. This points to a routing black hole or a genuine outage. The last responding hop (core1.isp.net at hop 4) is the router that knows where to send your packets. Whatever it is forwarding them toward is not responding and not sending anything back.
Trace B: the same two routers repeat with rising latency. router-a and router-b alternate. Latency keeps increasing by roughly 5-6 ms per appearance because each transit through the loop costs extra RTT. Packets will keep bouncing until their TTL hits zero. Nothing reaches the destination. This is a routing loop - a misconfigured routing table where each router's next-hop points back to the other. It is always a network infrastructure problem, never a problem on your end.
What to do. For both patterns:
- Confirm the destination is globally unreachable (not just from your network) by checking a down-detector service or using our Traceroute tool from a different vantage point.
- Contact your ISP with the traceroute output. Point them to the last clean hop by name and IP.
- For a routing loop, the ISP must fix routing tables on the affected routers. You cannot work around it from your side.
Where the problem is NOT. Your device and your local network (hops 1-4 are clean in both). The fault starts at hop 5 in Trace A, and it is an ISP or transit provider infrastructure issue in Trace B.
What to Do With Your Findings
If the problem is in your local network (hops 1-2):
- Restart your router and modem
- Try a wired Ethernet connection to rule out Wi-Fi interference
- Run a Speed Test to check connection quality
If the problem is in your ISP's network (hops 2-5):
- Call your ISP and share the full traceroute output
- Name the specific hop: IP address, hostname, and the hop number
- Ask if there is a known outage or maintenance window
If the problem is in a transit network (middle hops):
- Your ISP must raise it with the transit provider. You cannot escalate directly.
- In the meantime, a VPN may route around the congested link. See Best VPN Services for options that support route control.
- Check our Network Troubleshooting Guide for a broader diagnostic flow.
If you need continuous monitoring: Run mtr example.com and let it collect at least 100 cycles. MTR updates statistics per hop in real time and is far better at catching the 2% packet loss or 15ms of jitter that a single traceroute snapshot will miss.
FAQ
Why does one hop show high ping but the destination is fast?
That hop is deprioritizing ICMP diagnostic replies. Routers handling high-volume transit traffic put "time exceeded" ICMP messages at the bottom of their processing queue. Your actual data packets still flow through at full speed - the router just takes longer to generate the diagnostic reply. The test: look at all hops after the spike. If their latency is low and the destination responds fast, the spike is not a real bottleneck.
What does * * * mean in traceroute?
Three asterisks on a hop mean no response arrived within the timeout window. In the middle of a trace, this almost always means the router does not send "time exceeded" replies - either by firewall policy or to conserve CPU on high-traffic hardware. It does not mean your packets are being dropped. You can confirm: if the hops after the asterisks respond, and the destination is reachable, the asterisks are harmless. Only worry if asterisks run from one hop to the end and the destination also fails.
How do I know if packet loss is real or just ICMP rate limiting?
Check whether the loss is isolated to one hop or persists through all subsequent hops. If hop 7 shows 50% loss but hop 8 and the destination show 0% loss, that is ICMP rate limiting at hop 7 - not real loss. If hop 7 shows loss and every hop after it (including the destination) also shows loss or is unreachable, the loss is real and hop 7 is the likely fault point. MTR makes this easier to see: run it for 100+ cycles and watch whether the loss percentage at later hops matches or is lower than the loss at the suspected hop.
Why does my traceroute look different from someone else's to the same destination?
Internet routing is asymmetric and dynamic. The path from A to B is not necessarily the reverse of B to A, and different ISPs have different peering agreements that determine which transit networks they use. Your traceroute and a friend's traceroute to the same server may take entirely different geographic routes. This is why our server-side Traceroute tool is useful: it shows the path from a different origin point, helping you distinguish problems on your local path from problems at the destination itself.
Sources
WhatIsMyLocation Team
Our team of network engineers and web developers builds and maintains 25+ free networking and location tools used by thousands of users every month. Every article is reviewed for technical accuracy using real-world testing with our own tools.
Related Articles
Try Our Location Tools
Find your IP address, GPS coordinates, and more with our free tools.