Home › Blog › Guide

Traceroute Explained: Find Exactly Where Your Connection Breaks

By the MyToolsBase team · Updated 2026-10-29

A free built-in tool that shows every stop your data makes — and exactly where things go wrong.

Most connection problems leave you with a single, unhelpful fact: something, somewhere, isn't working. A website won't load, a game keeps lagging, a video call freezes — but you can't see where the trouble is. Your laptop? Your router? Your internet provider? Some network halfway across the world?

Traceroute answers exactly that question. It is a free tool already built into Windows, macOS and Linux, and it shows every stop your data makes on its way to a website, along with how long each stop takes to reply. This guide explains how to run it, how to read the output without getting fooled by it, and what to do with what you find.

What traceroute actually does

Data doesn't travel straight from your computer to a website. It hops from router to router — first your home router, then your provider's equipment, then a chain of larger networks — until it reaches the server. A typical trip involves somewhere between 8 and 20 of these hops.

Traceroute maps that chain using a clever trick. Every packet carries a counter called the TTL (time to live). Each router that handles the packet subtracts one, and when the counter hits zero, the router throws the packet away and sends back a short "time exceeded" message. Traceroute sends packets with a TTL of 1, then 2, then 3, and so on. The first router replies on the first try, the second router on the next, and so on down the line. Each reply reveals one hop and how long the round trip took.

By default it sends three probes per hop, which is why you see three time measurements on each line.

How to run a traceroute

Windows

Open Command Prompt (press the Windows key, type cmd, press Enter) and run:

tracert example.com

Add -d (tracert -d example.com) to skip looking up each router's name. The output is less readable, but it finishes much faster.

macOS and Linux

Open Terminal and run:

traceroute example.com

The -n flag skips name lookups in the same way. On some Linux distributions traceroute isn't installed by default; your package manager can add it, or you can use tracepath, which is often already there.

Phones

Neither iPhone nor Android includes traceroute in the settings, but several free network utility apps offer it. For serious troubleshooting, a laptop on the same Wi-Fi is easier.

A full trace can take a minute or more, especially when hops don't reply. Let it finish — it stops on its own when it reaches the destination or after 30 hops.

Reading the output line by line

Here is a simplified example of a healthy trace (addresses are illustrative):

• 1   1 ms   1 ms   1 ms   192.168.1.1 — your own router.
• 2   9 ms   8 ms   10 ms   100.64.0.1 — your provider's first piece of equipment.
• 3   12 ms   11 ms   12 ms   203.0.113.9 — the provider's regional network.
• 4   *   *   * — a router that didn't reply (more on this below).
• 5   18 ms   17 ms   18 ms   198.51.100.20 — a large backbone network.
• 6   19 ms   19 ms   20 ms   example.com — the destination.

Each line has the hop number, three round-trip times in milliseconds, and the router's address (or name). A few patterns are worth knowing:

• Hop 1 should be fast. Your own router normally answers in a few milliseconds. If hop 1 shows 50 ms or more, or timeouts, the problem is inside your home — usually weak or congested Wi-Fi.
• Times grow with distance. Light in fiber covers roughly 200 km per millisecond, so a round trip of 1,000 km adds at least 10 ms. A big jump between two hops often just means the data crossed a long distance, such as an ocean.
• Router names give hints. Names often contain city or airport codes and the network owner's name, which tells you roughly where the hop is and whose equipment it is.

The three mistakes almost everyone makes

1. Panicking about asterisks

A line of * * * means that router didn't send back its "time exceeded" message in time. Many routers are configured to ignore or deprioritize these requests on purpose — answering them is a low priority compared to forwarding real traffic. If later hops reply normally, the silent hop is fine. Your data is clearly passing through it.

2. Blaming a single slow hop

You might see hop 7 at 150 ms while hops 8, 9 and 10 are back at 25 ms. That is not a problem. The router was simply slow to answer traceroute because it was busy doing its actual job. A real problem carries forward: if hop 7 jumps to 150 ms and every hop after it stays at 150 ms or higher, the slowdown genuinely starts there.

3. Running it once

