Traceroute Troubleshooting: Find Where the Path Breaks
Traceroute answers one question: Where does the path change? When a ticket says “slow,” “timeouts,” or “works from office but not from home,” traceroute helps you separate local issues, ISP routing problems, and remote-side filtering—fast.
If you only remember one rule: don’t panic at asterisks. Timeouts are often rate limiting, not failure. The trick is correlating hops with latency changes and end-to-end results.
When traceroute is the right tool
- Latency spikes: “VPN is slow,” “SaaS feels laggy,” “VoIP jitter.”
- Intermittent drops: sessions reset, RDP freezes, game rubber-banding.
- Regional failures: works on LTE but not home ISP, or only some sites break.
- Routing suspicion: traffic hairpins to another city/region unexpectedly.
If your issue is “domain won’t resolve,” start with DNS Lookup. If your issue is “service won’t accept connections,” jump to Port Scanner.
How traceroute actually works (so the output makes sense)
Traceroute sends probes with increasing TTL (Time To Live). Each router that decrements TTL to zero may return an ICMP “time exceeded” message. That’s how you get a hop list.
Two important implications:
- Hops can “disappear” if a router doesn’t respond to TTL-expired probes (rate limiting or policy). Your traffic may still be forwarding fine.
- ICMP response timing ≠ forwarding timing. A hop can reply slowly while forwarding at line-rate. Your primary truth is the destination result and the latency shift that persists to the end.
Fast workflow (what senior engineers do)
1) Prove the target and baseline RTT
- Confirm the hostname resolves to the expected IP.
- Establish baseline latency and jitter before blaming the path.
2) Run traceroute and mark the “inflection hop”
- Find the first hop where latency jumps and stays elevated.
- Ignore one-off spikes that don’t continue to later hops.
- Don’t over-index on asterisks unless the destination also fails.
3) Determine if this is local, ISP, transit, or destination-side
- Local: jump begins on hop 1–2 (gateway/Wi-Fi).
- ISP: jump begins at ISP edge/metro hops.
- Transit: jump begins mid-path and persists.
- Destination: last hops inflate or destination times out.
How to read common traceroute patterns
Pattern A: Asterisks in the middle, but destination is fine
Usually ICMP rate limiting or a router configured not to respond. If the destination hop has consistent RTT and packet loss isn’t increasing end-to-end, treat this as normal noise.
Pattern B: Latency jumps at hop N and stays high through the destination
That hop (or the link after it) is your likely congestion point. The key is persistence: if hop N is high and hop N+1 through the destination remain similarly high, you have a real path shift.
Validate with continuous measurement: Ping Monitor.
Pattern C: One hop is high, later hops are normal
Classic “slow ICMP responder.” That router prioritizes forwarding over generating TTL-expired responses. Ignore it unless the destination is also impacted.
Pattern D: Destination times out, but earlier hops reply
Common causes:
- Destination blocks ICMP/traceroute probes.
- A firewall drops TTL-expired responses near the destination.
- Service is down or not reachable from your region.
If you’re troubleshooting an application port, validate reachability with Port Scanner.
Pattern E: First hop is already bad
If hop 1 (your gateway) is high or lossy, stop. That’s LAN/Wi-Fi, local CPU saturation, bufferbloat, or a bad edge device. Fix local before escalating to ISP.
Advanced: the issues traceroute hints at (but won’t “prove” alone)
Asymmetric routing
Traceroute shows the forward path of the probes, not necessarily the return path of your application traffic. You can see “weird geography” (hairpinning) that suggests asymmetry. The best confirmation is testing from another source (cell hotspot, office, another region) and comparing.
MPLS / hidden hops
Many ISP cores obscure internal hops or reply from loopbacks that don’t map cleanly to geography. Don’t fight it—your job is to isolate where the behavior changes, not to label every router.
MTU black hole symptoms
If small pings work but HTTPS stalls, VPN connects but data hangs, or some sites partially load, think MTU. Traceroute may show the “region” where it breaks, but you’ll need MTU-specific tests in your environment.
Policy routing and CDN steering
CDNs can steer you to different PoPs depending on resolver, ASN, or geo. If the hostname resolves to different endpoints from different ISPs, start with: DNS Lookup and compare results.
Escalation checklist (copy/paste for tickets)
- Target: hostname + resolved IP(s)
- Time window: exact timestamps and timezone
- Symptom: high latency / loss / timeouts / app resets
- Baseline: normal RTT and current RTT
- Inflection hop: first hop where latency jumps and persists
- Evidence: traceroute output + continuous ping/jitter chart
- ISP context: ASN/org and suspected region