How to Read a Traceroute and Diagnose Network Issues

Traceroute is a network diagnostic tool that shows the path packets take from your computer to a destination, listing every router (hop) along the way. It also measures the time it takes to reach each hop, helping you identify where delays or failures occur.

When you experience slow website loading, connection timeouts, or intermittent connectivity, traceroute helps pinpoint exactly where the problem is — whether it's on your local network, at your ISP, somewhere in the internet backbone, or at the destination server.

Traceroute works by sending packets with incrementally increasing TTL (Time to Live) values. Each router along the path decrements the TTL by 1; when it reaches 0, the router sends back a "Time Exceeded" message, revealing its identity. By sending packets with TTL 1, then 2, then 3, and so on, traceroute discovers each hop in sequence.

On macOS and Linux: traceroute google.com

On Windows: tracert google.com

Using MTR (My Traceroute): A superior alternative that combines traceroute with continuous ping monitoring:

• macOS: brew install mtr then mtr google.com
• Linux: sudo mtr google.com

Reading the output: Each line represents a hop (router) on the path. A typical entry looks like:

3 ae-2.r01.nycmny17.us.bb.gin.ntt.net (129.250.4.13) 12.456 ms 11.234 ms 12.891 ms

This shows: hop number (3), the router's hostname and IP, and three round-trip time measurements.

Normal results: Latency increases gradually with each hop. Minor variations between the three time measurements are normal. A typical domestic traceroute has 10–20 hops with total latency under 100ms.

**Timeouts (asterisks *):** A line showing * * * means that hop didn't respond. This doesn't necessarily indicate a problem — many routers are configured to ignore traceroute packets for security reasons. If subsequent hops respond normally, the * hops are harmless.

Latency spike at one hop: If latency suddenly jumps at a specific hop (e.g., from 20ms to 200ms) and stays high for all subsequent hops, that hop is likely the bottleneck. Note which network owns that router to determine if it's your ISP, a transit provider, or the destination network.

Latency spike that recovers: If one hop shows high latency but subsequent hops return to normal, the router is likely just slow to respond to traceroute packets — the actual forwarding is fine. This is called ICMP deprioritization and is not a real problem.

Persistent packet loss: If one hop shows significant packet loss AND all subsequent hops also show loss, there's a genuine issue at that point in the path.

High latency on first hop: Your local network or router has an issue. Check for Wi-Fi interference, cable problems, or router overload.

High latency at your ISP's hops (hops 2-4): Your ISP may be congested. This is common during peak hours. Contact your ISP if the problem persists.

Latency jump at a geographic boundary: A jump from 20ms to 80ms between two hops often indicates a trans-continental link (e.g., US to Europe). This is normal physics — light takes about 70ms to cross the Atlantic in fiber.

All asterisks after a certain hop: The destination or a firewall in front of it is blocking traceroute. The destination may still be reachable — try pinging it directly.

Route changes: Running traceroute multiple times may show different paths. This is normal — BGP routing can change, and load balancers distribute traffic across multiple paths.

Identifying the responsible network: Look up the IP addresses of problematic hops using LookMyIP to find the ASN and organization. This tells you whether the issue is with your ISP, a transit provider, or the destination's hosting provider — critical information when reporting problems.

Traceroute output is misinterpreted more often than it is read correctly, and almost always in the same three ways.

High latency at an intermediate hop means nothing. Routers generate ICMP Time Exceeded messages on their control plane CPU, which is slow, heavily rate-limited, and deprioritised below actual forwarding. A router showing 300ms may be forwarding your traffic in under a millisecond — it simply took its time replying to a request it considers unimportant. Only the latency at the final destination measures anything real. An intermediate spike that does not persist to the last hop is not a problem.

Asterisks do not mean packet loss. * * * means no ICMP reply came back, which usually means the router is configured not to send them, or rate-limited them away. Many networks disable ICMP generation entirely as policy. If subsequent hops respond normally, packets are clearly traversing that router fine. Loss that matters appears at the destination and at every hop after the problem — loss at one hop that vanishes at the next is a reporting artefact.

The reverse path is invisible. Traceroute shows the path outbound. The return path may be completely different, because internet routing is routinely asymmetric. A problem you observe could be anywhere on a return route you cannot see. This is why a traceroute from the other end, when you can get one, is worth ten from your side.

These three between them explain most "look at this terrible hop" reports posted to support forums. The diagnostic question is always the same: does the symptom persist to the final hop? If it does not, it is not a symptom.

One further caution: hop counts vary between runs because of load balancing. Modern networks spread flows across parallel paths, so consecutive traceroutes can show different routers at the same hop number. This is normal, and it is why mtr and Paris-traceroute exist.

