Traceroute vs IP Geolocation: Why They Do Not Always Agree

Traceroute discovers the routers between you and a destination by exploiting the time-to-live field in every IP packet. It sends probes with a TTL of 1, then 2, then 3, and so on; each router that decrements the TTL to zero discards the probe and sends back an ICMP Time Exceeded message (RFC 792) from its own address. The list of those addresses, in order, is the path, and the time between probe and reply is the round-trip latency to each hop. The Linux traceroute command sends UDP probes by default and can use ICMP echo (-I) or TCP SYN (-T) instead, up to a maximum TTL you can set; Windows tracert sends ICMP echo requests with increasing TTL values.

That makes traceroute a tool about the path at the moment you ran it: which networks the packets crossed, where latency jumps, and where replies stop. It is the right tool for a slow connection, a routing loop or a question about which carrier sits between two points, and the ASN guide explains how to turn the hop addresses into network names.

IP geolocation answers a different question: where is the address at the far end associated with? A geolocation database builds that answer from registry records, data published by network operators, latency measurements and other evidence, and the accuracy guide explains how reliable each level, from country down to city, tends to be. The result describes the endpoint, or more exactly the block the endpoint belongs to, and says nothing about the route your packets took to reach it.

The two therefore measure different things, and the apparent disagreements below come from reading one as if it were the other.

Hop addresses belong to router interfaces, and operators often register their backbone address blocks to a head office or place them wherever a database last saw evidence, so geolocating each hop produces a path that appears to jump between cities the packets never visited. The hostnames many operators attach to hops carry location hints, such as airport codes or city abbreviations, but those are naming conventions chosen by each operator, not a standard, and the reverse DNS guide explains why a hostname is a claim rather than a measurement.

Anycast breaks the picture more fundamentally. A service run under anycast (RFC 4786) announces the same address from many locations at once, so your traceroute ends at the instance nearest to your network while a geolocation lookup of the same address reports one place, often the operator's registered location. Public DNS resolvers and CDN edges work this way, which is why a lookup of a Cloudflare address can show one country while your packets stop a few milliseconds away.

MPLS hides hops. RFC 3443 describes the pipe model, in which packets crossing a label-switched path see the tunnel as a single hop regardless of how many routers it contains, so a trace can jump a continent in what looks like one step; RFC 4950 adds ICMP extensions that let traceroute display the MPLS label stack when operators enable them. Add to this that traceroute shows only the forward path while replies may return a different way, that per-flow load balancing can send successive probes down different paths, and that VPN exits, CDN edges and mobile carrier gateways end the visible path somewhere other than the device you care about.

Round-trip time is the one piece of location evidence traceroute does carry. Light in optical fibre covers roughly 200 kilometres per millisecond, so a round trip of 5 milliseconds to a hop cannot involve a hop 2,000 kilometres away, whatever its hostname or database entry says. RIPE IPmap's single-radius engine formalises this: it takes the lowest latency measured from a set of probes, converts it into a distance, and returns the cities inside that radius from the closest probe.

Latency can only rule places out, not pin one down, so treat it as a bound rather than a locator: a geolocation result far from where a low-latency trace ends points to anycast, a stale database entry or a registered-address placement, while one consistent with the latency is probably right.

Pick the tool by the question. The table below pairs the questions people bring to these tools with the one that actually answers each.

Start with the endpoint: run the final address through an IP lookup for its registered network, ASN and estimated location, then read the last few hops of the trace, their latency and hostnames, and whether the path ends well before the device you expected; if the round-trip time and the distance the lookup implies cannot both be true, the latency wins. Then account for the intermediaries: a VPN or proxy ends the trace at its exit, which the VPN verification guide shows how to check; a phone on cellular data reaches the internet through a carrier gateway that may sit in another city, as the mobile carrier guide explains; and if the lookup for your own address is simply wrong, the wrong-location guide lists the common causes.