Check what the databases currently say about your address on /report, and about any other address on /ip-lookup.
Where the location in a database comes from
No one surveys your connection. A geolocation vendor builds each entry out of several weak signals and picks the most likely answer:
- Registry records. The address the ISP filed with its regional registry when it received the block. Often a head office in a capital city.
- Latency measurements. Round-trip times from probes in known locations, triangulated to a plausible region.
- Geofeeds. Files that ISPs publish voluntarily, mapping their own prefixes to places, in the format of RFC 8805. Accurate where they exist, and many ISPs publish nothing.
- Observed positions. Apps and services that report a device position and its address at the same moment.
- Reverse DNS names. Many ISPs encode an exchange or a city into PTR records, so
host-12.lon.example.netis a hint.
Each of those can be stale or wrong, and none of them touches your device.
The five reasons it goes wrong
Your ISP aggregates a wide area. A regional network may carry an entire county through one border router, and every subscriber’s address belongs to the block announced there. Rural and satellite ISPs produce the largest errors this way, sometimes hundreds of kilometres.
Mobile carriers do it by design. A phone’s address comes from a packet gateway serving a very large area. A phone in a small town regularly reports the nearest large city, and moving does not change it until you change gateway.
The block changed hands. Address blocks are sold and reassigned constantly now that IPv4 is a traded asset. Databases update on their own schedule, so a block that moved from a Dutch host to a Brazilian ISP can carry the old country for months.
You are behind CGNAT. With carrier-grade NAT your public address belongs to the carrier’s translation site. Databases locate the translator, which is a plausible place for hundreds of thousands of subscribers and the right place for none of them.
A tunnel is in the path. A VPN, a corporate VPN, iCloud Private Relay, or a browser proxy places you at its egress. Private Relay is the surprising one, because it is on by default for iCloud+ subscribers and it deliberately keeps you in the right region while changing the city.
Anycast, and why the answer can differ between sites
Large services announce the same address from many locations at once, which is anycast. The routing system delivers your packets to whichever instance is closest in network terms, so two different services can legitimately place you in two different cities on the same connection.
This also explains a common confusion with public DNS. Querying 1.1.1.1 reaches a nearby Cloudflare site, and the resolver’s own location affects which CDN edge a site sends you to. Changing your resolver can change the content you get without changing anything about your address.
The consequence for debugging is that “wrong location” needs a source. Different vendors give different answers for the same address, and a site is only ever as right as the vendor it licensed.
Getting it corrected
The site showing the wrong city did not decide it. Fixing the database is the only durable route, and it is worth doing because most sites use one of a handful of vendors.
| Vendor | Correction route |
|---|---|
| MaxMind | GeoIP data correction request |
| IPinfo | Correction link on the result page for the address |
| IP2Location | Contact form, with the address and the correct city |
| DB-IP | Correction link on the result page for the address |
| Not correctable by the public. Google uses its own signals |
Submit the address or the prefix, the correct city and country, and a reason. If you operate the network rather than sit on it, publish a geofeed under RFC 8805 and register it in your RIR record. That is the fix that propagates to every vendor at once, and it is the right answer for an ISP with unhappy subscribers.
Expect days to weeks, and expect to repeat it if your address changes.
What to do in the meantime
- Grant browser location permission on the sites that need to be right. Precise positioning always beats an IP guess.
- Set the location manually where the site allows it. Weather, search, and shopping sites usually do.
- Turn off the VPN or Private Relay for that site if the egress is the cause. On iOS this is Settings, Apple Account, iCloud, Private Relay.
- Check whether it is actually your address. Compare the vendor result on /ip-lookup against the site’s claim. If they disagree, the site is using a different vendor or its own cached profile of your account.
- Do not change your DNS resolver expecting a fix. It affects which CDN edge serves you, not what the geolocation database says.
If the address is right and the city is wrong, nothing is broken on your side. What your IP reveals sets out how coarse that field is by construction.
Questions people ask
- How do I fix my IP location?
- Nothing on your device controls it. Look up which vendor the site uses, then submit a correction to that vendor. MaxMind, IPinfo, and IP2Location all take public correction requests. Expect days to weeks, and the fix only applies to sites using that vendor.
- Why does my phone show a city 100 km away?
- Mobile carriers route large regions through a small number of gateways, and the address you carry belongs to that gateway rather than to your cell. This is normal on every mobile network and there is no setting to change it.
- Why is the location right on my phone's map but wrong on a website?
- The map uses GPS, Wi-Fi positioning, and cell towers. The website uses your IP address, which is a completely different and much coarser source. Granting location permission in the browser overrides the guess.
- Does a wrong location mean my VPN is not working?
- Usually the opposite. A VPN puts you at its exit point, and geolocation databases sometimes place that exit in a different city from the one the provider advertises, because the address block is registered elsewhere.
Related
Last reviewed 2026-09-04. Reviewed quarterly, or sooner when a vendor changes something.