Proxy Showing the Wrong Location? Country and City Checks

Identify which location is wrong

Start with the observation: an IP lookup says another country, a website selects another currency, or a browser map shows your actual position. Those outcomes can have different causes. Replacing the proxy without identifying the signal makes the next result hard to interpret.

MaxMind explains that IP geolocation is approximate, databases can disagree, and mobile addresses may be used across a broad area. An accuracy radius is an uncertainty indicator, not the distance from the proxy to a confirmed device location.

The browser Geolocation API is a separate, permission-controlled mechanism. Changing an HTTP proxy is not the same action as changing a browser's location permission or the device data available to that API.

Verify the exit from the affected client

Open What is my IP in the browser profile that has the problem. For a server worker, run your own IP-echo endpoint through that worker's configured HTTP client instead. Record the result and repeat it immediately before the target request.

Then run a separate direct test. If direct and proxied results match, investigate a bypass rule, an inactive extension or a client that ignored the proxy setting. Matching addresses are a reason to investigate, not a universal proof of a leak: the paths may legitimately share an exit.

Do not infer the exit country by resolving the gateway hostname. The address accepting your proxy connection and the address reaching the website can be different. The HTTPX, aiohttp and Node.js fetch examples help establish routing before you test location.

Keep raw test results in your private support record. When sharing a screenshot publicly, hide credentials and any customer identifiers.

Why a mobile exit can have a broad location

A mobile connection can traverse a carrier gateway before reaching the internet. Multiple devices can share public IPv4 addresses, while private-side addresses do not identify the public exit. RFC 6598 reserves 100.64.0.0/10 for shared address space used between carrier-grade NAT and customer equipment.

An address in that shared range is not a globally unique public location marker. Read the CGNAT and mobile proxy explanation for the network context, then use the exit observed by the destination for your country test.

For a region-sensitive application, write down the actual requirement. "The exit is classified as US by the target's location system" is a different acceptance criterion from "a lookup returns New York." A commercial country label alone does not establish that every database or website will return the same city.

Our US mobile proxy and UK mobile proxy pages describe country offerings. Confirm the available carrier and region in the dashboard before purchase; verify the specific target behavior during your own acceptance test.

Check browser location and session state separately

Use a test profile for a service you are allowed to assess. First deny or reset location permission and record the site's result. Then, if the test requires it, permit geolocation and record which API result or prompt changed. Do not assume a site uses only IP location simply because it never shows a map.

For your own application, Chrome DevTools Sensors can emulate geolocation. It is a browser test aid, not an IP-routing feature. Record that the coordinate was emulated so a QA report does not present it as a measured network location.

Saved country preferences, language, cookies and a signed-in account can influence the page you see. Change one of those at a time. A clean test profile helps isolate state; it does not guarantee another site's decision or authorize bypassing its access rules.

Use the WebRTC test and DNS leak guide when those paths are relevant. A DNS resolver's location does not, by itself, prove where the HTTP request exited.

Handle a disagreement between GeoIP databases

Compare results for the same exit IP at the same time. Record each provider, the country and region returned, and whether the data product exposes a confidence or accuracy field. Do not select only the result that agrees with the country you hoped to see.

If one database appears stale, ask the network provider for an investigation and give it the exact evidence privately. MaxMind offers a correction process; an accepted change applies to that provider's dataset, not every website's copy or competing database. A website may continue using older data until it updates.

Do not submit an invented city to make a QA test pass. If the carrier pool serves a broad region, a less precise result may be the accurate representation. When a target's location rule is contractual or operationally essential, ask the provider whether it can meet that exact requirement before committing to a large order.

Use a repeatable acceptance record

For each test, keep: the purchased location and carrier, the proxy endpoint alias, UTC timestamp, observed exit, IP version, data sources checked, target URL, browser or worker version, location-permission state, account state and the target's observed result. Store passwords elsewhere.

Run a second sample after a planned reconnect or rotation if your workflow rotates. A successful first IP does not prove the entire rotating pool has the same database label. Keep the account state unchanged so you can attribute any changed result to the connection test.

For a support request, summarize the mismatch in one sentence: "The configured worker exits through the expected country in two lookups, but our target returns another region when signed in." That is more actionable than "the proxy location is wrong." Link the evidence and state which acceptance criterion failed.

This guide is based on the primary sources checked October 14, 2026 and our diagnostic procedure. We did not survey carrier pools or measure a geolocation accuracy percentage for Coronium.

Frequently asked questions