Traceroute Globe

The hidden journey behind every click

When you open a website, your request does not teleport. It hops from router to router across cities, countries and undersea cables, and the reply makes the same trip back, all in a few dozen milliseconds. Traceroute Globe makes that invisible journey visible: type any domain or IP address and watch a live trace race across a 3D globe, a pulse of light hopping from router to router until it reaches the destination.

How traceroute works

The trick is beautifully simple. Every packet carries a “hop limit”, a counter that each router decrements. When it hits zero, the router throws the packet away and sends back a little apology. So we send a packet allowed one hop, and the first router replies, revealing itself. Then two hops, and the second router replies. Then three, and so on, until a packet finally reaches the target. String those replies together and you have the path. We use mtr, which sends several rounds and reports the best, average and worst latency at each hop, so you see not just where the routers are but how steady the connection to each one is.

Reading the results

The yellow pin is our server, where every trace begins. Each pin after it is a router, placed where its IP address geolocates, with a pulse of light travelling the whole path on a loop. The destination pin glows green when the trace reaches it. Below the globe, the hop table tells the honest story: latency tinted from green (fast) to red (slow), packet loss, and location. The first few hops are usually private addresses inside our datacenter, which we label rather than pin.

Two patterns are worth knowing. A sudden jump of a hundred milliseconds or more between two hops is almost always an ocean crossing, the single biggest source of latency on the internet, and it is oddly satisfying to see it as a long arc leaping across the globe. And packet loss that appears at one middle hop but disappears at the hops after it is not a problem: that router is just deprioritising the probe replies while happily forwarding your real traffic. Loss that starts somewhere and continues all the way to the destination is the kind worth investigating.

An honest single vantage point

One caveat we state plainly: the trace runs from our server, not from you. The path from our datacenter to a target will share most of its final hops with your own path (the target’s side of the internet is the same for everyone), but the first half will differ. Router geolocation is approximate too, city-accurate for many networks and merely country-accurate for others, because IP-to-location databases are guesses, not GPS. The latency and loss numbers, though, are real measurements taken live when you run the trace.

Why the path matters

Traceroute is how network engineers answer “why is this slow?” A site that looks close on a map but routes through three continents will always feel sluggish, and the trace shows you exactly where the detour happens. It is also how you sanity-check a CDN: if your “global” CDN is actually serving a region from one distant datacenter, the trace makes it obvious. Pair this with our IP Lookup to dig into any hop, and our DNS Lookup and SSL Checker to round out a full picture of how a host is reached and secured.

For AI agents

This tool exposes a plain-text endpoint designed for language models and agents:

GET https://nitrosites.com/tools/traceroute-globe/scan.php?host=<domain-or-ip>&format=agent

It returns a token-cheap digest of the same trace: the target, whether it was reached, the hop count and final latency, and the full hop list with per-hop latency and loss. Private datacenter hops are collapsed. Soft rate limits apply (tracing is expensive); results are cached briefly. No key or login required.

Frequently asked questions

What is a traceroute?

A traceroute maps the routers your packets pass through to reach a destination, by sending probes with increasing hop limits and recording which router answers at each step. It shows where latency builds up and where a path breaks.

Why do some hops say "no reply"?

Many routers simply do not answer probe packets, or rate-limit their replies. A no-reply hop usually is not a problem, traffic still flows through it, it is just a router that prefers to stay quiet.

How accurate are the map locations?

Router IPs are geolocated with public databases, which are city-accurate for many networks but sometimes show an ISP's registration city instead. Treat the pins as a strong hint, not GPS. The latency numbers, by contrast, are real measurements.

Why does the trace start in the United States?

The trace runs from our server, so the journey you see is from our datacenter to the target. Latency from your own location will differ, but the target's side of the path and any problems near it are usually the same.

What do packet-loss percentages mean?

Loss at a middle hop with clean hops after it is usually just that router deprioritising probe replies, and is harmless. Loss that starts at one hop and continues all the way to the destination is real packet loss worth investigating.