How to Run a Traceroute: Diagnose Network Path Issues

What Is a Traceroute and How Does It Work?

A traceroute is a network diagnostic tool that maps the path data packets take from your computer to a destination server. Unlike a simple ping test that only tells you if a host is reachable, traceroute reveals every intermediate router (called a "hop") along the route, showing you where your traffic travels and how long each segment takes.

The tool works by sending packets with incrementally increasing Time-to-Live (TTL) values. When a router receives a packet whose TTL has reached zero, it discards it and sends an ICMP "Time Exceeded" message back to your machine. By starting with TTL=1 and incrementing with each probe, traceroute collects one response per hop until it reaches the final destination.

Each line in a traceroute output shows:

• Hop number — the sequential position in the route
• Router hostname / IP — the address of the intermediate device
• Round-trip times (RTT) — three latency measurements in milliseconds

Asterisks (* * *) appear when a router doesn't respond, which may indicate packet filtering or firewall rules — not necessarily a problem.

Running Traceroute on Windows

Windows ships with tracert (trace route), accessible from any Command Prompt or PowerShell window. The syntax is straightforward:

tracert google.com
tracert 8.8.8.8
tracert -d 8.8.8.8   # skip DNS resolution for faster results
tracert -h 30 google.com   # set max hops (default is 30)

The -d flag prevents tracert from resolving IP addresses to hostnames, which speeds up the output significantly when you only care about hop count and latency.

For more advanced analysis on Windows, tools like WinMTR or PathPing (built-in) combine ping and traceroute into a continuous report:

pathping google.com

PathPing is particularly valuable for detecting intermittent packet loss at specific hops, since it samples each hop over a longer period before displaying results. It takes around 5 minutes to complete but produces much more statistically reliable data than a single tracert run.

Running Traceroute on Mac and Linux

On macOS and Linux, the command is traceroute (not tracert). By default it uses UDP probes, whereas Windows uses ICMP. You can switch protocols with flags:

# Standard UDP traceroute
traceroute google.com

# ICMP mode (more likely to pass through firewalls)
traceroute -I google.com

# TCP mode on port 80 (best for testing through strict firewalls)
traceroute -T -p 80 google.com

# Increase probes per hop and skip DNS
traceroute -q 5 -n google.com

On Linux, mtr (Matt's Traceroute) is the preferred tool for most network engineers. It runs continuously, refreshing statistics in real time so you can observe transient packet loss:

mtr google.com
mtr --report --report-cycles 100 google.com   # generate a 100-cycle summary report

The --report flag prints a summary instead of the live display, which is useful for including traceroute data in bug reports. Always cross-reference with your current IP address so you can provide complete diagnostic context to your ISP or hosting provider.

Interpreting Traceroute Output

Understanding what the output means is as important as running the tool. Here is how to read results effectively:

• Increasing RTT at each hop — normal; latency naturally accumulates over distance.
• Sudden large RTT jump at one hop — that router (or the link leading to it) is the likely bottleneck. Cross-check with your ping test to confirm.
• RTT drops after a high hop — the high RTT was likely the router deprioritizing ICMP responses (rate limiting), not actual congestion. This is very common at core backbone routers.
• Consistent * * * from a hop onward — the destination may be firewalled or down.
• All hops normal but destination unreachable — the problem is at the final server, not the path.

Geographic clues are visible in hostnames. Strings like lon, fra, or nrt often indicate London, Frankfurt, or Tokyo respectively, helping you spot unexpected routing through distant regions (a phenomenon called "trombone routing").

If your traceroute leaves your ISP's network and immediately enters the destination's network with good latency, the issue likely lives in your local network or ISP's last mile — making a speed test a logical next step.

Common Traceroute Problems and What They Mean

Several patterns in traceroute output indicate specific network conditions:

• High latency starting at hop 1 or 2 — a problem with your modem, router, or the line between your home and your ISP. Try rebooting networking equipment and run a speed test.
• Packet loss at a single hop then clean thereafter — almost always rate-limited ICMP at that router. Not a real problem.
• Packet loss beginning at a specific hop and continuing — genuine loss at that hop or the link after it. Document the hop's IP and report to your ISP.
• Route suddenly changes between runs — BGP re-routing. Can be normal but may indicate instability if latency worsens.
• Traffic routing through unexpected countries — may indicate BGP hijacking or misconfiguration. Run a WHOIS lookup on the hop IPs to identify the AS (Autonomous System) responsible.

For persistent issues, run traceroutes at different times of day and save the output. Evening peak hours often reveal congestion at ISP peering points that don't appear during off-peak testing.

Advanced Traceroute Techniques

For deeper diagnostics, experienced network administrators use several advanced approaches:

Bidirectional tracing — running traceroute in both directions (from your machine to the target, and asking someone at the target to trace back to you) reveals asymmetric routing, which is extremely common on the public internet and can cause confusing latency patterns.

Paris traceroute handles ECMP (Equal-Cost Multi-Path) routing, which causes traditional traceroute to show seemingly inconsistent paths. Install it on Linux with apt install paris-traceroute.

TCP traceroute to specific ports helps when diagnosing application connectivity issues. If you can't reach a web server on port 443, run:

traceroute -T -p 443 example.com

This uses actual TCP SYN packets, which travel the same path as real HTTPS traffic and are far less likely to be filtered by intermediate firewalls than ICMP probes.

Combine traceroute data with a port checker to confirm whether destination ports are actually open, giving you a complete picture of both the network path and service availability.

Frequently Asked Questions