The traceroute Command — Network Path Tracing
Overview
traceroute maps the network path from your machine to a destination by sending packets with incrementally increasing TTL (Time to Live) values. Each network hop along the route responds, revealing the routers and networks your traffic passes through. This helps pinpoint where latency or packet loss occurs.
Basic Syntax
traceroute [options] hostname_or_IP
Basic Usage
traceroute example.com
Sample output:
traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
1 gateway (192.168.1.1) 1.234 ms 0.987 ms 1.102 ms
2 isp-router.net (10.0.0.1) 5.432 ms 5.210 ms 5.678 ms
3 core-router.isp.net (172.16.0.1) 12.345 ms 11.987 ms 12.123 ms
4 * * *
5 peer-router.cdn.net (198.51.100.1) 15.678 ms 14.890 ms 15.234 ms
6 example.com (93.184.216.34) 18.456 ms 17.890 ms 18.012 ms
Understanding the Output
Each line represents one hop (a router or network device along the path):
| Field | Meaning |
|---|---|
| Hop number | Sequential position in the route (1 = nearest to you) |
| Hostname/IP | The router or device at this hop |
| Three time values | Round-trip time for each of the 3 probe packets sent |
* * * | No response from this hop (see below) |
What * * * means
Stars indicate the hop didn’t respond. This can mean:
- The router is configured to not respond to traceroute packets (very common)
- A firewall is blocking the probe
- It does NOT necessarily mean there’s a problem — many routers silently forward traffic without responding to traceroute
Only be concerned if you see stars at the end (destination unreachable) or if subsequent hops show high latency.
Reading the Results
Healthy trace
Times gradually increase as you move further from your origin. A few milliseconds per hop is normal.
Latency spike at a specific hop
3 router-a.net 12.3 ms 11.8 ms 12.1 ms
4 router-b.net 85.6 ms 84.2 ms 86.1 ms ← Big jump here
5 router-c.net 86.0 ms 85.4 ms 85.8 ms
If the high latency continues for all subsequent hops, the bottleneck is at hop 4. If it returns to normal, hop 4 might just be deprioritizing traceroute responses.
Trace never completes
If the trace shows * * * for the final hops and never reaches the destination, the target may be blocking traffic or there’s a routing issue.
Useful Flags
| Flag | Description |
|---|---|
-n | Don’t resolve hostnames (faster output) |
-m N | Set maximum number of hops (default: 30) |
-w N | Wait N seconds for each response (default: 5) |
-q N | Send N probes per hop (default: 3) |
-I | Use ICMP instead of UDP (may bypass some firewalls) |
-T | Use TCP SYN packets (often works through firewalls) |
-p PORT | Set the destination port |
Use ICMP for better results through firewalls
sudo traceroute -I example.com
Skip DNS resolution for faster output
traceroute -n example.com
traceroute vs. mtr
| Feature | traceroute | mtr |
|---|---|---|
| Output | One-time snapshot | Continuous, updating display |
| Packet loss stats | No | Yes — per-hop loss % |
| Best for | Quick check | In-depth diagnostics |
| Availability | Pre-installed on most systems | May need to be installed |
For ongoing network issues, mtr (My Traceroute) provides more comprehensive data. See the related article on the mtr command.
Practical Examples
Trace the route to your website
traceroute yourdomain.com
Trace with only 10 hops
traceroute -m 10 yourdomain.com
TCP-based trace (firewall-friendly)
sudo traceroute -T -p 443 yourdomain.com
Tips
- Run traceroute from both directions (your machine → server, and server → your machine) to identify asymmetric routing issues.
- If
tracerouteis not installed, usesudo apt install traceroute(Debian/Ubuntu) orsudo yum install traceroute(CentOS/RHEL). - When reporting network issues to your hosting provider, include the full traceroute output — it helps support teams identify the problem quickly.