Using Traceroute to Diagnose Network Problems: A Practical Guide

Traceroute shows you the path a data packet takes from your computer to a destination server, hop by hop, along with how long each hop takes to respond. When a website is slow or unreachable, traceroute is usually the fastest way to figure out whether the problem is on your end, somewhere in the middle of the network, or at the destination itself.

Basic Syntax

On Linux and macOS:

traceroute example.com

On Windows, the command is tracert instead:

tracert example.com

Both return a numbered list of hops (routers) between you and the destination, along with the round-trip time for each one.

Reading the Output

Each line represents one hop. Three time values are shown per hop because traceroute sends three probe packets and measures each one separately — this helps reveal inconsistent latency, not just a single data point. A few patterns worth knowing:

• Asterisks (`* * *`) mean that hop didn't respond — common with routers configured to block or deprioritize traceroute traffic (ICMP/UDP probes), and not necessarily a sign of a problem.
• A sudden latency jump at one hop that stays high for all following hops usually points to a bottleneck at that specific point in the network, often a congested link between ISPs.
• The trace stopping before reaching the destination can mean a firewall is blocking probes, or there's an actual routing failure — checking whether the destination responds to a normal ping helps tell these apart.

Monitoring a Route Over Time

Intermittent issues (a site that's slow only sometimes) are hard to catch with a single traceroute run. Running it in a loop and logging output helps catch the problem when it actually occurs:

for site in google.com example.com; do
  traceroute $site >> traceroute_log.txt
  sleep 300
done

This logs a trace to both sites every 5 minutes, so you can go back afterward and check what the route looked like at the specific time users reported problems.

Traceroute vs. Ping vs. MTR

Common Real-World Uses

• After a DNS or hosting migration: Run a trace to confirm traffic is actually reaching the new server and not an old cached route.
• Diagnosing VPN slowness: Compare hop timings with and without the VPN active to see where the added latency is coming from.
• Confirming an ISP-side routing issue: If a specific hop consistently shows a large latency jump and it's on your ISP's network (not yours or the destination's), that's useful, specific evidence to give their support team instead of just saying "the internet is slow."

Useful Flags

• -n — skips reverse DNS lookups for each hop, which noticeably speeds up the trace on busy networks.
• -I (Linux) — use ICMP echo probes instead of the default UDP, which some firewalls handle differently and may get further through a blocked path.
• -w — adjust the timeout per probe if you're getting excessive asterisks on a slow but working connection.

A Note on Permissions

Only run traceroute against networks and hosts you have permission to test. On networks you don't control, unexpected active probing can be mistaken for reconnaissance, so stick to your own infrastructure or systems you're explicitly troubleshooting for a client.