Traceroute

How to read it: each row is one router (a "hop") between the probe and the target, in order. The times are round-trip latency from the probe to that hop. Look for the hop where latency jumps and stays high on every hop after it — that's where the delay is. Hostnames often hint at the provider and city (e.g. ae-5.r21.lon01…), and the ASN tells you whose network the hop belongs to.

"* * *" is usually normal. Routers forward traffic in hardware but answer traceroute probes with their own CPU, so many deprioritize, rate-limit or simply drop those replies. A silent hop followed by hops that do reply means traffic passed through fine. It only matters when every hop from some point onward is silent and the destination never answers.

Loss at one middle hop usually isn't real. If MTR shows 40% loss at hop 6 but hops 7, 8 and the destination show 0%, packets clearly got through — hop 6 is just limiting its own replies. Real loss carries on: it starts at a hop and shows up on every hop after it, including the destination. This page marks the first kind amber and the second red.

Traceroute vs MTR: traceroute sends a couple of probes per hop and shows one snapshot of the path. MTR repeats the trace several times and reports loss, average, best, worst and standard deviation for each hop, so it catches intermittent loss and jitter that a single traceroute can miss. Use MTR for "the connection is flaky" tickets; traceroute is fine for "which way does traffic go".

When to use TCP: many firewalls and cloud providers drop ICMP and UDP, so a default trace dies a few hops before a perfectly healthy server. TCP on port 443 looks like normal HTTPS traffic and usually gets through to the destination — use it when ICMP stops short or when you're troubleshooting a website specifically. If ping shows loss or high latency, a trace shows where it starts; use the Ping tool to compare locations first.