TRACEROUTE
traceroute is a network diagnostic tool used to map the path that packets take from your machine to a destination host. It helps identify where latency increases, where packets are dropped, or which network segment is responsible for routing problems.
It is commonly used during:
- Connectivity troubleshooting (cannot reach a host/service)
- Performance investigations (high latency, intermittent network issues)
- ISP or data center routing analysis
- CDN edge problems (unexpected paths, long routes)
It shows each “hop” (router/gateway) along the route and the round-trip time (RTT) to reach that hop.
The displayed route is not always the exact path used by all traffic. Some networks use load balancing, asymmetric routing, or filtering that can alter results.
How traceroute Works
Traceroute discovers hops by sending packets with increasing TTL (Time To Live). Each router that decrements TTL to zero responds with an ICMP “Time Exceeded” message. By increasing TTL from 1 upward, traceroute learns each hop in sequence.
Installation
Ubuntu / Debian
sudo apt update
sudo apt install traceroute -y
RHEL / CentOS / Rocky / AlmaLinux
sudo dnf install traceroute -y
macOS
Traceroute is typically already available:
traceroute -n example.com
Basic Usage
Trace a route to a domain
traceroute example.com
Trace a route to an IP address
traceroute 8.8.8.8
Numeric output only (no DNS lookup)
This is faster and avoids DNS confusion:
traceroute -n example.com
Understanding the Output
Example output:
traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
1 192.168.1.1 1.123 ms 1.050 ms 1.010 ms
2 10.10.0.1 5.250 ms 5.112 ms 5.081 ms
3 203.0.113.1 15.920 ms 16.100 ms 15.870 ms
4 93.184.216.34 20.340 ms 20.210 ms 20.180 ms
Key fields
| Field | Meaning |
|---|---|
| - | -- |
| Hop number | Router index along the path |
| Host/IP | Router identity (may be a hostname or IP) |
| Three RTT values | Three probe round-trip times (ms) |
Common Flags and Options
| Option | Meaning | Example |
|---|---|---|
| -- | -- | |
-n | Do not resolve DNS names | traceroute -n 8.8.8.8 |
-m <hops> | Max hops | traceroute -m 15 example.com |
-q <count> | Probes per hop | traceroute -q 1 example.com |
-w <sec> | Wait time per probe | traceroute -w 2 example.com |
-I | Use ICMP echo (instead of UDP) | traceroute -I example.com |
-T | Use TCP SYN probes (often best through strict firewalls) | traceroute -T -p 443 example.com |
-p <port> | Destination port (works with UDP/TCP modes) | traceroute -T -p 443 example.com |
-s <ip> | Source address | traceroute -s 192.0.2.10 example.com |
When diagnosing web access problems, TCP traceroute to port 443 often produces the most realistic path:
traceroute -T -p 443 -n example.com
UDP vs ICMP vs TCP Traceroute
Different probe types change what devices respond.
| Mode | Command | When to use |
|---|---|---|
| -- | - | |
| UDP (default on many Linux distros) | traceroute example.com | General path discovery, may be filtered by firewalls |
| ICMP | traceroute -I example.com | When UDP is blocked; closer to ping behavior |
| TCP | traceroute -T -p 443 example.com | Best when diagnosing access to a specific service (HTTPS) |
Interpreting Special Cases
1) * * * at a hop
Example:
5 * * *
Meaning:
- No reply from that hop for the probe(s)
Common reasons:
- Firewall blocks traceroute probes
- Router rate-limits ICMP responses
- MPLS/VPN segments hiding internal hops
If later hops respond, the route is still working.
2) Latency jump at a hop
Example: RTT increases from 20 ms to 180 ms and stays high afterward.
Interpretation:
- Congestion or long-distance routing after that hop
- A routing change that moved traffic to a farther path
- A peering/ISP issue
If latency jumps at hop N but returns to normal at hop N+1, it may be probe rate limiting (not real latency).
Ping the destination and compare:
ping -c 10 example.com
3) Different results across runs
Possible causes:
- Load-balanced routes (ECMP)
- CDN anycast routing changes
- ISP routing changes
Run multiple times and compare:
traceroute -n example.com
traceroute -n example.com
Practical Use Cases
A) Diagnose slow website access (HTTPS)
traceroute -T -p 443 -n yourdomain.com
What to look for:
- Large latency jumps before reaching the hosting network
- Timeouts within ISP or transit provider hops
- Unexpected detours across regions
B) Compare routing from server to external service
From your VPS:
traceroute -n 8.8.8.8
Use this to:
- Identify outbound routing problems
- Validate data center connectivity
- Compare with your local traceroute results
C) Confirm whether the problem is local, ISP, or server-side
Run traceroute from:
- Your local network
- A different ISP (mobile tether)
- The server itself (outbound)
If only one network shows problems, it is likely local/ISP routing.
Troubleshooting Workflow
- Confirm basic connectivity:
ping -c 4 destination
- Trace route (no DNS):
traceroute -n destination
- Trace using TCP to target service port:
traceroute -T -p 443 -n destination
- If destination is a server you control, check service listen state:
sudo ss -tulpn | grep -E ':22|:80|:443'
- Check firewall rules:
sudo ufw status verbose
Related Tools
| Tool | Best For |
|---|---|
| -- | |
ping | Basic reachability and packet loss to a host |
mtr | Continuous traceroute with loss/latency statistics |
ss / netstat | Confirm local ports/services are listening |
dig / nslookup | DNS resolution validation |
For a combined real-time view of hops, latency, and loss:
mtr -n destination