Traceroute

Trace the path to any host from three regions, with the address, PTR name, registry and latency of every hop.

We filled in 216.73.216.7, the address this server sees for you. A trace towards your own connection usually ends in silence at your ISP’s edge, because consumer gateways do not answer.

ready

Where the traces start

  • HYDHyderabad

Twenty hops maximum, fixed. Reverse DNS is resolved by us, not by the probes, and capped at twenty lookups per run. Geography comes from the registry that holds the hop address, plus a country only where we already had one cached: we do not spend a geolocation credit on a router interface, and router geolocation is unreliable anyway.

Acceptable use

Trace to hosts you own or have permission to test. Do not use this tool to generate load against a third party.

  • Rate limits. Ten runs per day per source address, one concurrent run. Past five runs in a day the response is flagged for a bot challenge, which is not yet presented in the browser.
  • Twenty hops maximum. Fixed. Traces beyond that are almost always a routing loop, and continuing wastes probes.
  • Blocklist. Operators can have their ranges excluded. Write to abuse@whatsmyip.fyi.

Report abuse to abuse@whatsmyip.fyi with the timestamp and target.

What a useful trace looks like

Read it in three parts. The first few hops are the source network and tell you little. The middle hops are transit and peering, where the interesting problems live: a hop that changes ASN is a network boundary, and boundaries are where congestion and routing mistakes concentrate. The last hops are the destination network.

When comparing regions, look for the hop where the ASN changes and the latency jumps together. That combination points at a specific interconnection rather than at a vague “the internet is slow”.

Anycast makes the destination ambiguous

Public DNS resolvers, CDNs, and most large services announce the same address from many locations. Three traces to 1.1.1.1 reach three different machines, and none of them is the “real” one. The hop names near the end tell you which facility each trace landed in, which is more useful than treating the destination as a single place.

About this tool

Enter a hostname or address and we trace the path from three regions, up to twenty hops. Each hop shows the address, its PTR record, the registry that holds it, and the latency, listed per region above a strip that marks which hops answered and which stayed silent. Three vantage points show whether a slow path sits near the destination or on one route.

How to read the result

Hop number and address
Each line is one router that decremented the TTL to zero and returned a time-exceeded message, in order along the path. A line is whichever interface replied, and that reply source address can belong to a different link than the forward path.
Latency per hop
Round-trip time to that hop, not the time spent traversing it. A hop slower than the one after it is normal, because routers deprioritise control-plane replies, and only a rise that persists through every later hop means real added delay.
Asterisks and missing hops
The router did not send a time-exceeded message, usually because ICMP generation is disabled or rate-limited. That is very common in the middle of large networks, and missing hops with a successful final hop mean the trace worked.
PTR and registry per hop
The reverse DNS name of each router and the regional registry that holds its address. Operator naming conventions frequently encode the city, often as an airport code, and the link speed, which is more accurate than any geolocation guess on the same line.
Hop location
Where the router address was issued, plus a country only where one is already cached. Geolocation of router addresses is unreliable, because backbone interface addresses are registered to the operator rather than the facility, so the PTR name is the better evidence.
The final hop
A trace that reaches the destination ends with it, and the path works. A trace that stops short in asterisks usually means the destination filters ICMP, so confirm with a TCP-based test before you conclude there is an outage.

Questions people ask

Why does traceroute stop before reaching the destination?
Most often the destination or its network filters ICMP time-exceeded and echo traffic. Cloudflare, most cloud load balancers, and many corporate firewalls do this. The path is usually fine; the probe simply gets no reply. Confirm with a TCP connection test rather than assuming an outage.
Why does one hop show huge latency but the next one is fast?
Routers generate ICMP replies on a low-priority path, so a busy router can be slow to answer while forwarding data at full speed. Only a latency increase that carries through to the destination reflects real delay on the path.
Does traceroute show the return path?
No, and this is the most common misreading. It shows the forward path only. Internet routing is frequently asymmetric, so return traffic can take a completely different route. A problem visible in your trace may live on a return path that no trace from your side will reveal.
Why do the three regions show completely different paths?
Because they are on different networks with different peering and transit arrangements. That is the point of running three: comparing them isolates whether a problem lives near the destination or on one specific path.
Is a traceroute proof of where a server is?
No. It suggests a region from hop names and latency, but the final address may be anycast, served from dozens of locations under one address. The last few hop names are usually more informative than any geolocation database entry.

Related

Last reviewed 2026-09-05.