How to Use Traceroute to Diagnose Network Problems

When a website feels slow or a video call drops repeatedly, the instinct is usually to blame the internet provider. Sometimes that is correct; often it is not, and the real culprit is one specific router somewhere between your home and the destination, doing something it should not. The diagnostic that tells you where in the chain a problem actually lives is traceroute, and learning to use traceroute properly turns vague “the internet is broken” complaints into specific evidence about exactly which hop is responsible. You’ll find the complete rundown in our Home Networking.

The encouraging news is that traceroute is built into every modern operating system and the basic version takes about five seconds to run. The harder part is reading the output thoughtfully — what each line means, which hops are yours versus the provider’s versus the wider internet, and which patterns indicate real problems versus normal behaviour. With a little orientation, the same output that looks like cryptic numbers becomes a clear map of how your traffic actually reaches its destination.

This guide walks through everything I think about when teaching someone to use traceroute for the first time — what the tool actually does, the right way to run it on every platform, how to read the output, and the common patterns worth recognising. By the end you will have a calm, working understanding of one of the most useful diagnostic tools in the personal-networking kit.

What It Means to Use Traceroute Effectively

Traceroute sends a series of probe packets from your computer to a destination address, with each packet asking the network “tell me about the router that handles you next.” The result is a list of every intermediate router between your device and the destination, with the round-trip latency at each step. To use traceroute is to map this path and then read the map for information about where problems live.

The typical output is a numbered list of hops. The first hop is usually your own router. The second hop is your provider’s edge equipment. The next several hops are inside the provider’s network or transitioning into the broader internet. The final hop is the destination server itself. Each line shows the IP address of that hop and three latency measurements taken from successive probe packets. To use traceroute thoughtfully is to read this list as a story: where the traffic went, how long each step took, and where the latency spikes suddenly.

According to internet engineering standards organisations, the underlying mechanism that traceroute exploits — the TTL field in IP packets — has remained essentially unchanged for decades, which is why the same tool works identically across every operating system and every era of networking. The cosmetic interfaces vary; the core information remains a clean, accurate picture of how packets actually travel.

How to Use Traceroute on Every Major Platform

The command and its variants are available on every modern operating system, with minor name differences. The full sequence to use traceroute productively on your particular machine:

1. Open a terminal or command prompt. On Windows, search “cmd” or open Windows Terminal. On macOS, open Terminal from Applications, Utilities. On Linux, open whichever terminal your distribution provides.
2. Choose a meaningful destination. A site you actually care about and use regularly produces more useful information than a random domain. cloudflare.com, google.com, or the domain of a service that has been giving you trouble all work well.
3. Run the command. On Windows it is tracert example.com; on macOS and Linux it is traceroute example.com. The output begins streaming line by line within a few seconds.
4. Wait for the trace to complete. A normal traceroute takes between ten and thirty seconds depending on how far away the destination is. Lines appear one at a time; do not interrupt unless something has clearly hung.
5. Look at the first hop. This is your own router. The latency should be very low — single-digit milliseconds. If it is high, the issue is your local network, not the internet.
6. Look at the second hop. This is your provider’s edge router. The latency should still be modest — usually under twenty milliseconds. A high latency here suggests the link between your home and the provider is degraded.
7. Scan the remaining hops. Look for sudden jumps — a hop where latency dramatically increases compared to the previous one. The location of that jump tells you where in the network path the problem lives.
8. Compare to a traceroute on a healthy day. A baseline trace captured when everything works normally gives you something to compare against when problems appear later.

The “compare to a healthy day” step is the most underused practice when households use traceroute for diagnostics. Saving the output of a normal-day trace to a file the first time you run it gives you a baseline that converts future traces from raw data into meaningful comparison. The same destination, traced again during a slow moment, surfaces the changed hop immediately.

Reading the Output When You Use Traceroute

The numbers on a traceroute look intimidating at first but reveal a clear story once you know what to look for. The key insight is that latency builds progressively, hop by hop, and each hop’s latency should be modestly higher than the previous one. Anywhere the pattern breaks is worth investigating.

Quick tip — a traceroute hop showing asterisks instead of latency numbers usually does not indicate a broken hop. Many routers are configured not to respond to traceroute probes for security reasons, and the asterisks simply mean that particular router declined to answer. As long as the trace continues to subsequent hops, the asterisks are cosmetic rather than diagnostic.

The patterns worth recognising when you use traceroute regularly:

• Smooth latency progression. Each hop is slightly higher than the previous. This is what a healthy path looks like, and most days you will see exactly this.
• Sudden spike at a specific hop. Latency jumps dramatically at one router and stays high for subsequent hops. The spike-point is the source of the problem.
• High latency from the very first hop. The local network is the bottleneck. Your WiFi or router is the issue, not anything upstream.
• High latency only at the destination. The destination server itself is slow. Everything between your house and the destination is fine.
• Variable latency on subsequent probes to the same hop. The hop is genuinely congested or under load. Single high values mixed with normal values usually indicate congestion rather than failure.
• The trace stops responding entirely. A complete path failure somewhere upstream. The last responding hop is just before the break.

