Enter a host name or an IP address and choose IPv4 or IPv6. We trace the route from our server and show every router on the way, how long each took to answer and where the path ends.
The host you enter is sent to Upzilla's testing server, which traces the route and returns the result. It is not stored.
Every packet carries a counter, the TTL (hop limit in IPv6), which each router lowers by one. When it reaches zero the router discards the packet and sends back a "time exceeded" message. Traceroute uses that on purpose: it sends probes with a TTL of 1, then 2, then 3, and each one dies at the next router along the way — which reveals itself by replying. The result is the list of routers between here and the destination, with the round-trip time to each.
One router on the path. The first few are the sender's own network, the last few the destination's.
Each hop is probed three times. Similar values mean a steady link; a wide spread means congestion.
No reply. Usually the router is set not to answer, and traffic passes through it normally.
Reverse DNS names often contain a city or airport code and the carrier — a rough map of the route.
Look at where the time goes up and stays up. A jump of 80 ms at one hop that carries through to the end is normal when the route crosses an ocean. A single hop that shows a high time while the hops after it are fast again is not a problem at all: routers answer trace probes at low priority, so that number says how busy the router's own processor is, not how fast it forwards traffic.
The same goes for missing answers. One silent hop in the middle of a working trace means nothing. What matters is the end of the list: if every hop from some point on is silent and the destination is never reached, the path is broken or filtered from that point — and the last router that did answer tells you whose network to look at. If only the final destination is silent while a ping or the website works, its firewall is simply dropping the probes.
A host reachable over both protocols is reached over two independent paths, often through different carriers. One can be slow or broken while the other is fine, and users on different networks then report different experiences of the same site. Trace both when you investigate a complaint that you cannot reproduce — and remember that this trace starts at our server. The path from a particular user's network may differ; for that, they need to run traceroute (or tracert on Windows) themselves and send you the output.
The router at that hop did not reply to the three probes. Most often it is configured not to, and it still forwards traffic normally. It matters only if every hop after it is silent too.
Routers handle trace probes at low priority. A slow reply from one hop, with normal times after it, reflects that router's workload, not a slow link.
Either the path is broken at the last hop that answered, or — more often — the destination's firewall drops the probes. Check whether the site or a ping to it works.
Ping tells you whether the destination answers and how fast. Traceroute shows the routers in between, so you can see where a delay or a failure begins.
On Linux and macOS use traceroute -6 host (or traceroute6); on Windows, tracert -6 host. Your network needs IPv6 connectivity for it to work.
Upzilla checks your servers every minute from several locations, so you know about a routing problem before your users report it. 10 monitors free.