A single traceroute is a snapshot of one moment, taken with three probes per hop. Intermittent problems are invisible to it. mtr combines traceroute and ping, running continuously and building statistics — which is what you actually need.

mtr -rwzbc 100 example.com

The flags: -r report mode, -w wide output so hostnames are not truncated, -z show ASNs, -b show both hostname and IP, -c 100 send 100 probes per hop.

Reading the output, the columns that matter are Loss%, Avg and StDev.

HOST                          Loss%  Snt   Last   Avg  Best  Wrst StDev
1. AS???  192.168.1.1          0.0%  100    1.2   1.4   1.0   3.2   0.3
2. AS64500 10.0.0.1            0.0%  100    8.4   9.1   7.9  14.2   1.1
3. AS64500 core1.isp.example  40.0%  100    9.2   9.8   8.7  18.3   1.4
4. AS3356 ae-1.lumen.example   0.0%  100   22.1  22.5  21.8  28.9   1.0
5. AS15169 example.com         0.0%  100   23.0  23.4  22.6  31.2   1.2

That 40% loss at hop 3 is not a problem. It disappears at hops 4 and 5, which proves packets pass through hop 3 fine — the router is simply rate-limiting its own ICMP replies. Loss that is real appears at a hop and persists through every hop after it.

StDev is the underused column. A high standard deviation with a normal average means jitter, which destroys voice and video quality even when average latency looks fine. A connection averaging 30ms with StDev of 40 is far worse for a call than one averaging 80ms with StDev of 2.

For a genuine problem, capture mtr output over several minutes at the time the issue occurs, from both ends if possible, and include it in any support ticket. A provider can act on that; they cannot act on "the internet is slow".

Router hostnames follow conventions that leak a great deal of useful information, and reading them turns an anonymous list of hops into a map.

Airport codes indicate location:

ae-3.edge4.Frankfurt1.Level3.net       → Frankfurt
xe-0-0-1.lon-lhr-core2.example.net     → London Heathrow
be-1.ams-nikhef.nl.example.net         → Amsterdam
ce-2.sjc2.us.example.net               → San Jose

Interface prefixes indicate link type and therefore capacity: ge- gigabit ethernet, xe- ten gigabit, et- hundred gigabit, ae- and be- aggregated or bundled links, po- port channel.

Role words are also conventional: core for backbone routers, edge or border for network boundaries, agg for aggregation, cust for customer-facing.

This lets you read a route as a narrative. A trace from London to a server in London that passes through Frankfurt1 and back tells you your traffic is tromboning through Germany — probably because your ISP and the destination's ISP have no local interconnect and meet at DE-CIX. That is a peering arrangement, not a fault, and no amount of complaining will change it quickly.

Where hostnames are absent, use the ASN. mtr -z shows it inline; otherwise look the address up with the IP lookup tool, which returns the ASN, the organisation and the approximate location. Knowing that hop 6 belongs to AS3356 tells you the traffic has entered Lumen's network and that a problem there is Lumen's to fix, not your ISP's.

One caution: geolocation of router addresses is less reliable than for end-user addresses, because backbone addresses are often registered to a company headquarters rather than the router's physical site. Treat the hostname as the better evidence when the two disagree.

Why does traceroute stop before reaching the destination?

Usually a firewall dropping the probes, which is extremely common for well-defended endpoints. Try traceroute -T -p 443 (TCP to a port the host actually accepts) or traceroute -I (ICMP echo) instead of the default UDP probes, since traffic to a port that is genuinely open is far more likely to be permitted.

Should I use traceroute or tracert?

They are the same concept with different defaults. Windows tracert uses ICMP echo. Linux and macOS traceroute defaults to UDP to high ports. That difference alone explains why the same path can look complete on Windows and truncated on Linux. -I makes Linux behave like Windows.

What is a good latency?

Within a city, 5–20ms. Across a continent, 30–80ms. Transatlantic, 70–120ms. Transpacific, 120–200ms. Satellite via geostationary orbit, 500ms+; low-earth-orbit services like Starlink, 20–60ms. These are floors set by the speed of light in fibre — roughly 200,000 km/s — so no provider can beat them, only approach them.

Can traceroute show me where a website is hosted?

Approximately. The final hops usually reveal the destination's network and region. Anycast and CDNs complicate this: you are seeing the nearest edge node rather than any origin server, which is the entire point of a CDN.

Why do consecutive traceroutes show different paths?

Load balancing across parallel links, which is standard in every large network. Paris-traceroute and mtr's newer modes keep flow identifiers constant so a single path is followed consistently, which produces much clearer output on load-balanced routes.