Traceroute — tracert on Windows — maps every router your data passes through on its way to a destination, and times each step. Where ping tells you whether something is slow, traceroute tells you where.
It’s the single most useful tool for answering “is this my connection, my ISP, or the website?” — and it’s also one of the most consistently misread. Most of this guide is about interpreting the output correctly, because the output invites two or three specific wrong conclusions that even experienced people jump to.
Key Takeaway:
Only the final hop’s latency reflects your actual experience. A scary-looking spike in the middle of a traceroute is usually a router deprioritising your probe, not a problem with your connection.
How Traceroute Works
The mechanism is a clever abuse of a safety feature.
Every packet carries a TTL (Time To Live) — a counter that each router decrements by one as it forwards the packet. It exists to stop packets circulating forever if routing goes wrong. When TTL hits zero, the router discards the packet and sends back an ICMP “Time Exceeded” message identifying itself.
Traceroute weaponises that:
- Send a packet with TTL=1. The first router decrements it to zero and reports back — now you know hop 1.
- Send one with TTL=2. It clears the first router, dies at the second, which reports back — hop 2.
- Keep incrementing until the destination replies instead of a router, or you hit the limit (usually 30 hops).
Three probes are sent per hop, which is why you see three timings on each line. Each hop’s IP address is a real router on the internet — you can look them up, and they’ll often reveal which network you’re crossing. See what an ASN is for how those networks are identified.
How to Run It
| System | Command |
|---|---|
| Windows | tracert example.com — Command Prompt |
| macOS / Linux | traceroute example.com — Terminal |
| Better option | mtr example.com — continuous, combines ping and traceroute |
| Android / iOS | Needs a network utility app — not built in |
One detail that causes confusion: Windows tracert sends ICMP probes, while the standard Unix traceroute sends UDP packets by default. Some networks treat these differently, so the same route can produce different-looking results on different machines. Add -I on Linux to force ICMP and match Windows behaviour.
If you’re troubleshooting seriously, use mtr. It runs continuously and shows loss percentages per hop, which turns a single snapshot into an actual pattern.
Reading the Output
A typical result looks like this:
1 1 ms 1 ms 1 ms 192.168.1.12 9 ms 8 ms 10 ms isp-gateway.example.net3 * * * Request timed out4 185 ms 12 ms 11 ms core-router.example.net5 14 ms 13 ms 14 ms example.com
Hop 1 is your own router. Hop 2 is your ISP. The final hop is your destination, and its timing is the only one that describes your actual experience.
| What You See | What It Actually Means |
|---|---|
* * * mid-route | ✅ Usually fine — that router just doesn’t reply to probes |
| One high hop, normal after | ✅ Fine — that router deprioritised your probe |
| High from hop X to the end | ⚠️ Real — the problem starts at hop X |
* * * all the way to the end | ⚠️ Route fails there, or the destination filters probes |
| High latency at hop 1 or 2 | ⚠️ Your own network or ISP line |
| Same IP repeating | ⚠️ Possible routing loop |
⚠️ The Three Big Misreadings
Almost every incorrect traceroute diagnosis is one of these.
1. Treating * * * as packet loss
It isn’t. Asterisks mean the router didn’t send back a Time Exceeded message — which is entirely normal. Many routers rate-limit or block ICMP responses deliberately, or a firewall filters them. Your actual traffic passed through perfectly. If later hops respond normally, that hop is fine by definition — the packets clearly got past it.
2. Panicking at a mid-route latency spike
The most common error. A router showing 185 ms while the next hop shows 12 ms is not a bottleneck. Routers handle forwarding in dedicated hardware but generate ICMP replies on a slow management processor, and that reply is treated as low priority. The high number reflects how quickly the router could be bothered to answer you — not how fast it forwards data. If the hops after it are fast, there is no problem.
3. Forgetting the return path
Each timing is a full round trip, but traceroute only shows you the outbound route. The return journey can take a completely different path, and internet routing is frequently asymmetric. So a slow hop might actually be slow coming back, over routers you can never see from your end. This is why a single traceroute is evidence, not proof.
Ping vs Traceroute vs MTR
| Tool | Answers | Use When |
|---|---|---|
| ping | Is it reachable, and how slow? | First check, always |
| traceroute | Where in the path is the problem? | After ping confirms an issue |
| mtr | Is it consistent, and where’s the loss? | Intermittent problems |
The sequence that actually works: ping to confirm something is wrong, traceroute to locate it, mtr to prove it’s persistent rather than a one-off.
Practical Uses
- Game lag. Traceroute to the game server. High latency from hop 2 onward points at your ISP; a spike only near the destination is the game’s own network.
- One site is slow, others fine. Compare a traceroute to the slow site against one to a fast site. Where the paths diverge is where to look.
- Evidence for your ISP. Run mtr for a few minutes and send the output. Consistent loss starting at one of their hops is far harder to dismiss than “my internet feels slow.” Useful alongside throttling checks.
- Seeing where your traffic physically goes. Hop hostnames often encode city codes, so you can watch traffic cross countries. Related: IP geolocation.
- Checking a VPN’s real route. With a VPN connected, your first hops become the tunnel — a quick way to confirm traffic really is being redirected.
Limitations Worth Knowing
- Load balancing scrambles results. Large networks spread traffic across parallel paths, so consecutive probes can take different routes and produce inconsistent hops. Tools like
paris-tracerouteexist specifically for this. - It only shows the outbound path. As above — half the journey is invisible.
- CGNAT adds hops you don’t control. Behind carrier-grade NAT, early hops belong to your ISP’s internal network.
- Some destinations block it entirely, so the final hops read as timeouts even though the site loads fine.
- It’s a snapshot. Network conditions shift minute to minute. One traceroute during a problem proves little on its own.
Frequently Asked Questions
Why do I see stars (* * *) in my traceroute?
That router chose not to reply to your probe — usually rate-limiting or a firewall policy. It’s normal, and it doesn’t mean your data was dropped. If the hops after it respond, your packets clearly passed through.
One hop shows 200 ms. Is that my problem?
Only if every hop after it is also slow. A single spike that returns to normal is the router deprioritising your probe, not a bottleneck. Read the trend, never a single line.
How many hops is normal?
Typically 8 to 20 for most destinations. More isn’t inherently worse — a well-routed 20-hop path can easily beat a poorly-routed 8-hop one.
Does traceroute work through a VPN?
Yes, but the path starts from the VPN server rather than your home connection. That’s actually a useful way to verify your traffic is genuinely being tunnelled.
Is running traceroute against a website legal?
Yes. It’s a standard diagnostic that sends a handful of ordinary packets — no different in nature from loading the site. Every network engineer uses it daily.
Why does the last hop time out even though the site works?
Many servers and their firewalls are configured not to answer probe packets while happily serving normal traffic. The site is fine; it just won’t talk to traceroute.
Should I use tracert or traceroute?
Whichever your system provides — tracert on Windows, traceroute on Mac and Linux. They do the same job with slightly different default probe types, which can occasionally produce different-looking output for the same route.
What should I send my ISP?
Run mtr for several minutes toward a well-known destination and send the full output, with timestamps and a note about what you were doing. Sustained loss beginning at one of their own hops is concrete and difficult to wave away.