How to Read a Traceroute

How traceroute works

Every IP packet carries a TTL (time to live) field, called hop limit in IPv6. Each router that forwards the packet decrements it, and a router that decrements it to zero drops the packet and usually sends back an ICMP Time Exceeded message, defined for IPv4 in RFC 792, Internet Control Message Protocol and for IPv6 in RFC 4443, ICMPv6. Traceroute exploits this. It sends probes with TTL 1, then TTL 2, then TTL 3, and so on. The first router replies to the TTL 1 probe, the second to the TTL 2 probe, and the sender records who replied and how long it took. This IP TTL has nothing to do with the TTL on a DNS record, despite the shared name.

The tools differ in what they send. Classic Unix traceroute sends UDP probes to high destination ports, starting at 33434 on most implementations, and recognizes the end when the destination answers with ICMP Port Unreachable. Windows tracert sends ICMP Echo Requests and stops at the Echo Reply. Linux traceroute can also send ICMP (-I) or TCP SYN probes (-T), which helps when a firewall only allows certain traffic through. mtr combines traceroute and ping, probing every hop repeatedly.

Reading the output line by line

Here is a trace from a home network to a web server, using documentation addresses:

$ traceroute www.example.com
traceroute to www.example.com (203.0.113.80), 30 hops max, 60 byte packets
 1  router.lan (192.168.1.1)  0.612 ms  0.540 ms  0.511 ms
 2  198.51.100.1 (198.51.100.1)  8.904 ms  9.120 ms  8.771 ms
 3  core1.city-a.isp.example.net (198.51.100.17)  10.233 ms  10.410 ms  10.118 ms
 4  * * *
 5  ix-peer.city-a.transit.example.net (192.0.2.33)  11.502 ms  11.307 ms  11.620 ms
 6  be10.core2.city-b.transit.example.net (192.0.2.65)  82.441 ms  82.390 ms  82.502 ms
 7  192.0.2.97 (192.0.2.97)  83.910 ms 192.0.2.101 (192.0.2.101)  84.022 ms 192.0.2.97 (192.0.2.97)  83.877 ms
 8  web1.example.com (203.0.113.80)  84.215 ms  84.190 ms  84.303 ms

Reading it from the top:

• Line 1 is your own router, under a millisecond away.
• Hops 2 and 3 are the ISP's access and core network. The name on hop 3 comes from a reverse DNS (PTR) lookup of the replying address.
• Hop 4 shows three asterisks: no reply within the timeout. Because hop 5 and everything after it answer normally, this router is forwarding traffic fine and simply not answering probes.
• Hop 6 jumps from about 11 ms to 82 ms, and the latency stays there for every later hop. That is often a long-distance link, such as an ocean crossing, which is expected physics rather than a fault. Congestion or a long return path can look the same, so compare with the latency and loss to the destination itself, and repeat the trace, before deciding.
• Hop 7 lists two different addresses. That usually means the network is balancing traffic over parallel paths and different probes took different routes, though it does not prove the paths are equal-cost.
• Hop 8 is the destination, and its time matches the hop before it.

Add -n (or -d on Windows) to skip the reverse lookups, which makes the trace faster and avoids long pauses when PTR lookups time out.

Patterns that look bad but usually are not

Routers forward packets in hardware, but answering a traceroute probe means generating an ICMP message in software, which is low priority and often rate-limited. That produces several misleading patterns:

Remember too that traceroute only shows the forward path. The replies may come back along a completely different route, so the times include a return path you cannot see. Latency that appears at a hop may actually be on the way back.

Patterns that point to a real problem

Real trouble has a consistent signature: it begins at one hop and never goes away. Look for:

• Persistent loss. Loss that starts at hop N and appears at every later hop, including the destination, suggests congestion or a fault at or just before hop N.
• Persistent latency jumps that do not match distance. A 100 ms increase between two routers in the same city, carried through to the destination, points to congestion or a poor route.
• Routing loops. The same two or three addresses repeating until the trace hits its hop limit means routers are passing packets back and forth.
• A trace that dies and the service is also down. When the last answering hop is followed only by asterisks and the destination is unreachable by every method, the problem is near that last answering hop, or the route beyond it has been withdrawn.

Routing changes on the Internet are driven by BGP, so a sudden change in path, or traffic taking a detour through an unexpected network, is often a routing event rather than a link failure. BGP Basics: How Internet Routing Works explains how those paths are chosen.

Using mtr for loss and intermittent problems

A single traceroute is a snapshot of three probes per hop, which is too few to measure loss. mtr sends probes continuously and keeps statistics. Run it in report mode with enough cycles to be meaningful, and with -z to show the autonomous system number (ASN) of each hop:

$ mtr -rwz -c 100 www.example.com
Start: 2026-10-15T09:12:03+0000
HOST: workstation                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    router.lan                              0.0%   100    0.6   0.6   0.4   1.9   0.2
  2. AS64500  198.51.100.1                            0.0%   100    9.0   9.1   8.6  14.2   0.7
  3. AS64500  core1.city-a.isp.example.net            0.0%   100   10.2  10.4   9.9  18.7   1.1
  4. AS64500  ???                                   100.0%   100    0.0   0.0   0.0   0.0   0.0
  5. AS64501  ix-peer.city-a.transit.example.net     40.0%   100   11.6  11.9  11.1  25.3   1.8
  6. AS64501  be10.core2.city-b.transit.example.net   0.0%   100   82.5  82.6  82.1  90.4   0.9
  7. AS64502  192.0.2.97                              0.0%   100   83.9  84.0  83.5  92.2   1.0
  8. AS64502  web1.example.com                        0.0%   100   84.2  84.3  83.9  91.8   0.8

Hop 5 shows 40 percent loss, but hops 6 to 8 show none, so that router is rate-limiting its replies and traffic is passing through untouched. If the destination line had shown 40 percent loss as well, you would have a real problem starting at hop 5. When you report a problem to a provider, an mtr report run in both directions (from your side and, if possible, from theirs) is the evidence most network teams ask for.

Traceroute and DNS

DNS operators use traceroute in a few specific ways. Tracing to a resolver or an authoritative name server shows whether queries are reaching it and over what path. Many DNS services use anycast, announcing the same address from many sites, so traces from different networks will end in different places; that is by design, as covered in DNS Anycast Explained. When a lookup times out from one network only, a trace from that network to the name server can show whether the path or a filter is at fault.

The hop names themselves come from DNS. They are PTR records published by whoever operates each address block, and they are only as accurate as that operator keeps them. Location codes embedded in names are useful hints, but they can be stale. Reverse DNS and PTR Records explains how those names are published.

How DNS Panopticon helps

DNS Panopticon’s Traceroute tool requests traces from Globalping probes, so they start at the probe you pick, not at your computer or DNS Panopticon’s servers. It can also help you interpret the end of a trace. Website Recon resolves a hostname and looks up each resulting IP address in RDAP to find its network and AS number, then matches that against known DNS, CDN, and hosting providers. Comparing that with the ASN column from mtr -z tells you whether your trace actually ends on the network you expected. If a CDN sits in front of the site, Recon says so, which also explains why your trace stops at a CDN edge rather than at the origin server.