Traceroute Online Multiple Locations

Traceroute From Multiple Locations

Enter a domain or IP address in Host or IP address, choose a Protocol (ICMP, TCP or UDP), tick the cities under Trace from, and click Run Traceroute. Up to eight traces run at once: from Frankfurt, Amsterdam, London, New York, San Francisco, Singapore, Sydney and Bengaluru.

Results appear city by city as each trace finishes. A summary table at the top shows each location’s network, the number of hops, the round-trip time to the target and whether the target was reached. Below it, every city gets its full trace, plus the Raw output. Stop ends traces still running, and Clear starts over.

The traces run from Globalping measurement probes in those cities, not from our server or your computer. Each run uses whichever probe is available in each city, so the network, and sometimes the route, can change from one run to the next.

Example: 8.8.8.8 from eight cities

Every city reached 8.8.8.8 within a few milliseconds because it’s an anycast address: each probe reached a different Google site near it. The Ping page explains how that works. What traceroute adds is the route in between. Here’s Frankfurt:

Four things stand out:

• Hop 1 is the probe’s own router. _gateway is the name Linux gives to a machine’s default router. Every trace starts inside the probe’s network, so the first hops tell you about the probe’s network, not the target’s.
• The trace leaves Oracle after one hop. From hop 2 on, the addresses start with 142.250 and 142.251, which belong to Google’s own network (ASN Lookup shows this). Oracle and Google connect directly in Frankfurt, so traffic hands over immediately. Other probes go through more networks first: Amsterdam’s took 9 hops and 9.2 ms.
• The routers in between have no names. Hop names come from reverse DNS, and Google doesn’t publish names for its internal routers. Many networks don’t, so an empty Host column is normal.
• Hop times go down. Hop 2 took 3.5 ms, but the target, four hops further on, answered in 1.0 ms. Routers forward traffic in fast hardware, but replying to a traceroute is a low-priority job for their processor. So a router can look slower than everything after it. A delay that matters keeps going all the way to the target.

ICMP, TCP or UDP

Traceroute works by sending packets with a hop limit (TTL) of 1, then 2, then 3, and so on. Each router that sees the limit run out discards the packet and sends a message back, which is how it shows up in the list. The protocol only changes what kind of packet is sent:

• ICMP sends echo requests, the same packets as ping. This is what Windows tracert uses.
• UDP sends packets to unused high ports. This is the default of the classic traceroute on Linux and macOS. The target answers with “port unreachable” when it’s reached.
• TCP sends connection requests to the port in TCP port, usually 443 for websites. Firewalls that drop ICMP and UDP almost always let web traffic through, so TCP gets furthest with a firewalled web server. It also follows the same rules as a real visitor’s connection.

Each hop is probed with two packets, which is why the RTT column shows two times.

Reading the asterisks

A row of * * * means no reply came back from that hop. Where it appears matters:

• In the middle, with answers after it. The router doesn’t answer traceroute, or limits how often it does. Traffic still passed through it, otherwise the later hops couldn’t answer. You can ignore it.
• At the end, until the trace gives up. The target, or a firewall in front of it, ignores this type of packet. The tool suggests a TCP trace on port 443 when ICMP is filtered. If TCP reaches the target, the host is fine. If it doesn’t either, check whether the site actually responds with the Website Status Checker, or whether the port is open with the Open Port Checker.
• From one point onward, in every city. If traces from all locations stop at the same network, that network is either filtering or having a real problem. Run a TCP trace to tell which.

Finding where a slowdown happens

Running the trace from several cities at once is what makes a problem easy to locate:

1. Compare the summary table. If one city is slow and the rest are fine, the problem is on that city’s path, not at your server.
2. Run it again. A different probe in the same city may take a different route. If the slowdown is still there, it’s real. If it’s gone, it was the first probe’s own network.
3. Open the slow city’s trace and find the jump, a hop where the time rises and stays high through to the target. Look up the network at that hop with ASN Lookup, or its name with IP to Hostname.
4. Check whether the jump is just distance. Around 70 ms appearing at the hop where a route crosses the Atlantic is the ocean, not a fault.
5. Send the raw output to your host when you open a support ticket. Network engineers can read it at a glance.

One limit applies to every traceroute: it only shows the way there. The replies can travel back by a different route, and their time counts towards each hop’s RTT. For the full picture of a problem between your server and a region, also trace from your server back towards it.

FAQ

What’s the difference between ping and traceroute?

Ping measures the round trip to the target and nothing in between. Traceroute shows every router on the way and the time to each one. Use Ping to see whether something is slow, and traceroute to see where.

Why did I get different results for the same city?

Each run picks an available probe in that city, and probes sit in different networks with different routes. Routes on the internet also change over time. Comparing several runs tells you what’s typical.

How do I run a traceroute from my own computer?

On Windows, run tracert example.com. On macOS and Linux, run traceroute example.com. On Linux, traceroute -T -p 443 example.com does a TCP trace (it needs administrator rights), and mtr repeats the trace continuously, which is useful for problems that come and go.

Can traceroute show where a server is physically located?

Only roughly. Router names often contain a city or airport code, like fra or lhr, and the last hops are usually in the same region as the server. But the target’s own IP says nothing reliable about its street address, and with anycast or a CDN, every city reaches a different server anyway.

Why does the trace show different IPs for my domain in different cities?

Each probe looks up the domain itself, and sites on a CDN give different addresses to different regions. The Target line above each city’s trace shows which address that city traced.