What Traceroute Actually Shows
Traceroute sends packets toward a destination with a controlled TTL (Time To Live) value, starting at 1 and incrementing by one each round. Each router along the path decrements the TTL; when TTL reaches zero, the router sends back an ICMP "time exceeded" message that reveals its IP address and the round-trip time to that hop. The result is a numbered list of every publicly visible router between you and the destination, with latency measurements at each step.
The most important principle for reading traceroute output: you are looking for where a pattern begins, not for the highest single number. A hop showing 200 ms is meaningless in isolation. A hop showing 200 ms where every previous hop showed 10–15 ms — and all subsequent hops also show 200 ms — is a clear indication that the problem started at that hop.
Running Traceroute
# macOS / Linux — run to a stable target, save output
traceroute 1.1.1.1
traceroute 8.8.8.8
# Windows — same concept, different command name
tracert 1.1.1.1
tracert 8.8.8.8
# Also trace to the actual slow destination for comparison
traceroute slow-site-or-game-server.example.comAlways run traceroute twice: once to a stable reference target (1.1.1.1 is ideal — it is close, well-routed, and consistent) and once to the actual destination you are experiencing problems with. The difference between the two traces locates the problem much faster than either trace alone.
Reading the Output: A Field Guide
| What You See | What It Means | What to Do |
|---|---|---|
| Hop 1 has high latency (20+ ms on a wired connection) | Problem is in your LAN — overloaded router CPU, a slow Wi-Fi link, or a congested switch port | Test on Ethernet; reboot router; check router CPU in admin page |
| Hops 2–3 show a sudden jump that persists through all later hops | Problem begins at your ISP's first or second router — access line congestion, modem signal issue, or ISP node problem | Check modem signal levels; run MTR for packet loss; contact ISP with the trace |
| One hop in the middle shows high latency, but the next hop and beyond return to normal | That middle hop is deprioritizing ICMP responses — this is not real latency affecting your traffic; it is router policy | Ignore it; look at the overall pattern across the full trace |
| Hops show * * * (three asterisks, no response) | The router at that hop is blocking ICMP; the hop may still be forwarding your real traffic normally | Check whether later hops respond; if the destination is reachable, the * hops are just filtering ICMP |
| Trace stops completely mid-path (all remaining hops are * * *) | A firewall is blocking all ICMP beyond that point, or packets are being dropped starting at that hop | Try using a different probe protocol: traceroute -T (TCP) or traceroute -U (UDP) on Linux/macOS |
| Final destination latency is much higher than a nearby hop | The destination server or its CDN has added processing time, or there is congestion near the destination | The problem is at or near the server end — not your ISP |
MTR: Traceroute with Packet Loss Measurement
Standard traceroute fires a fixed number of probes and reports the results once. MTR (Matt's Traceroute / My Traceroute) runs continuously, measuring latency and packet loss at every hop in real time. For diagnosing intermittent problems — especially packet loss — MTR is more useful than traceroute because it builds a statistical picture over many probe cycles.
# macOS / Linux — run 100 cycles and save to a text file
mtr --report --report-cycles 100 1.1.1.1 > mtr-report.txt
# Windows — use WinMTR (free download), set host to 1.1.1.1, run 100 cycles, export as textIn the MTR output, look at the "Loss%" column for each hop. Real packet loss appears at a hop and stays at that level or higher for all subsequent hops. Loss that appears at one hop but disappears at the next is ICMP deprioritization — not real loss affecting your actual traffic.
A Real-World Example
Here is a simplified annotated traceroute showing what a real ISP-side problem looks like:
Hop Host Latency
1 192.168.1.1 2 ms ← Your router (LAN is fine)
2 10.0.0.1 8 ms ← ISP CMTS/DSLAM (access line is fine)
3 72.14.x.x 9 ms ← ISP backbone router
4 74.125.x.x 180 ms ← Latency jumps here...
5 74.125.x.x 179 ms ← ...and stays elevated
6 142.250.x.x 181 ms ← ...all the way to destinationIn this trace, hops 1–3 are clean. The problem starts at hop 4 and persists — which means the issue is at or after the ISP's core routing, not in the home network. This trace, saved with a timestamp, is evidence worth sending to the ISP's network operations team.
Frequently Asked Questions
Why does traceroute show different results each time I run it?
Internet routing uses multiple paths, and traffic can take different routes on different runs — a technique called Equal-Cost Multi-Path (ECMP) routing. Routers also load-balance across links, so each traceroute probe may traverse a different physical path. Running traceroute three times in succession and looking for consistent patterns is more useful than interpreting any single run. If all three runs show the same elevated latency at the same hop, that pattern is real.
Should I run traceroute on Wi-Fi or Ethernet?
Always run it on Ethernet when diagnosing ISP or routing issues. Wi-Fi adds variable latency at hop 1 that can obscure the rest of the trace. A hop 1 latency of 2 ms means your LAN is fine; a hop 1 latency of 25 ms on Wi-Fi tells you nothing about what the ISP is doing. Once you have a clean Ethernet baseline, you can run the same trace on Wi-Fi and compare hop 1 to see how much the wireless link is adding.
When should I contact the ISP with a traceroute?
Contact the ISP when you have multiple traceroutes saved across different times — especially during your problem window — that consistently show elevated latency or packet loss starting at hop 2 or 3 (your ISP's first routers). A single trace is easy to dismiss. Three or more traces with the same pattern at the same hop, timestamped during the problem period, are much harder to dismiss. Pair the traces with MTR packet-loss output and modem signal level screenshots for maximum impact.