One trace is a snapshot. Congestion comes and goes, and routes can change from minute to minute. Run it a few times, ideally both when things are working and when they aren't, and compare.

Finding where your connection actually breaks

Once you know how to ignore the noise, traceroute becomes a diagnosis tool. Here is how to interpret the common failure patterns:

• Hop 1 times out or is slow. The problem is between your device and your router. Move closer, switch to a cable, or restart the router. This is the most common cause of "my internet is laggy" complaints.
• Hop 1 is fine, hop 2 is slow or missing, and nothing after it replies. Your connection to your provider is down or struggling. Check the modem lights, restart the modem, and if it persists, it's a call to your provider.
• Everything is fine through your provider's network, then the trace stops entirely. If every hop after a certain point shows asterisks all the way to hop 30, traffic is being lost there. Note the last responding hop — it's useful evidence.
• The trace reaches the last network but not the website. Many servers and firewalls block traceroute probes, so the final hops may go silent even when the site works. Before concluding anything, check whether the site loads at all. You can confirm with the MyToolsBase checker, which tests from an independent connection.
• Latency jumps at one hop and stays high to the end. That's real congestion or a long, indirect route. If it only happens in the evenings, it's probably the peak-hour congestion we explain in why internet slows down at night.

Remember that traceroute only shows the path to the destination. The reply can come back along a different route, so a slow hop might be reacting to a problem on the return path. That's one more reason to trust consistent patterns over individual numbers.

Going further: pathping and mtr

Traceroute is great at showing the path but weak at measuring packet loss, the hidden culprit behind choppy calls and rubber-banding in games. Two tools combine traceroute with repeated testing:

• pathping (Windows, built in): run pathping example.com. It traces the route, then spends a few minutes sending pings to every hop and reports the loss percentage at each one.
• mtr (macOS via Homebrew, most Linux distributions): run mtr example.com for a live, continuously updating view, or mtr -r -c 100 example.com for a 100-round report you can save and share.

The same rule applies to loss as to latency: loss at one middle hop that disappears at later hops is just a router ignoring probes. Loss that starts at a hop and continues all the way to the destination is real. If you're unsure what level of loss or jitter is acceptable, our guide to ping, jitter and packet loss has the benchmarks.

What to do with your results

Traceroute rarely fixes anything on its own, but it tells you who can.

• Problem at hop 1: it's yours to fix — Wi-Fi placement, a cable, or a router restart.
• Problem at hop 2 or within your provider's network: contact your provider. Paste the trace (or a pathping/mtr report) into your support ticket. Showing that latency or loss begins on their equipment gets you past the "have you tried restarting your router?" script much faster.
• Problem far from you, in someone else's network: there is usually nothing you or your provider can do immediately. These issues are often fixed within hours by the networks involved. A VPN sometimes helps temporarily because it sends your traffic along a different route.
• The path looks clean but things still feel slow: the bottleneck may be bandwidth rather than routing. Run a speed test to check whether you're getting the download and upload speeds you pay for.

Save a trace while everything is working normally. Having a "good" baseline to compare against makes it much easier to spot what changed when something breaks.

Frequently asked questions

Is it safe to run traceroute?

Yes. Traceroute only sends small test packets and reads the replies. It doesn't change any settings on your computer or network, and running it occasionally won't cause problems for you or anyone else.

Why does my traceroute stop at hop 30?

Traceroute gives up after 30 hops by default. If it reaches 30 without arriving, either the destination blocks traceroute probes or traffic is being lost somewhere. Check whether the site actually loads before assuming it is unreachable.

Can traceroute show my exact location to others?

No. Running traceroute reveals the routers between you and a site to you, not your location to anyone. If you share a trace with support, the first hops may show your router's private address and your provider's equipment, which is normally harmless.

Why do traceroutes to the same site look different each time?

Large networks balance traffic across several parallel paths and adjust routes as conditions change. Small differences between runs are normal; what matters is a consistent pattern of high latency or loss starting at the same point.

Does a VPN change my traceroute?

Yes. With a VPN on, your traffic travels inside an encrypted tunnel, so the trace typically shows the route from the VPN server onward rather than your own provider's network. Disconnect the VPN to see your real route.

Keep reading