Testing location data with edge cases, not just happy paths
An address in a well mapped city center tells you almost nothing about how your system handles a rural route, a disputed border, or a query near the poles. Test the hard cases deliberately.
Open two different phones on two different mobile carriers in the same city and look up their public IP addresses. There is a real chance both queries return an IP registered to a data center hundreds of kilometers from either phone. This is not a bug in either the phone or the geolocation service. It is carrier-grade NAT, commonly called CGNAT, and it is standard practice on nearly every mobile network.
CGNAT exists because mobile carriers ran out of enough public IPv4 addresses to give every connected device its own. Instead, a carrier assigns each device a private address and routes its traffic through a shared pool of public IPs at a central gateway, sometimes serving an entire region or even a whole country through a handful of exit points. From the outside, every one of those devices looks like it shares an IP with potentially thousands of other subscribers at that same moment.
The direct consequence for geolocation is that a mobile IP address often identifies the carrier's gateway location rather than the phone's actual position. A phone in one city can appear to be connecting from wherever that carrier happens to route its NAT pool, which might be the nearest major hub rather than the user's real location. This is different from the fixed-line case, where an IP is more likely tied to a specific regional exchange close to the subscriber.
This is a known and universal limitation of IP-based location on cellular networks, not something specific to any one lookup provider. It applies equally regardless of which geolocation service is doing the lookup, because the constraint is in how the carrier routes traffic, not in how the location data is compiled.
The practical takeaway is to expect coarser results, often at the region or country level, for IP addresses that resolve to mobile carrier ASNs, and to treat city-level results from mobile ranges as a reasonable estimate rather than a confirmed location. If your application genuinely needs to know where a mobile device is, GPS from the device itself will always outperform IP geolocation, because it measures position directly instead of inferring it from network routing. Use IP-based lookups on mobile traffic for what they are reliable at: identifying the carrier, the country, and usually the region, while treating anything finer as a best available estimate rather than a fact.