Mobile Carrier IP Geolocation: Why Phone Locations Often Look Wrong

A phone on mobile data does not reach the internet from where it is standing. Its traffic travels inside the carrier's network to a gateway, and only there does it get a public IP address and leave for the wider internet. A geolocation lookup sees that gateway's address, and the database places the address wherever the gateway, or the block it belongs to, was recorded. The result can be the right city, a regional hub two hundred kilometers away, or the carrier's headquarters in another part of the country.

That is the whole explanation for most 'my phone shows another city' cases. It is not a compromised device, a broken tool, or a location the phone has revealed. The wrong-location troubleshooting guide covers the other causes that apply to any connection; this guide is only about the mobile one.

When a phone attaches to a mobile network it opens a data session to an Access Point Name, the APN, which selects the network the session should reach, usually the public internet. On 4G, the 3GPP architecture (TS 23.401) terminates that session at the PDN Gateway, the PGW, which hands out the phone's IP address and connects it to the external network. On 5G (TS 23.501) the same job belongs to the User Plane Function, the UPF, with the address anchored there. Whichever generation, the address a website sees is the one issued at the gateway, not one tied to the cell tower.

Carriers run a limited number of these gateways and place them where it is efficient: in a few regional data centers, sometimes in one national site. A subscriber in a small town may be anchored at a gateway in the nearest major city, and a subscriber near a border may be anchored in a different region altogether. The distance between phone and gateway is invisible to the phone and to the website; it is only visible as a geolocation error.

Mobile networks have far more subscribers than public IPv4 addresses, so most run carrier-grade NAT: many phones share one public address, drawn from a pool at the gateway, with the private side often using the 100.64.0.0/10 shared address space that RFC 6598 reserved for exactly this. Two consequences follow for geolocation. The address a phone uses today may have been used by a subscriber in another town yesterday, so any location learned from past traffic is stale. And a database can only place the pool, not the people behind it; the CGNAT guide covers what else sharing changes.

Geolocation providers estimate the location of an address block from registry records, from feeds the operator publishes (the format in RFC 8805 exists for this), from latency measurements and from user corrections. For a fixed-line block that method converges on a neighborhood. For a mobile gateway block it converges on the gateway, or on the carrier's registered address, because that is where the block genuinely sits. MaxMind's accuracy notes say the same thing from the provider's side: accuracy varies with the type of address, cellular versus broadband among them, addresses used in mobile networks may be used by phones across a large distance, and where an address cannot be placed with confidence they publish only the country or region and omit the city. That is the expected outcome of measuring a gateway rather than a handset.

Some carriers publish geolocation feeds that map pools to the regions they serve, which improves results to the regional level. None can publish anything finer, because the pool is shared across the region by design.

The same phone gives two different answers within a minute. On home Wi-Fi it uses the household's broadband address, which databases usually place in the right town. Switch to mobile data and it uses a carrier gateway address, placed at the gateway. A phone that walks out of Wi-Fi range appears to jump cities, which is also why login-risk systems see mobile users as constant travelers; see the impossible travel guide.

Most modern mobile networks are dual-stack or IPv6-first. RFC 6459 and RFC 7066 describe how a 3GPP device receives a /64 IPv6 prefix for each data session, so IPv6 traffic carries an address unique to the phone while IPv4 traffic still goes through carrier NAT. Geolocation databases hold far less history for IPv6 blocks, so an IPv6 lookup of the same phone can land in a different city from the IPv4 one, or only at country level. Checking both addresses with the IPv6 lookup tool makes the difference visible.

Country is the reliable level for a mobile address: gateways sit inside the carrier's own country, with rare exceptions for roaming, where traffic can be routed home through the subscriber's own carrier and appear in the home country. Region is reliable only if the carrier has regional gateways and publishes them. City is an estimate of the gateway, not the handset, and coordinates are the center of an area. The accuracy guide explains the general error budget; for mobile addresses, assume the city is wrong until something else confirms it.

Treat a mobile address as a signal about the network, not about the person's whereabouts. A city mismatch from a cellular ASN is expected and should not by itself trigger a lockout, a step-up or an alarming message to the user. Use country and network type from the address, and get location certainty from the account's own history and device rather than from the gateway. Where a decision needs the user's position, ask the device for it with consent; the IP address cannot supply it. In user-facing wording, avoid claiming to know where the person is when the address only says which gateway they used.