How the trick works
Every IP packet carries a time-to-live counter. Each router that forwards it decrements the TTL by one, and any router that decrements it to zero discards the packet and sends back an ICMP "time exceeded" message. Traceroute exploits this deliberately: it sends a probe with TTL 1, which dies at the first router and produces a reply revealing that router's address. Then TTL 2, which dies at the second. And so on until a probe survives to the destination.
So a traceroute is not one measurement — it is twenty separate probes to twenty different routers. That single fact explains almost every confusing traceroute you will ever read, because the reply from hop 7 tells you about the path to hop 7, not about the path to your destination.
Reading the output without fooling yourself
Four rules cover most misinterpretations:
- A silent hop is usually normal. "No reply" means that router did not send an ICMP time-exceeded message. Plenty of routers are configured not to, or rate-limit them heavily. If the hops after it answer, nothing is wrong. Only a silent run that continues all the way to the destination indicates a real break.
- Latency at an intermediate hop is not your latency. ICMP replies from a router are generated by its control-plane CPU, which is deliberately deprioritised. A hop showing 200 ms while the next hop shows 40 ms is not a slow link — it is a busy router being slow to answer a low-priority request.
- Only rising, sustained latency matters. Look for the point where the time jumps and *stays* high for every subsequent hop. That is where the real delay was introduced. A single high hop followed by normal ones is noise.
- The return path is invisible. Each ICMP reply travels back by whatever route its router chooses, and internet routing is frequently asymmetric. A high RTT can be caused entirely by a bad return path you cannot see from this direction. This is why serious path debugging uses a traceroute from both ends.
Read the full explanation of traceroute results ↓Show less ↑
What the hop addresses tell you
We trace with -n, so addresses are not resolved to names — it is much faster and avoids waiting on slow reverse lookups. To identify a hop, run it through the reverse DNS lookup or the ASN lookup. Router PTR names are unusually informative: operators encode city codes, interface names, and link speeds in them, so a name like ae-3.edge4.Frankfurt1.example-net.net tells you the city and that the hop is a link-aggregation interface on an edge router.
A typical trace has a recognisable shape. The first hops are your own gateway and the provider's access network. Then the provider's backbone, where you may see several hops in the same city. Then an exchange point or a peering link — often the point where latency steps up as the packet crosses to another network. Then the destination network's edge, and finally the host. Watching the ASN change tells you exactly where one operator hands off to the next, which is what you need to know when you are trying to work out whose problem it is.
Common patterns and what to do about them
| What you see | What it usually means | Action |
|---|---|---|
| Trace completes, all times low | Healthy path. | If the service is still failing, the problem is above the network layer — check the port checker. |
| Last few hops silent, but the service works | The destination network filters ICMP at its edge. | Nothing to fix. Judge reachability by TCP, not by the trace ending. |
| Latency jumps at one hop and stays high | A genuinely congested or long link — often an intercontinental hop or a saturated peering point. | Note the two ASNs either side of the jump; that is the handoff to report. |
| The same few addresses repeat in a cycle | A routing loop, usually from a misconfiguration or a route withdrawal in progress. | Report it to the operator of the looping addresses. |
| Trace dies at hop 1 or 2 | Local firewall or gateway blocking outbound probes. | Not visible from here; test from another vantage point. |
| Private addresses in the middle of the path | The carrier uses RFC 1918 space on internal links. Common and harmless. | Ignore them; they are not routable but they do forward. |
UDP, ICMP, and TCP probes
Traditional Unix traceroute sends UDP packets to high-numbered ports; Windows tracert sends ICMP echo requests. Some firewalls allow one and block the other, so a path that appears broken with one probe type may complete with the other. When both are filtered, tcptraceroute (or traceroute -T) sends TCP SYN packets to a real port such as 443 — firewalls that must allow your actual traffic have to allow those too, so it very often completes where the others do not.
The command-line equivalent
These are the same flags this tool uses, plus the variants worth knowing:
# Numeric only, 1s wait, 1 probe per hop, 20 hops max — fast and readable
traceroute -n -w 1 -q 1 -m 20 example.com
# ICMP probes instead of UDP (needs root on Linux)
sudo traceroute -I example.com
# TCP SYN probes to port 443 — completes where UDP and ICMP are filtered
sudo traceroute -T -p 443 example.com
# IPv6
traceroute6 example.com
# Windows
tracert -d example.com
# The best tool for intermittent problems: continuous per-hop loss and latency
mtr -rw -c 100 example.comFor anything that comes and goes, use mtr rather than traceroute. A single trace is one sample of a path that may change between packets; mtr runs continuously and gives you per-hop loss statistics over hundreds of probes, which is the evidence an operator will actually act on.
Reporting a routing problem
If you need to escalate, include: traces in both directions (yours to them, theirs to you), the output of a long mtr run rather than a single traceroute, the exact timestamps and time zone, and the ASNs on either side of the hop where latency or loss begins. A one-way traceroute with no timestamps is the single most common reason a network ticket gets closed as "unable to reproduce".