Not run
Run a trace to see the path.
Traceroute
See the real hop-by-hop path packets take to reach a server, run from a genuine probe on real infrastructure - not simulated from this server's own datacenter.
Runs a real traceroute from a Globalping probe, not from this server.
Not every router along the way replies to a traceroute probe - that's normal.
Enter a target and choose a probe location to trace the path to it.
Total Hops
0
routers seen along the path
Answered Hops
0
hops that replied
Probe Location
—
where this trace ran from
Final Hop Time
—
latency at the last hop reached
🛰️ Hop-by-Hop Path
In order, from the probe to the destination (or as far as it got).
Hop
Address
Location
Time
🔎 Findings
📋 Query Details
Target
—
Probe
—
Probe Network
—
Checked At
—
📦 Raw API Result
A hop that shows "No reply" isn't necessarily a problem - many routers are configured to never respond to traceroute probes at all, or rate-limit them, while still forwarding traffic through perfectly normally. What matters most is whether the trace reaches the destination, and how latency changes across the hops that do reply.
HOW IT WORKS
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.
Want to see the full path to a site?
DNS, redirects, every hop, the CDN, TLS and the origin server.
Want to know your public IP?
See your IPv4 and IPv6 addresses, location, ISP and ASN.
Want to check your tower & route?
Live ping, speed, DNS, traceroute and a map of nearby points.
Want to ping from around the world?
Real latency from real probes across 12 countries, live on a map.
Want to locate any IP address?
City, region, country and coordinates for any public IP.
Want to know if an IP is risky?
Proxy, VPN, Tor, hosting and abuse-report indicators.
Want to know if you're blacklisted?
Check an address against major spam and abuse DNSBLs.
Want to know who owns an IP?
Network owner, ASN, CIDR range and abuse contact.
Want to explore an AS number?
Announced prefixes, BGP neighbours and registry details.
Want to test your connection speed?
Measure real download, upload, ping and jitter.
Want to see what changed?
Word-level diff between two blocks of text or code.
Want to know if a DNS change is live yet?
Compare answers from five independent public resolvers.
Want to verify a domain's nameservers?
Direct authoritative checks, glue records and SOA serials.
Want to check a domain's DNSSEC setup?
DNSKEY, DS records, signature expiry and real validation.
Want to know if a server port is open?
A real TCP connection attempt - open, closed or filtered.
Want to measure latency to a server?
Real connect timing - min/avg/max, jitter and connection loss.
Want a clean URL slug from a title?
Real transliteration, stop words and batch mode.
Want to find and replace across a document?
Regex, capture groups and a live preview before you commit.
Want to find the invisible character?
Code points, escapes, bytes and hidden-character detection.
Want to escape text for HTML?
Minimal, named or numeric entities, attribute-safe.
Want to strip emoji cleanly?
Whole clusters - no half-flags or stray modifiers left.
Want to spot repeated words?
Frequency, density and accidental doubles like "the the".
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.