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.
When a user connects through a VPN, IP geolocation does not fail, it just answers a different question than the one you meant to ask. The lookup correctly identifies the network the traffic is currently exiting from, which is the VPN provider's server, not the user's own connection. If that exit server sits in another country, the location result will confidently and correctly place the user there, because from the network's point of view, that is genuinely where the traffic originates.
Proxies behave the same way in principle, though the details vary. A forward proxy relays a request from one IP to another, and the destination only sees the proxy's address. A transparent proxy may pass along the original client address in a header, but a well-configured one hides it entirely. Either way, the geolocation lookup is not wrong about the IP it was given. It is simply describing the network that IP belongs to, which is the proxy or VPN operator's infrastructure, not the person behind it.
This matters for two different use cases that get confused with each other. If your goal is compliance or content localization, an accurate read of the exit network is often exactly what you need, since that is the jurisdiction the traffic is legally routed through. If your goal is fraud detection, the interesting signal is not the location itself but the fact that the connection is coming from infrastructure known to be a VPN or hosting provider rather than a residential or mobile network, which is a separate data point from the geolocation itself.
Detecting that a given IP belongs to VPN or proxy infrastructure is a different problem from placing that IP on a map, and it depends on tracking which address ranges are operated by hosting and VPN providers, a list that changes constantly as new services launch and old ones get reassigned. This is available as an optional signal alongside the geographic result, since bundling it into every response by default would slow down requests that do not need it.
None of this makes IP geolocation less useful. It makes it a description of network topology, which is what it always was. Treat a VPN-flagged result as "this connection currently exits through this network," not as "this is definitely not where the user lives," and the data does exactly what it promises. For network detail alongside the location fields, pass mg_extras=1 or the X-MG-Extras header on the IPv4 or IPv6 lookup.