How to Use Traceroute to Find Network Issues

A site loads slowly from one office, works fine from another, and your monitoring says the server is up. That is exactly where knowing how to use traceroute saves time. Instead of guessing whether the problem is DNS, the destination host, or something in between, traceroute shows the path packets take and where delay or failure starts to appear.

Traceroute is a path analysis tool. It maps the sequence of routers, or hops, between your device and a target host, then reports how long each step takes to respond. On Windows, the command is usually tracert. On Linux and macOS, it is traceroute. Browser-based tools can do the same job without requiring local command-line access, which is useful when you need a quick check from a different network vantage point.

What traceroute actually tells you

Traceroute works by sending packets with gradually increasing TTL values. TTL means time to live. Each router that forwards a packet reduces the TTL by one. When TTL reaches zero, that router drops the packet and returns a response. By repeating that process with TTL values of 1, 2, 3, and so on, traceroute reveals each hop along the route until it reaches the destination.

In practice, that gives you three useful signals. First, it shows the path itself, which helps when traffic is taking an unexpected route. Second, it shows round-trip times at each hop, which helps you spot where latency begins. Third, it shows where responses stop entirely, which can point to filtering, packet loss, or a dead-end route.

What it does not do is prove that a single hop is broken just because that hop looks slow or does not reply. Some routers deprioritize or block ICMP responses while still forwarding traffic normally. That distinction matters, because one misleading line in traceroute often sends people in the wrong direction.

How to use traceroute on common systems

If you are working from a local machine, the syntax is simple. On Windows, open Command Prompt and run tracert example.com. On Linux or macOS, open Terminal and run traceroute example.com. You can also target an IP address directly if you want to remove DNS resolution from the test.

If you prefer a browser-based workflow, an online traceroute tool is often faster for ad hoc checks, especially when you are troubleshooting from a system without shell access. It also helps when the issue may be tied to your local ISP or edge path and you want to compare results from another source. For many admins and support teams, that is the practical advantage of using a platform like Ping Tool Net for quick routing tests alongside ping, DNS, and port checks.

The target you choose matters. If a website is failing, test the relevant hostname first because that reflects the real user path. Then test the resolved IP if needed. If the hostname and IP produce different behavior, DNS or load balancing may be part of the issue.

How to read traceroute output

A typical traceroute line includes the hop number, a hostname or IP, and three response times in milliseconds. Those three values are separate probes sent to the same hop. Minor variation is normal. Large swings can indicate congestion, shaping, or an unstable path.

Look for where latency starts, not just where it appears

This is the most common reading mistake. If hop 6 suddenly jumps from 12 ms to 140 ms, that alone is not enough to blame hop 6. Check hops 7, 8, and onward. If the higher latency continues through the rest of the path, the increase is probably real and begins at or before hop 6. If hop 6 is high but the next hops drop back to normal, that router may simply be slow to answer traceroute probes while forwarding traffic just fine.

Timeouts are not always failures

An asterisk means a probe did not receive a response within the timeout window. One timed-out hop in the middle of an otherwise complete trace is usually not the problem. Many carriers and firewalls rate-limit or drop traceroute responses. If later hops still answer, traffic is likely moving past that point.

A more serious pattern is when timeouts begin at one hop and continue to the destination, especially if the destination is also unreachable. That can suggest filtering, a route break, or a remote host that is down. Even then, context matters. Some destinations block traceroute at the edge while continuing to serve application traffic.

Hostnames can help, but do not overtrust them

Reverse DNS names sometimes reveal carrier, metro area, or backbone information. That can help narrow the issue to an ISP segment or transit provider. Still, hostnames are labels, not guarantees. Routing changes faster than naming conventions.

How to use traceroute for real troubleshooting

Traceroute is most useful when you are testing a specific symptom instead of collecting output just to have it. Start with the complaint. Is the issue slowness, a complete outage, intermittent access, or region-specific reachability?

If the complaint is latency, run a traceroute and compare hop times from your location and another network if possible. A jump near the first few hops may point to local LAN, Wi-Fi, VPN, or ISP edge problems. A jump much later in the path may suggest upstream congestion or geographic routing inefficiency.

If the complaint is no connectivity, traceroute helps separate local from remote failure. If the trace dies at hop 1 or 2, look at your gateway, firewall, VLAN path, or ISP handoff. If it gets deep into the route and then stops, the issue may be upstream or at the destination network. That distinction is useful when you need to escalate to the right team.

If the complaint is only affecting one service, traceroute is still helpful, but not definitive. Modern applications may use CDNs, anycast, WAFs, and load balancers that respond differently across protocols. A clean traceroute to the host does not guarantee that TCP 443 or UDP application traffic is healthy. In that case, traceroute should sit next to ping, DNS lookup, and port testing rather than replace them.

Limits and trade-offs you should expect

Traceroute is simple, but the internet path is not. Routing can be asymmetric, meaning the path to the destination may differ from the return path. Traceroute only shows the route taken by your probes, not necessarily the route back. If users report poor performance but your trace looks fine, asymmetric routing is one possible reason.

Protocol choice also affects results. Traditional traceroute often uses ICMP or UDP, while some implementations support TCP-based probes. Firewalls may treat those differently. If ICMP traceroute fails but TCP traffic works, the path may be filtered rather than broken. That is why a single trace should not be treated as final proof.

Load-balanced networks can produce another odd result: different probes may take different next hops. That can make the output look inconsistent even when the network is operating as designed. If you see path variation across repeated tests, do not assume instability immediately. It may just be equal-cost multipath routing doing its job.

When traceroute is enough and when it is not

Traceroute is enough when you need to answer a narrow question such as where latency starts, whether traffic leaves your network, or whether a route reaches the destination edge. It is also useful for documenting evidence during escalation. A trace that clearly shows failure before your network boundary supports a stronger provider ticket than a vague report of slowness.

It is not enough when the issue is packet loss under load, application-layer errors, or a protocol-specific block. In those cases, combine it with continuous ping, path monitoring, DNS checks, bandwidth tests, and port validation. The goal is not to collect more output than necessary. The goal is to remove ambiguity.

A practical way to use traceroute well

Run the trace to the actual hostname users are trying to reach. Repeat it from at least one other network if the issue is inconsistent. Compare where latency begins, not where a single hop looks ugly. Treat timeouts in the middle of a successful trace as informational, not automatically fatal. If the trace stops completely, verify with another tool before declaring the path broken.

That approach keeps traceroute in its proper role: a fast path-visibility tool, not a magic answer machine. Used correctly, it tells you where to look next, which is often the difference between a ten-minute fix and an hour of guesswork.

The useful habit is not just running traceroute when something breaks. It is learning what normal paths look like for your key services, so when a route changes or delay appears, you can recognize it quickly and act with confidence.