The traceroute command shows the path your network traffic takes to reach a destination. It lists every router (hop) along the way and how long each one takes to respond, which helps you find where a connection slows down or stops working.
This is part 4 of my Linux networking series. If you missed the earlier posts, start with Linux dig Command: 5 Examples Every Developer Should Know, then read the nslookup and ping posts.
1. Install traceroute
traceroute is often not installed by default. On Debian/Ubuntu:
sudo apt update sudo apt install traceroute 2. Trace the Route to a Domain
traceroute google.com The output looks like this (addresses and times will differ on your network):
traceroute to google.com (142.250.x.x), 30 hops max, 60 byte packets 1 _gateway (192.168.1.1) 1.2 ms 1.1 ms 1.0 ms 2 10.20.0.1 8.4 ms 8.1 ms 8.3 ms 3 * * * 4 ... - Each numbered line is one hop, meaning one router on the path.
- The three times are the round-trip times for three probe packets sent to that hop.
-
* * *means that hop did not reply within the timeout. It is common, because many routers are set to ignore these probes, and it does not always mean a problem.
3. Skip DNS Lookups with -n
traceroute -n google.com By default, traceroute tries to resolve each hop's IP address to a hostname, which can slow things down. The -n option shows IP addresses only, so the trace runs faster and the output is easier to copy into a bug report.
4. Control Hops, Timeout, and Probes
Limit the maximum number of hops (the default is 30):
traceroute -m 15 google.com Wait only 2 seconds for each reply (the default is 5):
traceroute -w 2 google.com Send 1 probe per hop instead of 3 for a shorter, faster trace:
traceroute -q 1 google.com You can combine them:
traceroute -n -m 15 -w 2 -q 1 google.com 5. Use ICMP or TCP Instead of UDP
By default, traceroute on Linux sends UDP packets. Some firewalls block these, so you may see many * * * lines. Try another method:
sudo traceroute -I google.com -I uses ICMP echo requests, the same kind of packet that ping sends.
sudo traceroute -T -p 443 google.com -T uses TCP, and -p 443 sets the destination port. Since HTTPS traffic is rarely blocked, a TCP trace to port 443 often gets further than the default.
Both options need sudo.
Bonus: Choose IPv4 or IPv6
traceroute -4 google.com traceroute -6 google.com Bonus: Try tracepath
tracepath is a similar tool that works without root privileges and is often already installed:
tracepath google.com How to Read the Results
| What you see | What it likely means |
|---|---|
| Latency jumps at one hop and stays high afterward | The problem starts at that hop or the link after it |
| One hop with high latency, then normal again | That router is slow to answer probes, but traffic is probably fine |
* * * on a hop, but later hops reply | That router ignores probes, which is usually harmless |
* * * on every hop from some point onward | Traffic is blocked or lost there, or a firewall drops the probes |
Conclusion
The traceroute command shows where your traffic goes and where it slows down. Use ping to check that a host is reachable, dig or nslookup to check
