An IP address does not contain a location. A website looks your address up in a geolocation database. The database holds a best guess for each block of addresses, and the site shows that guess as where you are. The guess goes wrong in a few common ways. The database can be out of date, or follow the registry record of whoever holds the block. Your phone network may share your address with many others. Or your traffic leaves through a relay, VPN, proxy or company network somewhere else. Most fixes are on your side, and the lasting one sits with your internet provider.
We measured how far apart the answers can be on 11 October 2026. Apple publishes where each of its iCloud Private Relay address ranges is. For 400 of those ranges, we compared Apple's locations with the registry records and with a geolocation database. The registry put 186 of them in the wrong country. The database matched the country of all 400.
Where does a website get your location from?
A site that does not ask for your device location has only your IP address to go on. Google, which uses both, says your location "comes from a variety of sources, which are used together to estimate where you are". For the IP part, it writes that "IP addresses are roughly based on geography". When Google used your address, the note at the bottom of its results says "From your internet address".
The guess comes from a database, not from the address itself. RFC 6269 calls this use of an address "a heuristic at best". Sites still rely on it for content licensing, advertising and customised content. Each database merges several kinds of data. One kind is the operator's own word, a geolocation feed in the RFC 8805 format, which Google is named as using. That RFC also notes there is no "centralized means" to send correct location data to every site that needs it.
Your device's location is a separate thing. A site can ask your browser for it, and MDN describes how "the user is asked for permission to report location information". With that permission, the browser uses the best method the device has, for example GPS. Without it, the site falls back on the IP guess.
Why does my IP address show the wrong location?
There are six usual causes, and each one has its own fix.
| Cause | How to recognise it | What fixes it |
|---|---|---|
| The database is out of date | Lookup tools disagree; the address moved recently | A report to the site; your provider's geofeed |
| The registry's country, not yours | WHOIS shows the owner's head office country | Not WHOIS: a geofeed |
| A shared address on a phone network | Wrong on mobile data, right on home Wi-Fi | Device location; ask the carrier |
| A relay, VPN, proxy or work network | The location changes when you turn it off | Turn it off, or change its location setting |
| IPv6 instead of IPv4 | The site and the lookup page show different addresses | Check the address the site sees |
| The site uses another signal | Google says "Based on your past activity" | Device and account settings |
The database is out of date. Address blocks move. RFC 8805 warns about an ISP that "changes the location where an IP prefix is deployed". Sites that use location data may then start to work worse. The same RFC asks databases to refresh operator feeds "no less often than weekly". Google says its own IP updates "may take more than a month".
The registry's country, not yours. Every block is recorded with one of the five regional registries. The country in their shared files is the country "of the organisation to which the allocation or assignment was made". For a large company, that can be its head office. The RIPE NCC says its country field "cannot be used in any reliable way to map IP addresses to countries". ARIN says it "does not maintain geolocation data for an IP address". A database that leans on these records inherits their country.
A shared address on a phone network. A mobile carrier may put many users behind one shared public address, a setup called carrier-grade NAT. RFC 6269 describes the result. The subscriber is placed wherever the shared address appears to be, and "very often that will be in a different city".
A relay, VPN, proxy or work network. The site sees the address your traffic leaves from, and RFC 9632 notes that this address "may not point to a user". iCloud Private Relay is one such relay, built into Apple devices. Its second relay "generates a temporary IP address" and connects you to the site. By default Apple places that address near you, at "coarse city-level". A user can choose "Use Country and Time Zone" to make it vaguer.
IPv6 instead of IPv4. On a connection with both, the system prefers IPv6. RFC 8305 assumes a policy that "favors IPv6 over IPv4". The site may then locate your IPv6 address, while a lookup page that shows only IPv4 tells you something else. We compare the two in IPv4 vs IPv6 proxies.
The site uses another signal. Google may use your device location, the home and work addresses in your account, or your past activity. It also keeps your last device location in a cookie set to expire after 6 hours. A wrong result can come from any of these, not only from the IP.
How far apart are the registry and the real location?
We tested it on 11 October 2026 from our own server. Apple publishes the locations of its Private Relay exit ranges as an RFC 8805 feed. On that day, the feed listed 285,069 ranges in 235 country codes and 15,918 cities. We took a random sample of 400 IPv4 ranges and looked each one up two ways. The first was the country in the registries' own files. The second was a geolocation database: our free IP lookup.
The registry said United States for all 400 ranges, so it matched Apple's country only for the 214 that Apple places in the US. Apple places the other 186 in 72 other countries, most often India, the United Kingdom, Japan, Brazil and Canada. The lookup matched the country for all 400 and named the same city for 379 of them.
This is the best case for a database. Apple publishes its feed and asks site owners to have their database provider "update your feeds with the latest mappings". A home connection from an ISP without a feed gives the database less to go on. Two lessons still hold. A WHOIS country is not a location. And where the operator publishes a feed, a database can get it right: ours matched the country every time.
How do I fix a wrong IP location?
Work through these in order. The first steps fix what you see today; the last ones fix the record for everyone.
- Find out which signal the site used. On Google, the bottom of the results page shows how your location was estimated. Our proxy IP checker shows the public address a site sees from you and the country behind it. The IP lookup places any address you type in.
- Turn off the relay, VPN or proxy, or change its setting. For iCloud Private Relay, Apple's path is Settings > [your name] > iCloud > Private Relay > IP Address Location, then "Maintain General Location".
- Let the site use your device location. In your browser, click Site information in the address bar, then Site settings > Location, and choose Allow. Google notes that "Most computers can send location information to websites", even without GPS.
- Check your account settings. A home or work address saved in your Google account may be used to estimate where you are.
- Report the address to the site. Google takes reports through its Report IP problems form when your address "is causing Google products to show content for the wrong country". Its updates may take more than a month. For another site, its support team is the place to report it.
- Ask your internet provider to publish or fix its geofeed. This is the fix that reaches every database at once. The provider lists its ranges and their locations in the RFC 8805 format and points to the file from its registry record with a "geofeed:" line. RFC 9632 says the RIPE and APNIC databases support that line, and that where feed data exist, "geographic location hints in other data should be ignored".
- Ask the database's provider for a correction, if you know which database the site uses. Apple gives site owners the same advice for its relay ranges: reach out to the database provider.
Changing a WHOIS record will not help, for the reasons above: the registry's country describes the holder, not the location.
What if the address belongs to a proxy?
Then the site places you where it places the proxy's exit, by the same rules. A proxy whose exit sits in Frankfurt is placed in Frankfurt, if the database knows that range. A database that has not caught up places it wherever the block was before. Check the exit itself, not the label you chose. Our proxy location checker and the IP lookup both show the country and city of an exit address. If you need exits in a chosen country, our residential proxies let you pick the country, from $0.44/GB.
What this page could not check
- We cannot see which database a given site uses, or how it weighs the IP against other signals. Sites do not publish this.
- We measured one operator's feed, Apple's Private Relay, for 400 IPv4 ranges, against the registries and one database, ours. We did not query any other lookup service.
- An ISP without a feed and a mobile network behind carrier-grade NAT were not measured; for those we rely on the standards quoted above.
- City names were matched as text, so two spellings of one city count as a miss.
- Apple's feed, the registry files and every database change weekly or faster. We will measure again by 11 January 2027.
Sources
- RFC 8805: A Format for Self-Published IP Geolocation Feeds, RFC Editor, August 2020, read 11 October 2026.
- RFC 9632: Finding and Using Geofeed Data, IETF, August 2024, read 11 October 2026.
- RFC 6269: Issues with IP Address Sharing, section 7, IETF, June 2011, read 11 October 2026.
- RFC 8305: Happy Eyeballs Version 2, IETF, December 2017, read 11 October 2026.
- RIR statistics exchange format, Number Resource Organization, read 11 October 2026.
- Descriptions of primary objects: inetnum, RIPE NCC, read 11 October 2026.
- FAQ for law enforcement and public safety organizations, ARIN, read 11 October 2026.
- Understand and manage your location when you search on Google and Report IP problems, Google, read 11 October 2026.
- About iCloud Private Relay, Apple, 31 August 2023, and Prepare your network or web server for iCloud Private Relay, Apple, read 11 October 2026.
- Geolocation API, MDN Web Docs, read 11 October 2026.
- HProxy measurement from our own server, 11 October 2026, 01:28 to 01:37 UTC: Apple's egress feed, the five registries' delegation files and our IP location API.
