Pages load slowly, video keeps buffering, a game drops, and the ping test shows latency that is both high and jittery. But what you really want to know is: which segment of the path is the problem? That calls for a route-tracing tool: traceroute or MTR.
This article covers how they work, how to run them, and the most important part: how to read the output, and which signs are real problems versus false alarms.
How route tracing works
Data travelling from your computer to a destination passes through many routers, each called a hop. Traceroute works like this:
- It sends packets with TTL (time to live) set to 1. The first router decrements it to 0, drops the packet and sends back a "time exceeded" notice, so you learn the first hop's address and round-trip time.
- It sets TTL to 2 and gets the second hop in the same way.
- It keeps increasing until it reaches the destination.
So traceroute lists the address and latency of every hop on the path. Note that it shows only the outbound path. The return path may be entirely different.
How to run it
Windows:
tracert example.com
pathping example.compathping computes per-hop packet loss after tracing, and takes longer.
Linux / macOS:
traceroute example.comLinux traceroute uses UDP probes by default, while Windows tracert uses ICMP. Some networks block one of them, so when results look incomplete, try another protocol: on Linux, traceroute -I for ICMP or traceroute -T -p 443 for TCP.
MTR (recommended): MTR combines ping and traceroute, probing continuously and keeping per-hop loss and latency statistics. Its results are far more reliable than a single traceroute run.
mtr -rwzbc 100 example.comThe flags: -r report mode, -w wide output, -z show AS numbers, -b show both IPs and hostnames, -c 100 run 100 rounds. On Windows you can use a graphical tool such as WinMTR.
Reading the output: the key columns
An MTR report usually has these columns:
- Loss%: packet loss at that hop.
- Snt: number of packets sent.
- Last / Avg / Best / Wrst: the latest, average, best and worst round-trip time in milliseconds.
- StDev: the standard deviation of latency. A larger value means heavier jitter.
Four rules for telling real problems from false alarms
1. Look at the last hop, not just the middle. What affects you is the quality of the whole path to the destination. If the last hop shows no loss and normal latency, loss displayed at a middle hop can usually be ignored.
2. Loss at a middle hop with none after it is a false alarm. Many routers give replies to probe packets very low priority or rate-limit them, so a middle hop shows high loss while forwarding real traffic perfectly well. The test is: real packet loss continues through all the later hops, including the last one.
3. An asterisk * doesn't mean the link is down. It means no reply came within the timeout, perhaps because the router is configured not to reply or a firewall filters the probes. If later hops still respond normally, traffic is passing through.
4. For a latency jump, look at where it happens. If latency rises noticeably at one hop and stays high for every hop after it, that is likely a genuine bottleneck or a long-distance link. If only one middle hop is high and later hops drop back down, that device is just slow at handling probes, which doesn't affect you.
Common patterns and what they mean
- Latency jumps from tens of milliseconds to over a hundred near an international exit: normal for an ocean crossing, because light takes time. Roughly every 100 km costs at least 1 ms of round trip.
- Loss that persists from some hop onward: that hop or the link after it has a problem. Send this information to your network provider.
- Fluctuating latency and a large StDev at the last hop: a jitter problem, which hurts video, games and streamed AI output; see Latency, Jitter and Packet Loss.
- A detoured path: for example, reaching a server in a neighboring country by way of a distant region. This is common with poor routing, and can also be a clue that an IP's location differs from where it is used; see Native vs Broadcast IP.
What to include when handing results to a provider
If you want it taken seriously, don't just say "the network is slow." Include:
- The full MTR report (at least 100 rounds), not just the last few lines.
- The test time, your exit IP and the destination address.
- Ideally results in the opposite direction too, since the return path may differ.
- Comparison data: whether the result changes on another network or at another time of day.
How this works with the ipscoper ping test
Browsers can't send ICMP, so the ipscoper ping test measures HTTP round-trip latency, including DNS, TCP and TLS time. It is best for the first-pass judgment: overall latency and jitter to certain services, and whether they are unreachable. For benchmarks of what counts as good, see What Is a Good Ping. Once you find a problem, use traceroute or MTR to locate the specific segment. The two work as a relay, not as substitutes.
Summary
Reading a route trace comes down to three things: look at the last hop, check whether the problem continues through later hops, and don't be alarmed by loss at middle hops or by asterisks. With these you can separate genuine link problems from equipment false alarms, and give a provider useful evidence. If your problem only appears with a specific service, first separate "restricted" from "poor network" using the steps in AI Services Keep Asking for Verification? Check Your IP and Network First.