Traceroute
A list of the routers a packet passes, built by sending packets that expire on purpose. The middle of the list is less trustworthy than it looks.
Updated 20 September 2026 · 5 primary sources
Traceroute works by sending packets that are designed to die early. The first goes out with a hop limit of one, so the first router discards it and reports back. The next goes out with a limit of two, and the second router reports. The tool keeps counting up, collecting one reply per hop, until the destination itself answers.
The specification describes it in the same plain terms. A packet is sent "with a Time To Live (TTL) of 1". The first hop returns an error "indicating that the packet could not be forwarded because the TTL expired", and "this process continues until the destination is reached".
The whole tool rests on an optional message
The reply that makes traceroute possible has been optional since 1981. The rule is short. If a router finds the hop limit at zero "it must discard the datagram", and it "may also notify the source host via the time exceeded message". Discarding is required. Telling you is not.
Routers are also told to hold back. The router requirements say a router "SHOULD also be able to limit the rate at which it sends other sorts of ICMP error messages". Time exceeded is on that list by name. A hop that stays silent is usually a router declining to answer, not a router that is broken.
| The line shows | What that means | What it does not mean |
|---|---|---|
| An address and a time | That router answered your expiring packet | That your traffic waits there |
| A star | That router chose not to answer | A lost packet or a broken path |
| A rising time | The reply came from further away | That the delay starts at this hop |
Why the middle of the list lies
The times on each line are round trips to that router and back, so they describe the reply path as much as the outbound one. The 1993 specification lists the problem itself: the method "does not trace the return path, which may differ from the outbound path". A hop that looks slow may be a router that answers slowly, on a route home you cannot see.
Two more things bend the picture. The path can change while the trace is running, because each hop is a separate packet. And inside a carrier the hops may be carrying labels rather than plain addresses. An extension exists so those routers can say so.
What one honest trace looks like
On 20 September 2026 we ran a trace from our own server in Germany to each of the thirteen root name servers, five packets per hop. Twelve of the thirteen answered at the end. The routes took 9 hops at the median, with the shortest at 6 and the longest at 16, for a service that exists at thousands of sites.
The gaps were ordinary. Of 111 hops shown, 8 stayed silent, which is 7.2 percent. Not one intermediate hop answered some packets and dropped others, which is the point: the silent hops are consistently silent, so they are policy rather than a fault. Round trips to the end ran from 3.7 to 236.6 milliseconds, with a median of 13.7. The same service, from the same machine, differs by a factor of sixty depending on which instance answers.
| What we counted | Result |
|---|---|
| Destinations reached | 12 of 13 |
| Hops shown, median | 9 (from 6 to 16) |
| Hops that answered nothing | 8 of 111, or 7.2 percent |
| Hops with partial loss | None |
| Round trip to the end | 3.7 to 236.6 ms, median 13.7 |
Using it when a proxy feels slow
A trace is a hypothesis, not a verdict. It can show that an exit sits far from the target, or that the route leaves the country before coming back, and both are worth knowing. It cannot tell you which direction is slow, and it cannot prove a loss that only intermediate hops report.
It also does not follow your proxy. Running it on your own machine traces your path to the proxy, not the proxy's path to the target, and a proxy terminates the connection rather than forwarding your packets. To learn what the second half costs, measure the time to the target through the proxy and compare exits.
How HProxy handles it
The number that decides your work is the time to your target through the exit you will use, which is what our speed test measures. A trace is useful for forming a guess about why one exit is slower, and we would rather you measured the thing itself.
Frequently asked questions
What is traceroute?
A tool that lists the routers between you and a destination. It sends packets with a rising hop limit, and each router that discards one reports back.
Why do some hops show stars?
Because answering is optional and routers are told to limit how many error messages they send. A silent hop is usually a policy, not a fault.
Does a star mean packet loss?
No. It means that router did not reply to the expiring packet. Your actual traffic passes through it untouched, and in our own trace not one hop dropped only part of the packets.
Why is one hop in the middle slower than the destination?
Each time is a round trip to that router, including its reply path, and that path can differ from the one your traffic takes. A busy router can also answer slowly while forwarding quickly.
Can traceroute show the return path?
No, and the specification says so. It traces the outbound path only, and the way back may be different.
What is the difference between traceroute and mtr?
mtr repeats the trace and reports loss and timing per hop over many rounds, which makes a consistently silent hop easy to tell apart from an intermittent one.
Does traceroute work through a proxy?
Not usefully. A proxy terminates your connection and opens its own, so a trace from your machine stops at the proxy and says nothing about the path beyond it.
How many hops is normal?
In our trace to the root name servers the median was 9, with a range of 6 to 16. A different vantage point would give different numbers.
Sources
- RFC 792: Internet Control Message Protocol, IETF Internet Standard (J. Postel), 1981-09.
- RFC 1393: Traceroute Using an IP Option, IETF Experimental (G. Malkin, Xylogics), 1993-01.
- RFC 1812: Requirements for IP Version 4 Routers, IETF Standards Track (F. Baker, Ed.), 1995-06.
- RFC 4950: ICMP Extensions for Multiprotocol Label Switching, IETF Standards Track (R. Bonica, D. Gan, D. Tappan, C. Pignataro), 2007-08.
- Thirteen traces to the root name servers from our own server, HProxy measurement, 2026-09-20.
Back to the full glossary.