Last updated: August 31, 2026 · 13 min read

What traceroute actually does

Every IP packet carries a small counter called the TTL (time to live; IPv6 calls it the hop limit). Each router that forwards the packet subtracts one, and when the counter hits zero the router throws the packet away and sends a short ICMP "time exceeded" message back to the sender. That mechanism exists to stop packets circling the internet forever — traceroute simply abuses it as a mapping tool.

It sends a probe with a TTL of 1, which dies at the first router. That router's error message reveals its IP address and how long the round trip took. Then it sends a probe with a TTL of 2, which dies at the second router, and so on, increasing by one each time until a probe finally reaches the destination and gets a normal reply. Line them up in order and you have the forward path, hop by hop, with a round-trip time for each. By default most tools send three probes per hop, which is why you see three timings on every line.

One detail that matters later: different tools use different probe types. Windows tracert sends ICMP echo requests (the same packets as ping). Linux and macOS traceroute send UDP packets to unusual high-numbered ports by default, and can be switched to ICMP or TCP. Routers and firewalls treat these differently, so two people tracing the same destination with different tools can get different-looking results — neither is wrong.

Anatomy of a traceroute line

A typical hop looks like this:

 6  ae-3-12.br02.lon01.example-isp.net (203.0.113.45)  23.412 ms  23.871 ms  22.995 ms

Reading left to right: the hop number (6th router from you), the router's hostname if it has a reverse DNS entry, its IP address in brackets, and then three round-trip times — one per probe — measured from your machine to that router and back. If a hostname is missing you'll just see the IP twice, and if a probe gets no answer within the timeout you'll see an asterisk in place of its time.

Hostnames are worth a second look because network engineers embed clues in them. Three-letter airport codes (lon, fra, ams, lax) or city names usually tell you where that router physically sits. Fragments like ae-3-12 or xe-0/1/0 are interface names; br, cr and core mark border and core routers; and a name mentioning peer, ix or another company's name often marks the point where your ISP hands traffic to a different network. None of this is standardised, but it's frequently the fastest way to understand which part of the internet a hop belongs to.

The shape of a normal route

Most traceroutes from a home connection follow the same pattern, and knowing it helps you spot what's unusual.

Hop 1 is your own router — a private address like 192.168.1.1 or 10.0.0.1 with a time of a millisecond or two. If hop 1 is already 20 ms or wildly variable, the problem is inside your home, typically Wi-Fi, and nothing beyond that hop is worth analysing yet.

Hops 2 to 4 are usually your ISP: the equipment your line terminates on, then one or two aggregation routers. If hop 2 lands in the 100.64.0.0–100.127.255.255 range, your provider is using carrier-grade NAT and you're seeing its internal network; our CGNAT explainer covers what that means for you. Latency should still be modest here — single digits on fibre or cable, a little more on DSL or mobile.

The middle hops are where your ISP hands off to a transit provider or connects directly with the destination's network. This is also where the big, legitimate jumps in latency happen, because it's where your packets start crossing real distance. Light in fibre covers roughly 200 km per millisecond, and a packet has to go there and back, so every 100 km of route adds about 1 ms of round-trip time before any router does anything at all. London to New York comes in around 70–80 ms and there is no configuration that will change that — it's physics, not congestion.

The final hops belong to the destination's network — a hosting provider, a CDN, a cloud region — ending with the destination itself. Big services often answer from an anycast address, meaning the same IP is served from many locations and you're routed to the nearest one, which is why your route to a public DNS resolver can be five hops and someone else's can be fifteen.

Reading latency the right way

This is the part most people get wrong. Each timing is a round trip to that hop, so numbers naturally grow as the hops get further away. A jump from 5 ms at hop 4 to 80 ms at hop 5 isn't automatically a problem — it might be the transatlantic cable. The question is never "which hop has the biggest number" but "where does the increase happen, and does it persist to the destination?"

Two patterns cover almost every case:

A spike that disappears at the next hop

Hop 6 shows 250 ms, hop 7 is back to 30 ms, and the destination finishes at 32 ms. This is not a problem with your connection. Routers are built to forward packets at full speed in dedicated hardware, but generating an ICMP error is a chore handled by the router's much slower management CPU, and it sits at the bottom of that CPU's priority list. A busy router will forward your real traffic instantly while taking its time answering traceroute. Since every later hop's probe passed through hop 6 and came back faster, hop 6 clearly isn't slowing real traffic. Ignore it.

A step up that carries through to the end

Hops 1–5 sit around 10 ms, hop 6 jumps to 120 ms, and every hop after it stays at 120 ms or more. Now the delay is real, because it's affecting everything downstream. Whether it's a fault depends on what that hop is: if the hostname says you just crossed an ocean, it's expected; if hop 5 and hop 6 are both in the same city and the jump is 100 ms, that's a congested or misrouted link, and the ISP that owns hop 6 is who to ask about it.

The same logic applies to packet loss. Two asterisks out of three at an intermediate hop, with clean results afterwards, is a router rate-limiting its error messages — a deliberate setting, not loss. Loss that starts at a hop and continues on every hop after it, including the destination, is real.

What asterisks and timeouts really mean

A line of * * * means that hop didn't answer any probe within the timeout. It rarely means what people fear. Many networks configure their routers not to send ICMP time-exceeded messages at all, or drop them under load, or block them at a firewall. The packets still passed through that router perfectly well — you just don't get to see it. The proof is the next line: if hop 9 is silent but hop 10 answers normally and the trace completes, nothing is wrong.

