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.

This page has distro-specific commands. Pick your poison:
Set it and forget it. Like your firewall rules. Wait—

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.

Back to the top, you overachiever.