Why IP Geolocation Shows the Wrong City

// The City-Level Accuracy Problem

You look up an IP address and the country is correct — United States, Germany, Japan — but the city is unmistakably wrong. A user in Portland appears to be in Seattle. A London office shows as Manchester. A visitor from rural France geolocates to Paris.

This is not a bug in your lookup tool. It is a fundamental limitation of how IP geolocation works. Geolocation databases map IP address blocks to geographic areas based on registration data, routing hints, and latency measurements. They do not know where individual devices physically are.

Country-level accuracy typically exceeds 90–95% for most IP types. City-level accuracy drops significantly — often to 50–80% depending on the IP category. Understanding why helps you interpret results correctly and avoid bad security or business decisions based on a wrong city pin.

// VPN and Proxy Effects

The most common cause of wildly incorrect geolocation is a VPN or proxy. When a user connects through a VPN, their traffic exits from the VPN server's IP address, not their own. Geolocation shows the VPN server's city — which may be in a completely different country from the user.

Commercial VPN providers operate exit nodes in dozens of countries. A user in Brazil connecting to a US exit node will geolocate to whatever city hosts that node — often Ashburn, Virginia (a major data centre hub) or Los Angeles. The country will be United States, which is technically correct for the IP, but tells you nothing about the user's real location.

Corporate proxies and privacy tools (Tor, iCloud Private Relay, corporate Zscaler gateways) have the same effect. The IP you see is the egress point, not the origin.

What to do: Check the ASN/ISP field. VPN and hosting ASNs (NordVPN, M247, Datacamp) are strong indicators that city geolocation reflects infrastructure, not a person.

// Mobile Carrier NAT

Mobile networks use Carrier-Grade NAT (CGNAT) and centralised gateways to route millions of subscribers through a relatively small pool of public IP addresses. These gateway IPs are often registered to the carrier's headquarters or a major network operations centre, not the cell tower the user is connected to.

A subscriber in Lyon, France might appear to be in Paris because Orange or Free routes all mobile traffic through a Paris gateway. The country is correct (France), but the city reflects the carrier's infrastructure geography, not the subscriber's position.

4G and 5G networks exacerbate this because users move constantly while retaining the same carrier-assigned IP for the duration of their session. The geolocation database has no way to know the phone moved 200 km since the IP was assigned.

// Corporate Egress and Remote Work

Large organisations route all employee internet traffic through centralised firewalls or Secure Web Gateways (SWG). Whether an employee works from home in Munich, a café in Hamburg, or the Berlin office, their public IP is the same corporate egress address — typically registered to headquarters or a primary data centre.

This was especially visible during the remote-work shift: companies saw login attempts from "the office city" even when every employee was at home. Security teams that geo-blocked by city found themselves locking out legitimate remote workers.

Practical implication: Never use city-level geolocation alone for access control in organisations with centralised egress. Country-level blocking is more defensible; city-level blocking on corporate IPs is unreliable.

// CDN Anycast and Cloud Providers

Content Delivery Networks (CDNs) like Cloudflare, Akamai, and Fastly use anycast — the same IP address is announced from dozens of locations worldwide. BGP routes each user to the nearest edge node, but geolocation databases can only assign one city per IP block.

Cloudflare's famous 1.1.1.1 DNS resolver is anycast. Depending on which database you query and when it was last updated, it might geolocate to San Francisco, London, or any city with a Cloudflare PoP. The country may be correct for the block's registration, but the city is essentially arbitrary for anycast addresses.

Cloud provider IPs (AWS, Azure, GCP) are registered to the region where the IP block was allocated, not where your specific virtual machine runs. An EC2 instance in Frankfurt might share geolocation traits with blocks registered to US-based Amazon infrastructure depending on how the block is mapped.

// Database Update Lag

Geolocation databases are updated on schedules ranging from daily to monthly. When an ISP reassigns an IP block from one city to another — or sells a block to a different regional provider — there is a lag before all databases reflect the change.

IP & Domain Tracker uses MaxMind GeoLite2, updated monthly. During the gap between a real-world IP transfer and the database update, lookups return stale city data. This is especially common when:

• ISPs merge or acquire other providers and reorganise IP allocations
• IPv4 blocks are traded on secondary markets and moved between regions
• A hosting company opens a new data centre and begins using IPs registered elsewhere
• Government or military blocks are repurposed for commercial use

If country is correct but city seems outdated, check the IP's RDAP registration date and compare the ASN against RIPEstat or similar routing data. A recent registration change with an old city pin strongly suggests database lag.

// When Country Is Accurate but City Is Not

This is the normal case, not the exception. IP blocks are allocated by Regional Internet Registries to countries (or regions within countries). Country assignment is baked into the allocation process and reinforced by BGP routing data. City assignment is a best-effort overlay applied by commercial geolocation vendors using proprietary algorithms.

Think of it in layers:

1. RIR allocation — determines country/region (high confidence)
2. ISP service area mapping — narrows to city for residential blocks (moderate confidence)
3. Infrastructure geography — data centres, gateways, anycast (city = DC location)
4. User physical location — unknown to the database entirely

For fraud detection, use country + ASN + behavioural signals, not city alone. For content localisation, prefer browser language settings or explicit user preference over IP city. For compliance, consult legal counsel — IP geolocation city is generally not sufficient evidence of a user's physical jurisdiction.

// Practical Troubleshooting Steps

When you encounter a suspicious or unexpected city result, work through this checklist:

1. Look up the IP on ip-tracker.online and note country, city, ASN, and ISP.
2. Check the ASN — is it a VPN, hosting, CDN, or mobile carrier? If yes, discount city accuracy.
3. Compare with traceroute — do network hops align with the geolocated country?
4. Test from another tool — query a second geolocation source; agreement on country but disagreement on city confirms city-level uncertainty.
5. Check RDAP registration — when was the block last updated? Recent changes may mean stale city data.
6. Ask the user — if this is a support ticket, browser-based geolocation (with consent) or simply asking the user is more reliable than IP city.
7. Review your use case — do you actually need city precision, or is country + ASN enough?

Wrong city geolocation is a feature of how the internet is built, not a failure of your tools. The key is knowing when to trust city data and when to fall back to country, ASN, and other signals.

// Related Articles