Traceroute maps the exact path your data takes from your device to a destination, showing every router it passes through along the way. It does this by sending out packets with intentionally short lifespans, forcing each router in the chain to reveal itself. The result is a numbered list of network “hops” with timing data, giving you a clear picture of where slowdowns or failures are happening.
How Traceroute Works, Step by Step
Every packet traveling across the internet carries a counter called Time to Live (TTL). Each time a packet passes through a router, that counter drops by one. When it hits zero, the router throws the packet away and sends a small error message back to whoever sent it, essentially saying “your packet expired here.” Traceroute exploits this behavior in a clever way.
It starts by sending a packet with a TTL of 1. The very first router in the path decrements it to zero, discards the packet, and sends back that error message. Traceroute records the router’s address and how long the round trip took. Then it sends another packet with a TTL of 2, which makes it past the first router but expires at the second. Then TTL 3, then 4, and so on. Each expired packet reveals the next router in the chain until the packet finally reaches the destination. The result is a complete, ordered map of every hop between you and the target.
This error message is called an ICMP Time Exceeded message. It’s the backbone of how traceroute discovers routers, and it works the same way in IPv6, where the TTL field is simply renamed “Hop Limit.”
Reading Traceroute Output
A typical traceroute result looks like a numbered list. Each line represents one hop (one router), and shows the router’s IP address along with three round-trip times in milliseconds. Those three times come from three separate probe packets sent to each hop, giving you a rough sense of consistency. If the first probe takes 12ms and the third takes 80ms at the same hop, that router may be under intermittent load.
Sometimes you’ll see asterisks (*) instead of times. That means the router didn’t respond. This doesn’t always signal a problem. Many network administrators configure their routers to silently ignore these probe packets for security reasons, so a few missing responses in the middle of an otherwise healthy trace are usually nothing to worry about.
What Traceroute Is Actually Used For
The most common use is pinpointing where a network problem lives. If a website is loading slowly, a traceroute might show normal response times of under 10ms for the first few hops, then a sudden jump to 200ms at hop 7. That tells you the bottleneck isn’t your connection or the destination server. It’s a congested router somewhere in the middle, likely on an ISP’s backbone.
Traceroute also reveals routing loops, where packets bounce endlessly between two misconfigured routers. In the output, you’ll see the same IP address repeating across multiple hops. It catches unexpected detours too. If you’re connecting to a server in your own city but traceroute shows your traffic routing through another continent, that points to a misconfigured routing policy. Network engineers use this kind of information to pressure ISPs into fixing bad routes or to reroute traffic through better paths.
VoIP call quality issues, video buffering, and online gaming lag can all be diagnosed this way. One practical example: a voice-over-IP quality problem was traced to a router that was splitting traffic unevenly across two paths, sending voice packets on a longer route and introducing enough delay to degrade call quality. Traceroute made the detour visible.
Windows vs. Linux and macOS
The tool exists on every major operating system, but with slight differences. On Windows, the command is tracert and it sends ICMP Echo Request packets, the same type used by ping. On Linux and macOS, the command is traceroute and it sends UDP packets by default, though you can switch it to use ICMP instead.
This protocol difference matters because some firewalls treat ICMP and UDP traffic differently. A traceroute that works fine on Windows might produce different results on Linux for the same destination, simply because certain routers along the path block one protocol but not the other. If you’re getting unexpected timeouts, trying the other protocol can sometimes fill in the blanks. For IPv6 addresses, Linux provides traceroute6 (or traceroute -6), which works identically but uses the IPv6 Hop Limit field and sends slightly larger default probe packets (80 bytes instead of 60).
Why Traceroute Can Be Misleading
Traceroute is powerful, but it has real blind spots that can lead to wrong conclusions if you’re not aware of them.
The biggest one is ICMP rate limiting. Many routers are configured to cap how many error messages they generate per second, often as low as 80 per second. When a router hits that cap, it simply stops responding to some probe packets, producing timeouts that look like packet loss. Research from USC’s Information Sciences Institute has found that undetected rate limiting can silently distort measurements, creating false conclusions about where problems exist. A hop showing 30% “packet loss” might just be a busy router deprioritizing its responses to your traceroute while forwarding actual traffic perfectly fine.
The second blind spot is asymmetric routing. Internet traffic almost always takes a different path going forward than it does coming back. When traceroute shows you timing data, those round-trip times include the return trip, which may follow a completely different chain of routers. If there’s congestion on the return path, it shows up in your traceroute as high latency at a forward-path hop that’s actually working fine. The congestion could be in an entirely different ISP’s network on the way back.
This is why network professionals run traceroutes in both directions whenever possible: one from the source to the destination, and another from the destination back to the source. A single one-way traceroute can correctly identify that a problem exists but point to the wrong location.
How to Run a Basic Traceroute
On Windows, open Command Prompt and type tracert followed by a domain name or IP address. On macOS or Linux, open Terminal and type traceroute followed by the target. The tool will print each hop as it discovers it, usually finishing within 30 seconds for most destinations. If it seems stuck, that typically means a hop along the way is blocking responses, and the tool is waiting for replies that won’t come before moving on.
Each hop number corresponds to one router between you and the destination. Hops 1 and 2 are usually your home router and your ISP’s first device. The middle hops are backbone routers operated by various ISPs and transit networks. The final hop is the destination itself. Consistent times under 100ms across all hops is typical for domestic connections. Jumps of 60 to 100ms between two consecutive hops often indicate a geographic leap, like traffic crossing an ocean on an undersea cable, which is normal and expected.