The sudden-spike pattern is the most informative when you use traceroute during a problem. The exact hop where latency jumps is usually traceable to a specific organisation through tools like a WHOIS lookup on the IP address, which converts “the internet is slow” into “the slowness is at a specific router belonging to a specific provider.” That specificity is exactly what tells you whether the problem is fixable on your side or whether the right answer is a call to whichever organisation owns the troubled hop. Reviews from outlets like major technology publications regularly cover the consumer-friendly traceroute apps that surface this kind of attribution automatically.

One subtle but useful behaviour to know: many home routers and consumer-grade networking equipment respond to traceroute differently from how the broader internet treats it. Some routers mask their internal hops, others rewrite the addresses for privacy, and a handful refuse to respond at all. None of these behaviours indicate a problem; they reflect deliberate design choices that prioritise user privacy and security over diagnostic transparency. The output you get from your home network may look slightly different from the textbook example, and that is fine.

Common Cases Where Traceroute Saves the Day

Several recurring situations benefit dramatically from the ability to use traceroute. Recognising them as candidates means reaching for the chance to use traceroute deliberately rather than guessing.

The first is the “my video calls are bad but my speed test is fine” complaint. Speed tests measure raw throughput; video calls suffer from latency, jitter, and path quality, none of which a speed test reveals. When you use traceroute during a bad call, the hop where latency spikes points directly at the problem layer. Often it turns out to be the second hop — the provider’s local equipment — which is a fault you can call the provider about with specific evidence.

The second is the “one specific website is slow but everything else is fast” pattern. Tracing to the slow site usually reveals either a destination-side issue (the site’s hosting is degraded) or a routing issue (your traffic to that specific destination is taking a poor path). Either is actionable: the first is reported to the site operator, the second is reported to your provider with the trace as evidence.

The third is intermittent slowness that vanishes by the time you actually look. Running traceroute repeatedly during the problematic period captures evidence that lives beyond the moment. The collection of traces over time reveals patterns that no single trace would show, which is dramatically more useful when escalating to a provider than the standard “it was slow yesterday” complaint. Our companion walkthroughs on testing network latency and fixing slow network issues cover the broader diagnostic flow that traceroute fits into.

One last practical observation: traceroute is best used as a snapshot rather than a continuous monitoring tool. A single trace captures the path at one specific moment; the path may shift slightly between traces because of routing decisions made elsewhere. This is normal and not a sign of trouble. If you want continuous visibility into a path over time, the right tool is one of the graphical variants like MTR that runs probes continuously and surfaces the stable patterns underneath the moment-to-moment variation.

Smart Habits Around Using Traceroute

Once you know how to use traceroute, building a habit to use traceroute regularly around it turns the tool from “occasional diagnostic” into “ongoing visibility.” None of these are demanding; they fit into the broader awareness routine that makes a household network feel reliable.

Capture a baseline. Run a traceroute to a few destinations you care about — your main work platform, your favourite streaming service, a video-call host — on a day when everything is working well. Save the output to a file with the date. The next time something feels slow, you have something to compare against rather than guessing.

Use modern visual variants of traceroute. MTR, PingPlotter, and several mobile apps run traceroute continuously and surface the results graphically. These are dramatically friendlier than reading raw command-line output and surface intermittent issues that single traces miss. For ongoing monitoring rather than one-off measurement, the graphical variants are the right tool.

Document the conclusions. When you use traceroute to identify a problem, write down what the trace showed and what you concluded. The same problems tend to recur, and a short log compresses with time into a personal manual for your specific network. Pair this with the broader hygiene practices from our WiFi network security guide. According to official cybersecurity guidance, the discipline of basic path-aware diagnostics on home networks remains among the underrated personal-infrastructure habits in 2026 — not because households need enterprise-grade observability, but because a few well-placed traces can answer questions that no amount of guessing will.

A final consideration worth keeping in mind: traceroute reveals only the outbound path from your device to the destination. The return path — how packets get back from the destination to you — can be different, and a problem on the return path will not show up in a regular traceroute. For situations where the return path matters, tools like reverse traceroute or specialised diagnostic services can help, but for the vast majority of household troubleshooting the outbound path is sufficient. Knowing the limitation prevents the false reassurance of “the trace looks fine” when the actual issue is on the return path that your test cannot see.

For most households, this distinction rarely matters in practice — when the outbound trace looks clean, the experience usually feels clean too. The cases where return-path issues matter are edge cases for gamers and people running home servers, and even there the symptoms are usually distinctive enough to point at the unusual cause without specialised tooling.

The bottom line: knowing how to use traceroute is the small skill that elevates everyday network diagnosis at home from anecdotal complaint into specific, useful, actionable evidence — and that elevation alone is worth the modest effort of learning the tool.