Trace the network path to a server from six continents at once, and see where the route slows down or stops.
A traceroute lists every router a packet passes through on its way to a destination, with the round-trip time to each one. When something is slow or unreachable, it is how you find out where rather than just that.
This runs a trace from six continents at once, because a route that is fine from one part of the world is often the problem from another. Enter a domain or IP address to begin.
Every packet carries a hop limit, the TTL, which each router decrements by one. When it reaches zero the router discards the packet and reports back. Traceroute exploits that deliberately: it sends a packet with a limit of one, then two, then three, collecting a reply from each router in turn.
That is also why the output is a list rather than a single answer, and why later hops take longer than earlier ones — each line is a separate measurement to a point progressively further away.
A hop showing no response is a router configured not to answer expired packets. It is extremely common, it is a deliberate policy rather than a fault, and the trace continues straight past it. A gap in the middle of an otherwise healthy path is not something to chase.
What is worth attention is a trace that goes quiet and never recovers. That usually means a firewall near the destination is dropping the probes — the host itself may be perfectly reachable on port 80 or 443. Confirm with the global ping test or simply by loading the site.
Look for the jump. A step from 5 ms to 80 ms between two hops is a long-distance link, usually a subsea cable or a continental crossing, and it is expected. A step to 300 ms followed by everything after it staying at 300 ms points at a genuinely congested or badly routed link.
One hop showing a high time while every hop after it is fast is not a problem at all. Routers treat replying to expired packets as their lowest priority, so a busy one answers slowly while forwarding real traffic at full speed. Only a slowdown that persists through the rest of the path is meaningful.
Internet routing is asymmetric. The path your packets take to a server is frequently not the path its replies take back, and a traceroute only ever shows you the outbound half.
This catches people out constantly when diagnosing one-directional slowness. If a trace looks clean but the connection is still poor, the return path — which you cannot see from this end — is the usual suspect. Diagnosing it properly needs a trace run from the other side.
ICMP is the default and works most of the time. When a trace dies early, it is often because something along the way filters ICMP specifically.
Switching to TCP frequently gets further, because probes shaped like ordinary web traffic are far more likely to be allowed through a corporate or cloud firewall. UDP is a third option that some networks treat differently again. If one protocol stops short, trying another is the first thing to do.
That router chose not to answer. It is a configuration choice, not a failure, and the packet still passed through it on the way to the next hop. Only worry if the trace never recovers afterwards.
Almost always a firewall close to the destination dropping the probes. The server can be entirely reachable over HTTP while refusing to answer traceroute. Try the TCP protocol option, which more firewalls allow through.
Because answering expired packets is the lowest-priority job a router has. A busy one replies slowly while still forwarding real traffic at full speed. A slow hop only matters if every hop after it is slow too.
Because they genuinely take different routes through different networks. That is the value of running several at once: a peering problem affecting only Asian traffic is invisible from a European trace.
Each trace produces ten to thirty rows, so sixteen of them is more output than anyone reads, and it would use nearly three times as much of your hourly measurement allowance for very little extra insight.