How to read traceroute output

Most of what looks alarming in a traceroute is normal. Here is which parts actually indicate a fault and which are artefacts of how the tool works.

Updated Sep 21, 20264 min read

Before you run anything

These guides are reference material, not instructions for your particular network. Run commands only against networks you own or have explicit permission to examine — in many countries probing a network you are not authorised to touch is a criminal offence regardless of intent. Everything here is provided without warranty: you are responsible for what you run and for its effect on your systems.

Traceroute is the most misread tool in networking. People see a row of asterisks, conclude the connection is broken there, and spend an afternoon chasing a hop that was never the problem. Almost everything alarming in traceroute output is an artefact of how the tool works rather than a fault.

What it actually does

Every IP packet carries a counter called TTL — time to live. Each router that forwards the packet decrements it by one, and a router that decrements it to zero throws the packet away and sends back a small “time exceeded” message.

Traceroute abuses this deliberately. It sends a packet with TTL 1, which dies at the first router and produces a complaint from it. Then TTL 2, which dies at the second. And so on. The list you see is not a path the tool followed; it is a list of routers that each complained once, assembled into an order.

That detail explains nearly every confusing thing below.

Reading a normal result

traceroute to example.net (203.0.113.10), 30 hops max
 1  192.168.1.1              1.2 ms   1.1 ms   1.3 ms
 2  10.20.0.1               11.4 ms  10.9 ms  11.2 ms
 3  * * *
 4  198.51.100.9            14.8 ms  15.1 ms  14.6 ms
 5  198.51.100.42           38.2 ms  37.9 ms  38.4 ms
 6  203.0.113.10            39.1 ms  38.8 ms  39.0 ms

Hop 1 is your own router. Hop 2 is typically your ISP’s first device. The three numbers are three separate probes, so you can see whether a hop is consistently slow or merely had one bad packet.

This is a healthy result. It reached the destination, and the timings climb roughly in step with distance.

The asterisks are usually not a problem

* * * means that router did not send a reply. That is a decision the router made, not evidence that your traffic stopped there.

Routers treat generating TTL-exceeded messages as the lowest-priority thing they do. A busy core router will forward your actual traffic at full speed while ignoring the probe entirely, because replying costs CPU that forwarding does not. Many operators also filter these replies outright.

The test is whether the hops after it still answer. In the example above, hop 3 is silent but hops 4, 5 and 6 reply normally — so traffic clearly passed through hop 3 without trouble. A silent hop in the middle of a working path is noise.

What does matter is asterisks that continue all the way to the end and never recover. That means the path genuinely stops progressing.

Latency that jumps and then settles

A hop showing 200 ms followed by a hop showing 40 ms looks impossible, and it is — if you assume the numbers accumulate. They do not.

Each figure is an independent round trip from you to that one router and back. A router that is slow to generate its reply produces a large number without adding any delay to traffic passing through it. So a spike at one hop that does not persist into the following hops tells you about that router’s control plane, not about your connection.

Only a rise that continues to the end is a real increase in latency.

The return path is invisible

Traceroute measures a round trip, but it only shows you the outbound half. The return journey can take a completely different route, and frequently does. A hop that looks slow may in fact be a router whose replies come back a long way round while your real traffic goes somewhere sensible.

This also means a traceroute from you to a server and one from that server back to you can disagree entirely, and both be correct. If you are reporting a problem to a provider, run it in both directions when you can.

When it is telling you something real

Four patterns are worth acting on:

The path stops and never resumes. Consistent asterisks from a given hop through to the end, on repeated runs.
Packet loss at the final hop. Loss in the middle is usually the deprioritisation above. Loss at the destination is your traffic actually being dropped.
Latency that rises and stays risen. A step change at one hop that every later hop inherits.
The path changes on every run. Some of this is normal load balancing, but a path that never stabilises can indicate a routing problem.

One run proves very little. Run it three or four times before drawing a conclusion.

The commands

On macOS and Linux:

traceroute example.net

On Windows:

tracert example.net

If it stalls, force it to use ICMP, which some networks treat more kindly than the default UDP probes:

sudo traceroute -I example.net

Better than all of these is mtr, which runs traceroute continuously and shows loss and latency per hop as a live table. It answers “is this hop consistently bad or was that one packet” without you having to run the command repeatedly:

mtr example.net

It is not installed by default; on Debian and Ubuntu it is sudo apt install mtr, and on macOS brew install mtr. Windows has WinMTR as a separate download.

The full set of commands, with what to look for in each, is on the local checks page.

What to send to support

If you are escalating, include: the output of three separate runs, the time you ran them, whether it is constant or intermittent, and — this is the part people leave out — a run to a destination that works. A traceroute to a broken destination alone tells the other side almost nothing. Two traceroutes that diverge at a specific hop tell them where to look.

The network report collects the browser-side half of this for you, with your address masked if you prefer.

All guides