An IP address contains no physical location. Geolocation databases assign a location estimate to an address or network prefix using external data. Country mapping is the strongest layer. City mapping is less reliable on mobile networks, CGNAT, broad ISP pools, and recently reassigned prefixes. A VPN changes the public exit point, so the reported city follows the VPN exit rather than your physical location.
Seeing a different city does not mean the IP address or route is faulty. A correct public IP, a valid route, and the expected origin AS do not validate the city label.
Routing and geolocation answer different questions. BGP identifies the origin AS advertising the prefix. A geolocation database attaches a place to that prefix from a separate dataset. When the prefix and origin AS are expected but the city is wrong, inspect the geolocation data rather than treating the result as a routing fault.
The same symptom appears on residential fiber, cable, mobile broadband, satellite access, and corporate networks across the United States, Canada, Australia, and Europe. Country results are the more stable layer. City labels diverge between providers, and stale records also place valid prefixes in the wrong country after transfers or redeployment.
Related tool: IP Lookup — it shows the public address, origin ASN, routing and the geolocation estimate as separate layers, each with its own confidence.
01 / Model
How IP geolocation actually works
An IPv4 or IPv6 address contains no built-in city code, latitude, or longitude. The location shown by an IP lookup comes from external databases, not from the addressing protocol.
One common fixed-line path looks like this:
Home / office device
|
v
ISP access network (fiber / cable / DSL)
|
v
BNG / BRAS / aggregation layer
|
+--> public address assigned from an ISP pool
|
v
Internet
A geolocation vendor starts with the public address or prefix and joins several network and location signals. Refresh timing matters. Different update schedules leave one database on a current geofeed while another still serves an older mapping.
Public IP / network prefix
|
+--> RIR allocation and registration data
+--> ASN and BGP information
+--> ISP-published geofeeds
+--> network measurements and observations
+--> historical mappings and corrections
|
v
Geolocation database
|
v
Country / region / city / coordinates / accuracy radius
RIR registration data is not geolocation. An ARIN, RIPE NCC, APNIC, or LACNIC record identifies the organization that received or manages address space. It does not prove where one subscriber using an address from that block is physically located.
02 / Causes
What actually causes a wrong IP location?
Wrong city labels come from five layers: address assignment, shared translation, mobile-core egress, stale location data, or a deliberate exit point such as a VPN or proxy.
ISP address pools do not follow city borders
ISP address pools are built around network operations, not municipal boundaries. In a regional aggregation design, one broadband pool serves several access areas behind the same BNG or aggregation layer. If a geolocation database tags that prefix to one city, subscribers elsewhere in the pool inherit the same city label.
A new DHCP or PPP session does not guarantee a new public address. If the ISP assigns a different address and that address maps to another city, the displayed city changes. The subscriber did not move. The address-to-location mapping did.
CGNAT puts many subscribers behind the same public IPv4 address
Carrier-Grade NAT translates many subscriber flows behind one or more shared public IPv4 addresses. The externally visible address belongs to the ISP shared translation pool, not to one household. When a vendor maps that shared address to the gateway or pool city, every subscriber translated through it receives the same city label.
Subscriber A ---+
Subscriber B ---+--> CGNAT / shared translation --> public IPv4
Subscriber C ---+ |
v
geolocation database
Check the router WAN IPv4 against the public IPv4 reported by an external lookup. Example: the router shows 100.72.18.4 while the lookup returns a different public IPv4. The WAN address falls inside 100.64.0.0/10, the RFC 6598 Shared Address Space. That combination is strong evidence of CGNAT or another provider-side translation layer using shared address space. It is a diagnostic clue. Subscriber identification requires the operator translation records.
A private WAN address such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 together with a different external public IPv4 proves that NAT exists upstream. It does not prove carrier-grade NAT. Double NAT at home, an ISP modem/router, or an enterprise network produces the same visible pattern.
Mobile traffic exits far from the phone
GPS, Wi-Fi positioning, and cellular location services locate the handset. A website sees the public source IP after traffic crosses the mobile core. In LTE/EPC, the P-GW anchors the PDN connection and forwards traffic toward the external data network. In 5G Core, the UPF handles user-plane forwarding toward the data network. Operators place these functions according to network design, so the public IP and egress follow the carrier architecture rather than the handset street position.
Native IPv6 removes IPv4 CGNAT from the IPv6 path, but it does not embed location in the address. Carrier prefix assignment and vendor mapping still determine the geolocation result.
Geolocation vendors disagree because their datasets differ
There is no official registry that designates one correct city for every public IP address. MaxMind, IP2Location, DB-IP, IPinfo, and other providers maintain separate datasets, use different evidence, and refresh on different schedules.
Test the same public IP against several databases without changing the connection. If the origin AS and prefix stay the same while the city changes between providers, the difference comes from the geolocation datasets, not from the routing path.
| Signal | What it tells a vendor | What it does not prove |
|---|---|---|
| RIR records | Who holds or manages the address space | The physical location of a subscriber |
| ASN / BGP data | Which origin AS advertises the prefix | The end-user city |
| Geofeed | Operator-published location hints for prefixes | That every subscriber sits at the listed coordinates |
| Measurements / observations | Where a prefix appears to be used | An exact household address |
Reassigned prefixes leave stale location records behind
Address space moves between organizations and regions through transfers, mergers, and redeployment. Routing changes and geolocation refreshes are separate events. When a transfer changes the origin AS, BGP reflects the new origin as soon as routing is updated. Vendor geolocation records refresh on their own schedule.
Before touching the customer CPE, check prefix history, the current origin AS, the published geofeed, and the vendor record when several services place the same fixed-line public IP in an old location.
VPNs, proxies, tunnels, and privacy relays move the exit point
For traffic sent through a VPN or proxy, the destination sees the exit server public source address. A full-tunnel corporate VPN sends traffic from a laptop in Manchester through the company egress in London, Frankfurt, New York, or another configured site.
Privacy relays also replace the public address for the traffic they handle. Secure DNS is different. DNS over HTTPS and DNS over TLS change DNS transport. They do not route the browser web traffic through a new public source IP. Secure DNS alone does not move IP geolocation.
The accuracy radius matters more than the city label
A city name looks precise even when the underlying record is not. When a geolocation product returns an accuracy radius, keep that radius visible. A 50 km radius carries more diagnostic information than a city label shown without context.
A result centered on Denver with a 50 km accuracy radius means the returned coordinates are the center of a broad estimate. It does not prove that the user is inside Denver city limits.
Database result: Denver Coordinates: center point near Denver Accuracy radius: 50 km Website UI: "You are in Denver" Reality: the estimate covers a wide area around Denver
A common interface mistake is to drop the radius and display only the city. The database returned coordinates plus uncertainty. The interface presented a precise-looking city label.
03 / Precision
How accurate is IP geolocation, really?
IP geolocation has no universal accuracy percentage. Provider, country, access type, database version, and prefix history all affect the result. Fixed broadband and mobile networks use different address-assignment and egress designs. Recently transferred prefixes are especially exposed to stale mappings. IPv4 and IPv6 use separate mappings, so their coverage and refresh state differ.
For troubleshooting, match each field to the precision it actually provides:
| Level | How to use it | Good for |
|---|---|---|
| Country | Best suited to country-level defaults. Verify before a high-impact decision. | Localization, broad screening, content defaults |
| Region / state | Use for regional context, not precise positioning. | Regional content and diagnostics |
| City | Use as approximate city-level context, not as a physical position. | Nearby defaults, rough context |
| Street / household | Do not derive a street or household address from public IP alone. | Not a valid use of public IP geolocation |
A public IP lookup does not reveal a home address. Subscriber attribution comes from access-provider records tied to an exact time. On CGNAT, attribution adds translation state: public IP, translated source port or allocated port block, protocol, and timestamp matched against the operator logs. Access to subscriber records follows the law and process of the relevant jurisdiction.
04 / Method
A quick diagnostic when your IP shows the wrong city
Before filing a correction request, troubleshoot in the same order you would use on the network: exit service, access type, WAN/public-IP relationship, then the geolocation dataset.
Wrong IP location?
|
+--> VPN / proxy / corporate tunnel / privacy relay active?
| YES -> check the exit server location first
|
+--> Using mobile data or fixed wireless?
| YES -> inspect carrier addressing and shared gateways
|
+--> Wrong on one site but correct on others?
| YES -> focus on that database or the site cache
|
+--> Router WAN IPv4 in 100.64.0.0/10 and differs from the public IPv4?
| YES -> inspect CGNAT / shared provider translation
|
+--> Fixed line, no tunnel, wrong across several databases?
-> investigate a stale or mislabeled prefix mapping
A correct public IP, a valid route, and the expected origin ASN tell you the network path is healthy. They say nothing about whether the city label is current.
05 / Correction
Correcting a wrong IP location
Correction requests fix data, not topology. Use them for a stale vendor mapping or incorrect published prefix information. They do not alter CGNAT, a VPN exit, or a mobile carrier egress point.
Compare databases first. If all but one show the expected location, focus on the outlier vendor or the website cached copy.
Use the vendor correction channel for stale mappings. Major geolocation providers maintain separate datasets, so correcting one provider does not update the others.
For network operators, check the geofeed first. RFC 8805 defines the format for self-published IP geolocation feeds. Publish accurate prefix-level data and keep it current. Vendor ingestion remains vendor-specific, so a geofeed does not force every database to update on the same schedule.
Rebooting a router does not update a geolocation database. The displayed result changes only when the reboot leads to a different public IP whose mapping is different. The mapping for the original prefix remains unchanged.
For traffic sent through a VPN, the public exit IP changes. The destination then geolocates the VPN exit, not the original address. That is an exit-path change, not a correction to the original geolocation record. Banking, payment, and streaming services apply their own location and risk policies to VPN exits.
06 / Questions
Common questions
Does a wrong IP location mean I have been hacked?
No. A wrong city by itself is not evidence of compromise. Check the network path first: VPN or proxy exit, mobile-core egress, CGNAT, and disagreement between geolocation databases. Investigate security when separate indicators exist, such as unauthorized logins, unexpected configuration changes, or malicious traffic.
Why does my IP location keep changing?
Dynamic address assignment does not add a new geolocation record for every lease. It exposes a different public address or prefix mapping that already exists in the vendor dataset. The city label changes when the newly assigned address maps differently. A mobile-core egress change or a VPN exit change produces the same visible symptom by changing the public source IP.
Why is Google right when another site is wrong?
Google services with location permission have access to device-location and Wi-Fi positioning signals that an IP-only lookup does not. An IP lookup sees the public address and related network context. It does not receive the handset GPS position from the IP address.
Can I set my IP location manually?
IP geolocation is not a profile setting. Data providers and network operators maintain the source mappings. Correct a stale mapping at the data source. Changing the public exit IP only changes the address that websites geolocate.
Is IPv6 geolocation better than IPv4?
Native IPv6 bypasses IPv4 CGNAT for IPv6 traffic, but that alone does not improve geolocation accuracy. Prefix stability, carrier allocation strategy, and vendor mapping quality determine the result. A healthy IPv6 route does not validate the city label.
07 / Model
A better mental model
When the city looks wrong, verify the network facts first: public address, origin AS, prefix, and route. If those are consistent, inspect the geolocation layer instead of treating the city label as a routing fault.
Each layer answers a different question. Address assignment tells you what the subscriber received. NAT translation determines the public address visible on the Internet. BGP identifies the origin AS advertising the prefix. The mobile core or tunnel policy determines the egress path. For an IP-only lookup, the geolocation database supplies the city.
IPRevealed follows that order: expose the address and network facts first, then show geolocation as a separate data layer with its own uncertainty. A city label is useful context. It is not a GPS reading.
08 / Tools
Test it yourself
Work through the same layers this guide describes, in order.
- IP Lookup — check the public address, origin ASN, BGP routing, reverse DNS, and the reported location with its accuracy radius, shown as separate layers.
- VPN Leak Test — check whether a VPN or proxy exit is changing the public IP your connection presents, and compare the IPv4 and IPv6 paths.
Start with the network facts
Look up your current public address and see the origin ASN, routing and geolocation estimate as independent layers before deciding the city label is wrong.
Open IP Lookup09 / References
Technical references
- 3GPP TS 23.501
- System architecture for the 5G System (user plane function)