Traceroute
Map the network path your packets take to a host, hop by hop, and spot where latency climbs. A server-side tool — browsers can't send the packets it needs.
Why traceroute can't run in a browser
A traceroute sends packets with a deliberately short lifespan and listens for the ICMP errors that each router along the path sends back. That needs raw network access — exactly what browsers forbid for safety. So a true traceroute has to run from one of our servers. Here's what the finished tool will show: the path your traffic takes, hop by hop, with the round-trip time to each one.
- 1 Your router First hop — your home gateway 1 ms
- 2 ISP edge Your provider's local network 9 ms
- 3 Backbone Long-haul transit between networks 24 ms
- … Peering / IX Where networks exchange traffic 38 ms
- N Destination The host you're trying to reach 41 ms
Illustrative path — not a live measurement.
What a traceroute does
When you connect to a website, your data doesn't travel in a single jump. It passes through a chain of routers — your home gateway, your ISP's network, long-haul backbone links, peering points where networks meet, and finally the destination's network. A traceroute reveals that chain. By sending probes that expire after one hop, then two, then three, and so on, it coaxes each router into identifying itself and reports the round-trip time to reach it. The result is a map of the path your packets take and how long each leg adds.
It's the tool of choice when a site feels slow or unreachable but you can't tell where the slowdown happens — your network, your ISP, or somewhere far out on the internet.
How to read a traceroute
Read it top to bottom. The early hops are close to home — your router and your ISP — and should show single-digit to low double-digit latency. As you move outward the numbers rise gradually; that's normal and reflects distance. What you're hunting for is a sudden, sustained jump: if latency leaps at hop 6 and stays high for every hop after, the congestion or bottleneck starts there. A one-off spike that recovers on the next line is harmless — that router simply deprioritised your probe. Likewise, a hop of * * * in the middle usually means a router that ignores traceroute, not a fault.
Frequently asked questions
- Why can't traceroute run in my browser?
- Traceroute works by sending packets with increasing TTL (time-to-live) values and reading the ICMP "time exceeded" replies from each router along the way. Browsers don't allow raw socket or ICMP access for security reasons, so a true traceroute simply isn't possible from JavaScript. It has to run from a server.
- What does a traceroute actually show?
- Each line is a "hop" — a router your packets pass through on the way to the destination — along with the round-trip time to it. Read top to bottom, it maps the path your traffic takes and reveals where latency suddenly jumps.
- What do the asterisks (* * *) mean?
- A hop showing * * * didn't reply within the timeout. Often it's harmless — many routers are configured to ignore traceroute probes to save resources — so a single starred hop in the middle usually isn't a problem. Stars all the way to the end can indicate a real block or failure.
- How do I read where the problem is?
- Look for the hop where latency jumps and stays high for every hop after it. That jump is usually where congestion or a long-distance link begins. A spike on one hop that recovers on the next is normal — that router just deprioritised your probe.
- Can I run a traceroute myself now?
- Yes — use tracert example.com on Windows, or traceroute example.com / mtr example.com on macOS and Linux. mtr is especially good because it runs continuously and shows packet loss per hop. Our hosted, multi-region version is in development.
Find the layer that's actually slow
A traceroute shows the path; the Doctor explains the verdict. While the hosted traceroute is in development, run a full diagnosis to see whether the bottleneck is your Wi-Fi, your ISP, or the wider route.
Run a full diagnosis