When a website loads slowly, a video call keeps buffering, or a game server feels laggy, the problem could be anywhere between your computer and the destination server. Your data doesn't travel in a straight line — it hops through a series of routers operated by your ISP, transit providers, and the destination's network. A traceroute maps this path and measures the time each hop takes, giving you a diagnostic view of exactly where delays or failures are occurring.
Traceroute is one of the most powerful diagnostic tools in networking, but its output can be confusing if you don't know how to interpret it. After 20+ years of using traceroutes to diagnose everything from slow office connections to complex multi-provider routing issues, I'll walk you through how to run one, read the results, and understand what they're telling you.
How Traceroute Works
Traceroute exploits a field in every IP packet called TTL (Time to Live). Despite its name, TTL isn't measured in seconds — it's a hop counter. Every time a packet passes through a router, the router decrements the TTL by 1. When the TTL reaches 0, the router discards the packet and sends back an ICMP "Time Exceeded" message to the sender, including the router's IP address.
Traceroute takes advantage of this mechanism by sending a series of packets with incrementally increasing TTL values. The first packet has TTL=1, so it's discarded by the very first router and that router reveals its identity. The second packet has TTL=2, making it past the first router before being discarded by the second. This continues until a packet reaches the final destination, building a complete map of the path.
At each hop, traceroute sends three packets (by default) and measures the round-trip time for each response. This gives you three latency measurements per hop, which helps identify whether high latency is consistent or intermittent.
Running a Traceroute
On Windows, open Command Prompt and use tracert followed by a domain name or IP address: tracert iplobster.com. On Mac and Linux, the command is traceroute iplobster.com. The output will show numbered hops, each with the router's IP address (and sometimes hostname) and three round-trip time measurements in milliseconds.
A typical traceroute might look like this: Hop 1 shows your home router (192.168.1.1) with latency under 1ms. Hops 2-4 show your ISP's local infrastructure with latency of 5-15ms. Hops 5-8 show transit provider routers with gradually increasing latency of 20-50ms. The final hop shows the destination server with total round-trip latency of 40-80ms.
For a more detailed analysis, consider using MTR (My Traceroute), which combines traceroute and ping into a single tool that continuously probes the path and provides statistics over time, including packet loss percentages and latency averages. On Linux, install it with your package manager and run mtr iplobster.com. On Windows, WinMTR provides the same functionality with a graphical interface.
Reading the Results: What's Normal
Gradually increasing latency is completely normal and expected. Each hop adds a small amount of processing and transmission time. A traceroute from the US East Coast to a server in Europe might start at 1ms at your router, increase to 10-15ms through your ISP, jump to 80-100ms as the traffic crosses the Atlantic on an undersea cable, and end at 100-120ms at the destination. These geographic jumps in latency are normal and reflect the physical distance the data travels.
Asterisks (* * *) at one or two hops don't necessarily indicate a problem. Many routers are configured to not respond to traceroute probes (by dropping ICMP Time Exceeded messages) as a security measure. If the hops before and after the asterisks show normal latency, and the traceroute eventually reaches its destination, the asterisks are harmless. They simply mean that particular router chose not to identify itself.
Consistent low latency throughout the path (under 100ms for domestic destinations, under 200ms for international) indicates a healthy route. For reference, latency of under 20ms feels instantaneous for web browsing, 20-50ms is excellent for most applications, 50-100ms is acceptable for general use, and over 150ms starts to become noticeable for interactive applications like video calls and gaming.
Identifying Problems: What's Abnormal
A sudden latency spike that persists. If latency jumps from 20ms to 200ms at a specific hop and stays high for all subsequent hops, that hop is the bottleneck. The congestion or problem is at that router or the link leading to it. Note the hostname of the problematic hop — the domain name often reveals which provider operates the router (e.g., hostnames containing "comcast.net" or "level3.net" identify the network operator). If the spike occurs within your ISP's network, contact them with the traceroute results. If it's in a transit provider's network, your ISP may need to adjust their routing.
A latency spike that recovers. If one hop shows high latency but the subsequent hops return to normal values, this is usually not a real problem. It indicates that the specific router is deprioritizing ICMP responses (traceroute packets) while still forwarding actual traffic normally. Routers prioritize data forwarding over responding to diagnostic probes, so ICMP-based latency can be misleading at individual hops. Focus on the overall trend and the final destination latency.
Packet loss at a specific hop. If one of the three latency measurements at a hop shows an asterisk while the others show normal times, there's intermittent packet loss at that hop. In MTR, this shows up as a loss percentage. Occasional packet loss (under 5%) at transit hops is common and usually doesn't affect user experience. Consistent packet loss above 5% at a hop that persists to the destination indicates a real problem that will impact performance.
The traceroute never completes. If the traceroute reaches a certain hop and then shows nothing but asterisks until it hits the maximum hop count (usually 30), the traffic is being blocked or the destination is unreachable. This could be a firewall blocking traffic, a routing loop, or a genuine outage at or beyond that point. Check whether the destination is reachable at all by trying to ping it directly or loading it in a browser.
Routing loops. If you see the same IP address appearing multiple times in the traceroute, or latency suddenly increasing then decreasing then increasing again in a pattern, there may be a routing loop — packets are bouncing between routers without making progress toward the destination. Routing loops are misconfigurations in the transit network and typically resolve themselves within minutes as routing protocols reconverge, but persistent loops need to be reported to the affected network operator.
Common Traceroute Patterns
The "last mile" problem. High latency or packet loss on the first few hops (between your device and your ISP's first router) indicates a problem with your local connection. For cable internet, this might be signal issues on the coaxial line. For DSL, it could be line quality problems. For Wi-Fi, it might be interference or signal weakness. This is the part of the path your ISP is directly responsible for, and the traceroute provides evidence for your support call.
The "peering point" problem. Sometimes you'll see a dramatic latency increase at the boundary between two networks (where your ISP hands traffic off to a transit provider, or between two transit providers). This happens when the interconnection point between the two networks is congested. It's a common source of "my ISP is fine but Netflix is slow" complaints — the ISP's network works well internally, but the link to the content provider's network is saturated.
The "geographic hop" pattern. A sudden jump from 15ms to 80ms doesn't necessarily mean a problem — it often just means the traffic crossed a significant geographic distance. Data traveling from the US to Europe on an undersea cable adds roughly 60-80ms of latency. Transpacific cables add 100-150ms. These latency increases are determined by physics (the speed of light through fiber optic cable) and can't be "fixed."
The "asymmetric path" complication. Traceroute shows the outbound path from your device to the destination, but the return path might be completely different. This means that a problem on the return path won't show up in your traceroute, but will still affect your experience (since every internet communication requires traffic in both directions). If you're experiencing issues that don't show up in your traceroute, the problem might be on the return path — which is much harder to diagnose from your end.
Using Traceroute Results Effectively
When contacting your ISP about a connectivity problem, include traceroute results in your support request. Run the traceroute during the time the problem is occurring, and if possible, run it multiple times over a period of several minutes to show the problem is consistent rather than transient. Highlight the specific hop where the issue appears and note the hostname of the affected router.
Combining traceroute data with other diagnostic information makes your troubleshooting more effective. Run a DNS lookup on the hostnames of problematic hops to learn more about which network operates them. Use IP geolocation on hop addresses to understand the geographic path your traffic is taking — sometimes traffic takes an unnecessarily long route due to suboptimal routing, and your ISP can adjust this. Check WHOIS data for the IP addresses to identify the network operators responsible for each segment of the path.
Traceroute is one of those tools that seems simple but reveals a tremendous amount about how the internet actually works. Every packet you send traverses a chain of independent networks, and traceroute lets you see exactly which links in that chain are performing well and which ones need attention. Once you learn to read it, you'll never troubleshoot network problems the same way again.