Analyzing a slow network involves a lot of guesswork. You can blame your router for slow internet in the evening, adjust your DNS settings to see if your ISP’s DNS is causing the problem, or run a ping command to confirm that yes, something is slow. But ping only tells you the round trip time to your destination. It does not tell you where the reduction occurs.
That’s where the tracert command comes in. Short for path tracking, it maps each router your data passes through on its way to the server and measures the response time at each stop. Instead of just confirming that your connection is slow, tracert shows you exactly which hop in the path is causing the delay, whether the problem is your router’s settings quietly destroying your internet speed, your ISP’s equipment, or a congested broadband connection.
How traceroute works
Tracert maps everything between you and the server
When you type tracert google.com at Windows Terminal or Command Promptcommand sends packets with increasing TTL (Time to Live) values, forcing every router on the path to identify itself. In this way, tracert discovers each router in sequence and measures how long it takes to reach each one.
The hidden reason that your Wi-Fi is slow may be the time you spent fixing it
They sound like a great solution, but they’re often a headache.
The result may seem difficult to understand, but it’s easy once you know what to look for. The first column is the hop number, the next three show the round-trip time (RTT) for three separate probes, and the last column shows the router’s IP address or hostname. Three probes per hop may seem redundant, but that’s how you tell a real problem from a one-time glitch.
Here’s what the live example on Google.com looks like from my link:
|
Hop |
RTT 1 |
RTT 2 |
RTT 3 |
Address |
What it is |
|---|---|---|---|---|---|
|
1 |
2 ms |
1 ms |
1 ms |
192.168.1.1 |
Your home router |
|
2 |
6 ms |
3 ms |
4 ms |
223.190.228.1 |
ISP gateway |
|
3 |
3 ms |
4 ms |
4 ms |
152.52.122.45 |
ISP router |
|
4 |
27 ms |
23 ms |
23 ms |
116.119.161.147 |
Wide web |
|
5 |
23 ms |
23 ms |
22 ms |
72.14.205.196 |
Google web |
|
6 |
24 ms |
22 ms |
23 ms |
142.251.227.211 |
Google web |
|
7 |
22 ms |
21 ms |
24 ms |
209.85.247.229 |
Google web |
|
8 |
22 ms |
22 ms |
28 ms |
pnmaaa-at-in-f14.1e100.net |
Site (Google) |
This is a clean, healthy model. Hop 1 is my router at 1-2 ms. Hops 2 and 3 are my ISP devices, which are still under 6 ms. The RTT goes up by 4 hops as traffic enters multiple networks, and then stays constant through Google’s network to the destination. No sudden spikes, no downtime.
The RTT signal indicates the bottleneck
See where latency spikes and stays high
Following a close browser can be confusing. But I started getting tracert when a Japanese news site I read sometimes felt unusually slow. The pages took a long time to load, and I thought there was something wrong with my connection or the site itself. So I ran tracert yahoo.co.jp to know.
|
Hop |
RTT 1 |
RTT 2 |
RTT 3 |
Address |
What it is |
|---|---|---|---|---|---|
|
1 |
2 ms |
1 ms |
1 ms |
192.168.1.1 |
Local router |
|
2 |
3 ms |
3 ms |
4 ms |
223.190.228.1 |
ISP gateway |
|
3 |
3 ms |
4 ms |
4 ms |
152.52.122.45 |
ISP router |
|
4 |
66 ms |
66 ms |
66 ms |
116.119.161.147 |
Wide web |
|
5 |
77 ms |
77 ms |
76 ms |
15.230.56.106 |
Equinix Exchange |
|
6 |
132 ms |
132 ms |
132 ms |
210.130.180.133 |
IIJ.Net (Tokyo) |
|
7 |
133 ms |
133 ms |
133 ms |
210.130.134.30 |
IIJ.Net router |
|
8 |
134 ms |
134 ms |
133 ms |
210.130.134.78 |
IIJ.Net router |
|
9 |
144 ms |
144 ms |
144 ms |
124.83.228.217 |
Yahoo Japan online |
|
10 |
* |
* |
* |
The request has expired |
– |
|
11 |
160 ms |
205 ms |
161 ms |
183.79.135.206 |
Site (Yahoo Japan) |
The first three hops stayed under 4 ms, so my network and ISP were fine. But look at hop 4: RTT jumped to 66 ms when the traffic left my ISP. At hop 5, it went up to 77 ms with the Equinix exchange. Then at hop 6, the RTT nearly doubles to 132 ms when the connection hits the IIJ.Net routers in Tokyo, presumably crossing the undersea cable from India to Japan. The remaining hops landed in the 133-144 ms range, and the destination reached in 160-205 ms.
An important trend to look for: when the RTT spikes for a particular hop and stays high for all subsequent hops, the slowdown starts at that hop. Everything after that inherits the delay. In my case, skipping hop 6 was not a broken router or a congested link. It was just a place between India and Japan. Tracert showed me that my connection was intact; the place was just a long way away, and no amount of trouble on my end was going to change that.
That’s real value. If the spike had occurred on hop 2 or 3, I would know the problem is on my ISP’s end. If it shows up on hop 1, I would be looking at my router. Tracert doesn’t just show you that something is slow; that tells who the problem is.
Three checks per hop confirm that the spike is real. If the three RTTs are always higher compared to the previous hop, that’s a real increase in latency. If only one is elevated while the others are normal, it is likely a temporary blip.
Not everything that is unusual means that something is broken
Periods and spikes can be normal
On the same lines of yahoo.co.jp, hop 10 showed stars across three searches with a “Request timed out” message. That looks scary, but the model is well done with 11 hops, to get to your destination. Router on hop 10 is not responding to tracert probes. Many routers are configured this way for security reasons or to reduce performance overhead. They are still forwarding your real traffic; they just don’t respond to test packets.
Tracert also sends probes above 30 hops. If the destination is not reachable within that limit, you will see “Request timed out” for each remaining hop, which means that several routers along the way are blocking the probes while passing traffic normally. Similarly, a single high-throughput three-step search on a given hop is usually temporary noise, not something worth investigating.
The comments to watch out for are the ones that don’t make sense. A spike that corresponds to a physical distance or a time-limited hop in a non-pure way is common. A rise from 20 ms to 200 ms between two routers in the same city, or rising RTTs from a certain ISP hop, is when you get something to happen.
- OS
-
Windows
- Minimum CPU requirements
-
1Ghz/2 Cores
Windows 11 is Microsoft’s latest operating system with a centralized Start, Snap Layouts, virtual desktops, enhanced security with TPM 2.0, and deep integration with Microsoft Teams and AI-powered Copilot.
Stop guessing what’s wrong with your network
Tracert won’t fix your slow internet, but it takes some guesswork out of finding the problem. When I’ve had streaming problems caused by surfing the net, a quick scan has helped me narrow things down before I start changing settings or calling my ISP.
That said, tracert has its limitations. It shows the forward path from your machine, not necessarily the return path, and some networks treat tracert probes differently than normal traffic. It also won’t detect packet loss or jitter that isn’t visible in RTT measurements. For those, to wander on Windows it proceeds by measuring packet loss at each hop over a long period of time. However, as a first step in finding a lazy connection, tracert gives you actionable information in seconds that most people get through hours of trial and error.
#Windows #command #shows #slowing #network