IP & Network
Network traceroute
Trace the network path to any host, hop by hop.
Host or IP
IPv4, IPv6 or domain. Public addresses only.
About this tool
Traceroute reveals the actual route your packets take across the internet — every router, every hop, every change of latency along the way. Where ping tells you "is the host up", traceroute tells you "what does the path look like and where does it slow down".
Our tool runs traceroute -n -q 1 -m 30 from our Frankfurt server, sending one probe per hop with a 2-second timeout. As each router answers, the row appears in your browser — you watch the trace build hop by hop. We add reverse DNS, country (with flag), city, and ASN/owner for every public IP, so you can see who runs each piece of the path.
What you can do with it
- Find where the latency lives. A clean low-RTT trace that suddenly jumps 80 ms at hop 12 points at one specific transit. That hop's ASN tells you whose network it is.
- Confirm the path goes through the expected geography. Traffic from Frankfurt to a "European" host that detours through New York is a meaningful signal — could be misrouted, could be normal CDN edge, but worth seeing.
- Compare two hosts side by side. Run traceroute to A and to B; if both die at the same hop, the problem is between us and that intermediate router, not at the destinations.
Reading the result
Hops marked* mean no reply within 2 seconds — that's either a router that drops ICMP TTL-exceeded messages (very common) or a real packet drop. Sustained * for the last few hops while earlier hops succeed usually means the firewall at the destination is silently dropping traceroute probes — the host is fine, just hidden. The reverse DNS column hints at carrier topology: names like be-1234.cr1-fra.de.example.net follow a pattern (interface, role, location, ASN suffix).
Frequently asked questions
Why do some hops show "*" forever?
A
* means we got no reply for that TTL within 2 seconds. The most common reason is a router that simply does not emit ICMP TTL-exceeded — many carriers rate-limit or disable it on backbone routers. The trace continues past these hops normally, so a few asterisks in the middle are not a problem. A long tail of asterisks at the end usually means the destination's firewall is dropping probes; the host itself may still be reachable on TCP.
Why is my traceroute different from yours?
Our probes leave from Frankfurt, yours leave from your machine — different ISPs, different upstream peering, different geography. The trace is a snapshot of the path between two specific endpoints at a specific time. Comparing both versions is exactly the point: if our path is clean and yours is not, the regression is upstream of you, not at the destination.
Are private/loopback IPs allowed as targets?
No. RFC 1918 private ranges, loopback, link-local (169.254/16), CGN (100.64/10) and cloud-metadata endpoints are refused — same SSRF policy as the rest of our tools. Use traceroute on your own machine to inspect your LAN; a public service should only probe the public internet.
Only one RTT per hop — why not three?
Classic
traceroute sends three probes per TTL and prints the three round-trips. We use one per hop (-q 1) so the worst case (30 unreachable hops × 2 s) stays inside a 60-second budget — we keep probes cheap and let you re-run if you want a tighter measurement. For deeper jitter analysis on a specific hop, our Ping tool is the right pick: it sends 5–30 echoes and gives you min/avg/max/mdev.
My favourite host shows latency that does not match my own ping. Why?
Two reasons. First, traceroute RTT for an intermediate hop measures the time the router spent generating an ICMP TTL-exceeded reply — many routers de-prioritise that path, so the number can look worse than the actual forwarding latency. Second, we measure from Frankfurt; you measure from wherever you are. The destination row (final hop) is the closest analogue to your end-to-end ping, and only when it is the actual target.