Real probe · Globalping network
Traceroute — every hop, for real
See the actual hop-by-hop path packets take to reach a server: which networks they cross, where the latency arrives, and the route drawn on a real map. Run from a genuine probe on real infrastructure — not simulated from this server's own datacenter.
TCP 443 looks like ordinary HTTPS to every network in between, so it is the variant most likely to complete through a firewall — ICMP and UDP are one click away. Locating hops costs one geolocation lookup per hop, so it is capped at the first 10 answered hops, with the destination always kept.
Probe location
The path depends entirely on where the trace starts — the same target from Singapore and from Germany very often takes completely different routes.
Hop-by-hop path
Grouped by the network each hop belongs to, in order from the probe.At a glance
Latency profile
Round-trip time at each answered hop.A hop that shows “No reply” is not necessarily a problem — many routers never respond to traceroute probes at all, or rate-limit them, while forwarding traffic through perfectly normally. What matters is whether the trace reaches the destination, and where latency jumps along the way.
A Real Trace From Real Infrastructure
This tool does not run traceroute from this server. That would produce a path starting inside whichever datacenter happens to host this site - real, but not what most people actually want to know. Instead, it requests a genuine traceroute from Globalping, a free network of thousands of community-run probes worldwide, from whichever real location you choose (or "Auto" to let Globalping pick a reachable one). Every hop shown is a router that genuinely replied to a probe packet on the way to your target, with its real address and round-trip time - not a simulation.
What else can you check?
These tools all work on the same connection and address data — pick whichever question you actually have.
Traceroute FAQ
Why do some hops show "No reply"?
Many routers are deliberately configured not to respond to traceroute probes, or deprioritize them under load, even though they forward your actual traffic normally. A few silent hops in the middle of an otherwise-working trace is expected, not a fault.
Why choose a probe location instead of tracing from "your" computer?
A browser cannot run a real traceroute at all - there's no API for it. Running it from this server would show the path from this server's datacenter, which is usually not useful either. A real Globalping probe gives you a genuine hop-by-hop path from an actual location of your choosing.
Why does the trace sometimes stop before reaching the destination?
Firewalls at or near the destination commonly block the probe packets traceroute relies on, even though the server itself is reachable for normal traffic like a web request. This shows up as the trace ending in unanswered hops rather than reaching the target directly.
Does the probe location affect the result?
Yes, meaningfully - the path (and every hop's latency) depends entirely on where the trace starts from. Tracing the same target from Singapore and from Germany will very often show completely different routes.
Why are only some hops shown on the map?
Placing a hop on the map needs a geolocation lookup for its address, and those cost one request each - so they are capped, and many router addresses are simply not present in geolocation databases or are registered to a company head office rather than the rack the device sits in. The map footer always states how many hops it actually managed to place, rather than looking complete while quietly plotting a handful.