Three situations deserve attention. First, if the trace goes silent at some point and never completes, the destination is either down, unreachable from your network, or (most often) behind a firewall that drops your probe type — try a different type, or simply check whether the site loads in a browser, which is the real question. Second, asterisks that begin exactly where a persistent latency increase begins reinforce that the hop is genuinely struggling. Third, timeouts at hop 1 or 2 point to your own router or ISP equipment, which you can actually do something about.

Two more oddities that aren't faults: on Windows, a trace to a destination that blocks ICMP will run to 30 hops of asterisks and stop — that's a timeout, not thirty broken routers. And the destination itself sometimes answers while the last few hops before it stay silent, because networks often mute their internal routers while still allowing servers to respond.

Things a traceroute can't tell you

Traceroute shows the forward path only. Replies come back along whatever route the far end's network prefers, and on the internet that is frequently a different path from the one your packets took out. A hop that looks slow might be slow only on its return trip, over links your trace never displays. This is why a traceroute run from the other end — from the server towards you — sometimes tells a completely different story, and why a good ISP will ask for both.

It also can't see inside MPLS networks, which many large carriers use in their core. Depending on configuration, an entire backbone can appear as a single hop, or as several hops that all report nearly identical latency because the TTL isn't examined until the packet exits the tunnel. Long identical timings across consecutive hops are usually this, not a real anomaly.

And it doesn't guarantee that all three probes took the same path. Core routers spread traffic across parallel links by hashing packet headers, so probes can be sent down different links and answered by different routers. When a single hop line shows two or three different IP addresses, that's load balancing, and it's normal.

Reading the map: geolocation caveats

Visual traceroute tools like GoIPScan's visual traceroute plot each hop on a map, which turns a wall of numbers into something you can interpret at a glance — your traffic leaves your city, crosses to a peering hub, hops over an ocean, lands at a data centre. It's a great way to understand why a site "feels far away," and to catch surprises like traffic to a domestic service being routed via another country.

Take individual pins with a grain of salt, though. Router interface addresses are some of the hardest IPs to geolocate: they're often registered to a carrier's headquarters rather than the city the router is in, and a large block may span a whole continent. The hostname's airport code is usually more reliable than the pin. Our guide to how accurate IP geolocation really is explains where the databases get their information and why the map is sometimes wrong. Use the map to understand the shape of the route, and the timings to judge its health.

Traceroute with a VPN on

Connect to a VPN and run a trace, and you'll see hop 1 is your router, hop 2 is typically the VPN server (everything in between is hidden inside the encrypted tunnel), and the rest of the route unfolds from the VPN server's location. That's the intended behaviour — and it's also a useful check. If a trace while connected shows your ISP's routers between you and the destination in plain view, your traffic isn't going through the tunnel. Pair the traceroute with a dedicated VPN leak test and a DNS leak test to confirm both your traffic and your DNS queries are actually going where you think.

A VPN can also fix a genuinely bad route. If your ISP hands traffic to a congested transit link on the way to a particular service, tunnelling to a VPN server in a different city changes the exit point and can route around the problem entirely. Traceroute is how you'd find that out: compare the traces with the VPN on and off, and see where the persistent jump moves.

A practical way to troubleshoot with it

When something feels slow, run a ping first to confirm the problem is latency or loss rather than, say, a slow server, then use traceroute to find where along the path it begins. Run the trace several times, ideally at a good time of day and a bad one, because a single trace is a snapshot and congestion comes and goes. Trace to a couple of different destinations too: if the same hop is bad in every trace, it's your ISP's problem; if only one destination is affected, the fault lies closer to that end. On Windows, open a command prompt and type tracert example.com; on macOS or Linux use traceroute example.com; or run the visual traceroute to get a map and timings without installing anything.

When you do contact your ISP, give them the full output rather than a summary, note the time and date, and point to the specific hop where the persistent increase or loss begins. That's the language their network team speaks, and it turns "the internet is slow" into a ticket someone can actually act on.

Frequently Asked Questions

Why does my traceroute end with rows of asterisks?

Most often because the destination — or a firewall in front of it — silently drops the type of probe your tool sends, so the trace never gets a final reply and keeps trying until it reaches its hop limit. If the site loads normally in a browser, the route is fine. Try a different probe type (Windows uses ICMP, Linux and macOS default to UDP) and you'll often see the trace complete.

Is a high latency on one hop a problem?

Only if the hops after it are high too. A single hop with a large number followed by lower numbers at later hops is just a router that's slow to answer traceroute while forwarding real traffic normally. A latency increase that persists all the way to the destination is real, and the hop where it first appears is where to look.

Why does my friend's traceroute to the same site look completely different?

Because you start from different networks and each ISP chooses its own path to the destination. Big services are also served from many locations at once, so you may not even be reaching the same physical server. Different hop counts and different intermediate networks are expected; what should be similar is the overall latency for people in the same region.

Can traceroute tell me where a website's server is located?

Roughly. The hostnames of the last few hops and the latency give strong hints — a 5 ms destination is nearby, a 150 ms one is not. But the map pins depend on IP geolocation, which is approximate for router addresses and can be wrong by a country, and services behind a CDN answer from the nearest edge rather than their real home. Treat it as a good estimate, not a street address.

Is it safe to run a traceroute, and does it reveal anything about me?

Yes, it's safe. Traceroute sends a few dozen tiny packets — the same kind that flow across the internet constantly — and every router along the way already sees your IP address on all your traffic anyway. The output reveals your local router's private address and your ISP, which is worth keeping in mind if you post a trace publicly, but it exposes nothing that ordinary browsing doesn't.

What's the difference between ping and traceroute?

Ping measures the round trip to one destination and tells you whether there's a delay or loss. Traceroute repeats that measurement at every router along the way and tells you where it begins. Tools like MTR combine the two, running a continuous traceroute so you can watch loss and latency at each hop over time.