traceroute network
find out exactly where the network is broken.
The traceroute man page is 500 lines long. You need one command and it shows you every router between you and a destination — and exactly where things go wrong.
You pinged a server. It was slow. Or it was unreachable. You know there’s a problem. But the internet isn’t a direct wire between you and the server — your packets hop through 10, 15, sometimes 20 routers on the way. Any one of them could be the problem.
So you called your ISP. “My internet is slow.” They said “have you tried restarting your router?” You restarted your router. Nothing changed. They said “we’ll look into it.” They didn’t. Three days later it fixed itself. You’ll never know what happened.
traceroute would have told you in fifteen seconds. It shows every hop your packets take and how long each one takes. Hop 1 through 5 at 5ms? Fine. Hop 6 suddenly jumps to 400ms? That’s the problem. That’s the router. Now you can call your ISP and say “your router at hop 6 is adding 395ms of latency” and watch them actually take you seriously.
Unless you’re running Windows then wtf none of this applies to you. But hey, come to the dark side, go install WSL2 and you can follow along. We’ll wait. Impatiently.
If you’re lazy like me (all sysadmins are!) then click here for the traceroute cheat sheet.
Trace the route
traceroute google.com
traceroute to google.com (142.250.80.46), 30 hops max, 60 byte packets
1 router.local (192.168.1.1) 1.234 ms 1.102 ms 0.987 ms
2 isp-gateway.example (10.0.0.1) 5.432 ms 5.211 ms 5.098 ms
3 core-router.isp.net (203.0.113.1) 12.345 ms 11.987 ms 12.102 ms
4 peering.isp.net (198.51.100.1) 15.678 ms 14.890 ms 15.234 ms
5 google-edge.1e100.net (74.125.x.x) 5.432 ms 5.211 ms 5.098 ms
6 lax17s55-in-f14.1e100.net (142.250.80.46) 5.123 ms 5.098 ms 5.234 ms
Each line is a hop — a router your packet passes through. Three timing measurements per hop (three probes sent). The numbers are round-trip latency to that hop.
Reading the output
- Hop 1 — your local router/gateway
- Middle hops — your ISP’s network, then transit networks
- Last hop — the destination
- Times increasing gradually — normal. Each hop adds a bit of latency
- Sudden spike — that hop is slow. Could be congestion, a bad router, or geographic distance
* * *— that router didn’t respond. Could be firewalled (not necessarily broken)
Find the problem hop
3 core-router.isp.net 12.345 ms 11.987 ms 12.102 ms
4 congested-router.isp.net 245.678 ms 312.890 ms 198.234 ms
5 next-hop.peer.net 248.432 ms 310.211 ms 200.098 ms
Hop 3: 12ms. Hop 4: 245ms. That’s where the latency spike happens. Everything after hop 4 is slow because it’s downstream of the problem. Hop 4 is your bottleneck.
If you see this pattern, the problem is in your ISP’s network (or the transit network between them). Call them. Give them the traceroute output. They can actually do something with it.
Stars (***) don’t always mean broken
5 * * *
6 * * *
7 google-edge.net 5.432 ms 5.211 ms 5.098 ms
Hops 5 and 6 didn’t respond to traceroute probes, but hop 7 (the destination) is fine. Those routers are configured to ignore traceroute packets — it’s a security or performance choice. The path works. Don’t panic at stars.
Stars at the end, with no final response? The destination is unreachable or blocking traceroute.
Use TCP instead of UDP
sudo traceroute -T google.com
Default traceroute uses UDP. Some firewalls block UDP but allow TCP. -T sends TCP SYN packets instead — more likely to get through corporate firewalls.
sudo traceroute -T -p 443 google.com
TCP traceroute on port 443 (HTTPS). Almost nothing blocks port 443.
Use ICMP (like Windows tracert)
sudo traceroute -I google.com
Uses ICMP echo requests — the same protocol as ping. Some networks handle ICMP differently than UDP.
Don’t resolve hostnames
traceroute -n google.com
Skip DNS reverse lookups for each hop. Faster output, especially when some hops have slow or broken reverse DNS. The IPs are often more useful than the hostnames anyway.
Set max hops
traceroute -m 15 google.com
Default is 30 hops. If the destination is closer, reduce it to speed things up. If you’re tracing something far away or through many networks, you might need to increase it.
mtr: traceroute on steroids
If you want continuous monitoring instead of a one-shot trace:
mtr google.com
mtr combines ping and traceroute into a live, continuously updating display. It shows every hop with real-time packet loss and latency statistics. It’s the best network diagnostic tool most people don’t know about.
mtr -r -c 100 google.com
Report mode — runs 100 cycles and prints a summary. Perfect for pasting into a support ticket or an email to your ISP.
Install it if you don’t have it:
sudo apt install mtr
sudo dnf install mtr
The flags that actually matter
| Flag | What it does |
|---|---|
-n |
Don’t resolve hostnames. Faster output. |
-m N |
Set max hops (default 30). |
-w SECS |
Wait N seconds for a response per hop. |
-q N |
Send N probes per hop (default 3). |
-T |
Use TCP instead of UDP (requires sudo). |
-I |
Use ICMP instead of UDP (requires sudo). |
-p PORT |
Use a specific port (with -T). |
-f N |
Start at hop N (skip earlier hops). |
“But I just—”
Sure.
“I use the visual traceroute on whatsmyip.com.” A visual traceroute that shows your packets bouncing across a world map is cool to look at. It’s also wildly inaccurate because IP geolocation databases are wrong about 30% of the time, and the animation adds nothing to your diagnosis. The text output tells you latency at each hop. That’s what matters.
“Windows has tracert.” Correct. tracert uses ICMP by default (which is fine) but can’t switch to TCP or UDP, offers fewer options, and is slower because it resolves DNS for every hop by default. Linux’s traceroute and especially mtr are more flexible tools.
“My ISP said the problem isn’t on their end.” Show them the traceroute. If the latency spike happens at their router, the evidence is right there. Traceroute output is the closest thing to proof you’ll get without access to their infrastructure. It’s hard to argue with “your router at hop 4 is adding 300ms.”
“I just restart my router.” Restarting the router fixes problems between your device and the router. If the problem is at hop 7 — three networks away — restarting your router does nothing except waste ninety seconds of your life. Traceroute tells you whether the problem is local or upstream before you unplug anything.
traceroute cheat sheet
You made it. Or you skipped straight here. Either way, no judgment. Copy and paste these. Pin them. Tattoo them on your forearm. Whatever works.
| What you’re doing | Command |
|---|---|
| Basic trace | traceroute google.com |
| No DNS resolution (faster) | traceroute -n google.com |
| TCP traceroute (bypasses firewalls) | sudo traceroute -T google.com |
| TCP on port 443 | sudo traceroute -T -p 443 google.com |
| ICMP traceroute | sudo traceroute -I google.com |
| Limit to 15 hops | traceroute -m 15 google.com |
| Live monitoring (mtr) | mtr google.com |
| mtr report for support ticket | mtr -r -c 100 google.com |
The diagnostic flow: ping says “it’s slow.” traceroute says “hop 6 is where it gets slow.” Now you know who to call and what to tell them.