How to Use Traceroute (tracert) to Find Where Your Connection Breaks

Ping tells you whether a server answers and how long it takes. Traceroute tells you the path: every router your data passes through on the way, and how long each one takes to answer. That makes it the tool for the question support always asks — is the problem in your home, at your internet provider, or somewhere beyond?

What Traceroute Shows

Traceroute uses a counter built into every IP packet, the time to live (TTL). Microsoft’s documentation explains the trick: each router on the path must lower the TTL by at least 1, and when it reaches zero, the router sends back a “Time Exceeded” message. Traceroute sends its first packet with a TTL of 1, so the first router answers; then a TTL of 2, so the second router answers; and so on until the destination replies or the maximum number of hops — 30 by default — is reached. The routers that answer form the route.

Each line of the result is one hop: a router on the path, its address and name if known, and usually three round-trip times in milliseconds.

How to Run It on Windows, Mac and Linux

Windows. Open Command Prompt and type:

tracert example.com

Useful options from Microsoft’s documentation: -d skips looking up router names, which makes the trace much faster; -h 20 changes the maximum number of hops; -w 2000 sets how long to wait for each reply, in milliseconds.

Mac. Open Terminal and type traceroute example.com. The older Network Utility app had a Traceroute tab, but recent versions of macOS no longer include it. The Mac version sends UDP packets by default; traceroute -I example.com uses ICMP like Windows does, which some networks answer more reliably.

Linux. Use traceroute example.com (install the traceroute package if needed) or tracepath example.com, which needs no special permissions.

To test a game or a service, trace to its server address, or to a well-known destination such as a large website. Traceroute to an address on your own network shows only one hop.

How to Read the Results

A trace from a home network typically looks like this:

 1    1 ms    1 ms    1 ms  192.168.1.1
 2    9 ms    8 ms   10 ms  100.64.12.1
 3   11 ms   10 ms   12 ms  isp-core-1.example.net [203.0.113.5]
 4   14 ms   13 ms   15 ms  ix.example.net [198.51.100.7]
 5   21 ms   20 ms   22 ms  example.com [192.0.2.80]

Hop 1 is your own router. A few milliseconds or less is normal on Ethernet; on Wi-Fi it can be higher and more variable.

Hop 2 is usually the first router at your provider. An address starting with 100.64–100.127 means the provider uses carrier-grade NAT; see what is CGNAT. Two private addresses (192.168.x.x or 10.x.x.x) in the first two hops mean two routers in your home — see double NAT.

The middle hops are your provider’s network and the networks it hands traffic to. Their names often hint at the operator and the city.

The last hop is the destination. If it answers with sensible times, the path works.

*Asterisks (``)** mean no answer arrived within the waiting time for that probe. As Microsoft notes, some routers silently drop these packets, so they are invisible to traceroute — an asterisk alone is not a fault.

Where Is the Problem? Typical Patterns

High times from hop 1 onwards. The delay starts in your home: usually Wi-Fi. Run the trace again on a cable, and see why is my Wi-Fi so slow.

Hop 1 fine, hop 2 slow or lost, and everything after it too. The problem is between your router and the provider: the modem, the line or the provider’s first router. Check the modem lights, restart the modem and router, and contact the provider with the trace.

Times jump at one hop and stay high to the end. The delay is introduced there. If it is a long-distance link — between continents, for example — that is physics, not a fault.

The trace stops at some hop, with asterisks to the end, and the site does not open. Traffic is lost there. If the site does open, the destination simply does not answer traceroute packets.

Microsoft’s example of a configuration fault: the first router replies “Destination net unreachable”. That means the gateway has no route to that network at all — a wrong address or a routing problem.

Common Misreadings

One slow hop in the middle, normal times after it. Routers answer traceroute with low priority when busy. If later hops, including the destination, are fast, that slow hop is not your problem.

Asterisks in the middle, but the destination answers. Those routers just do not reply to traceroute. Nothing is lost.

Different paths on each run. Large networks balance traffic across several routes. Compare several runs, not single lines.

Blaming the provider for distance. A server on another continent will always be tens to over a hundred milliseconds away. Choose nearby servers in games if you can.

Going Further: pathping and MTR

A single trace is a snapshot. For intermittent problems, use a tool that repeats the test and shows packet loss per hop. On Windows, Microsoft points to pathping, which combines traceroute and ping and reports loss for each router after collecting statistics for a while. On Mac and Linux, mtr does the same continuously. Packet loss that starts at one hop and continues to the destination is the clearest evidence you can give your provider.

To check whether a server answers at all, our ping test is a quick start; then run traceroute from your own computer to see the path.