Traceroute

How this tool works

Enter an IP address or a hostname. Our probe server runs an MTR trace to it: a traceroute that is repeated several times within a time limit of about 10 seconds, so that every hop gets multiple samples instead of one. The result is a table with one row per hop, up to a maximum of 30. The tool is free and does not require an account.

A traceroute works by sending packets with a deliberately small time-to-live value. Each router that forwards a packet decreases the value by 1, and the router where it reaches 0 discards the packet and sends back a time-exceeded message. Sending with a TTL of 1 reveals the first router, 2 the second, and so on until the destination itself answers. The probe records the address that sent each message and how long the reply took.

For each hop the tool shows the IP address, the hostname from reverse DNS when one exists, the autonomous system that announces the address, the percentage of probes that got no reply, how many were sent, and the last, average, best and worst round-trip times along with their standard deviation. The ASN column comes from the same routing data as the ASN lookup and is what makes it possible to see where the path crosses from one network to another.

Hostnames are resolved before the trace starts. Private and reserved targets are refused and each visitor is rate-limited.

How to read the result

Read the table from top to bottom. The first hops are inside the probe's own network and its upstream provider; the middle hops are transit and exchange points; the last hops belong to the destination's provider and the destination itself.

Loss column. The important rule: loss that appears at one hop and disappears at later hops is not real loss. Routers answer traceroute probes as a low-priority task and often rate-limit those answers, while forwarding real traffic normally. Loss that starts at a hop and continues on every hop after it, including the destination, is real; the problem is at or just before the hop where it began.

Latency columns. Compare best and average across hops. A step up in the best time that persists to the destination is distance, typically a long link such as a submarine cable. A spike in average or worst at a single hop that does not persist is the router being slow to reply, not slow to forward. Latency that rises and stays risen from one hop onward marks a congested link at that point.

Hostnames. Transit providers name their router interfaces with codes that often reveal the city and the link, for example airport codes or city abbreviations. The reverse DNS tool resolves any of them individually.

ASN column. Watch where the number changes. The boundary between two networks is a peering or transit link, and it is the most common place for congestion and for the loss and latency changes described above. A path that enters the destination's network with low latency and then slows inside it points at the destination's own infrastructure.

Asterisks. A row with no address and no times is a hop that did not answer at all. If the trace continues normally afterwards, ignore it. If every row after a certain point is empty but the destination answers a ping, the destination's firewall drops time-exceeded messages while allowing echo replies. If nothing answers from a point onward and the destination does not reply either, the path is broken there, or the destination is down.

The last row. When the destination answers, its row shows the complete round trip, which should roughly match the result of a ping to the same host from the probe.

What to do with a traceroute

Finding where a slow connection is slow

1. Run the trace from the probe to the host and note the hop where latency rises and stays risen.
2. Run a traceroute from your own computer to the same host (commands below) and find the corresponding hop.
3. If the slow point is in the first few hops of your own trace, the problem is your local network or your ISP's access network. If it is at a boundary between two ASNs in the middle, it is a congested interconnect that neither you nor the destination controls directly. If it is inside the destination's network, the destination operator needs to look.
4. For an intermittent problem, repeat the trace at different times. MTR's per-hop statistics make a pattern visible that a single traceroute would miss.

Reporting a problem to an ISP or hosting provider

1. Include the full trace, with timestamps and the time zone, from both directions if you can get the far side to run one.
2. Point at the specific hop and the specific change in loss or latency, not at the total.
3. Note that the return path can be different from the forward path. A provider may ask for a trace from the destination back to you for that reason.

Checking a VPN or proxy route

A trace to a host while connected through a VPN starts at the VPN server, not at your computer, so the first hops belong to the VPN provider's network. A trace to the VPN server itself, with the tunnel disconnected, shows how far the detour is. If the latency to the tunnel endpoint alone is larger than you expected, choosing a server closer to you is the fix.

Running a traceroute from your own computer

Windows: tracert 203.0.113.45 uses ICMP and prints one line per hop with 3 samples. Add -d to skip hostname lookups for a faster run.

macOS: traceroute 203.0.113.45 uses UDP by default; traceroute -I 203.0.113.45 switches to ICMP, which gets through some firewalls that block UDP probes.

Linux: traceroute 203.0.113.45 as on macOS, or install mtr and run mtr -z 203.0.113.45 for a live, continuously updating view with ASNs, which is what the probe uses. mtr -r -c 50 203.0.113.45 prints a report after 50 cycles, suitable for pasting into a support ticket.

For IPv6 targets use tracert -6, traceroute6 or mtr -6.

Reading the hostnames of transit routers

Carrier and transit networks name router interfaces systematically, and once you know the pattern a trace tells you the geography of the path without any lookup. A hostname often contains a city or airport code, the router's role and the interface type: codes such as fra, ams, lhr, nyc or sin identify the city; cr, br, ar or pe distinguish core, border, access and provider-edge routers; and interface names like ae0, xe-0/1/0, et-1/0/2 or hu0/0/0/1 describe aggregated, 10 gigabit, 100 gigabit and similar links. Two consecutive hops with different city codes and a jump in best latency between them are a long-haul link, which is normal; two hops in the same city with a large latency step are a congested or oversubscribed link, which is not.

Hops that resolve to names containing words like ix, exchange or peer are interconnection points between networks; combined with the ASN column they show you exactly where responsibility for the path changes hands.

Limits of this tool

• The trace runs from our probe server. It shows the path from the probe to the host, which shares little with the path from your computer unless you are near the probe.
• Traceroute shows the forward path only. The replies travel a return path that may be different and cannot be seen from this side.
• Routers reply to probes with low priority. Loss or latency at a single hop that does not persist to later hops is a measurement artifact, not a fault.
• Some networks hide their internal hops, for example with MPLS tunnels, so the trace shows fewer routers than packets actually cross.
• Many firewalls block the time-exceeded messages or the probes themselves. A trace that ends in asterisks does not prove the destination is unreachable.
• The run is limited to 30 hops and about 10 seconds, so the number of samples per hop is small. For statistics over minutes or hours, run MTR locally.
• Load-balanced networks can return different routers for different probes, producing a table that mixes two or more parallel paths.
• Private and reserved targets are refused, and the tool is rate-limited per visitor.