Short answers
Why do two lookup services disagree about the same address?
Because geolocation is a database, not a property of an address. Each service builds its own from registration records, routing and latency measurements, and they update at different speeds. Disagreement is normal, especially on addresses that recently changed hands.
Which answer does a website actually use?
That depends on the site. It may use an IP-location database, a saved market choice, account settings or the requested domain. A public lookup result cannot tell you which input determined the page you received.
What is the difference between the registered country and the observed one?
The registered country is what the block holder filed with the regional registry. The observed country is inferred from how the address behaves. They differ often, because a company registered in one country routinely assigns addresses used in another.
I have the right country and the site still shows the wrong market. Why?
The address is only one possible input. Language preferences, browser timezone, saved cookies, account settings, delivery details and the requested domain may affect the result. Each site chooses its own rules; there is no universal order of priority.
How do I check whether an address reads as a home line or a carrier connection?
Record the exit’s ASN, operator and the source of any network classification. That classification is separate from its country lookup and does not identify the browser or device. Our mobile pool uses carrier modems; residential peer devices can use home broadband or mobile connections, so that pool does not guarantee a household connection.
What if nothing was online in the country I asked for?
Then you never got that country: the gateway answers 502 with E_NO_STOCK_COUNTRY rather than sending you out of a neighbouring one. Check what is online before you start, and treat the country as a live quantity rather than a setting.
Why country lookups differ
There is nothing inside an IP address that says where it is. Every "this address is in that country" is somebody’s inference, built from registry records, routing paths, round-trip times and corrections, and refreshed on their own schedule.
So the question is never "where is this address" but "which database is this site using, and what does it say today". Two services describing 203.0.113.10 differently are both doing their job.
Registered country against observed country
The registry record says who holds a block and which country they filed. That is administrative, and it travels badly: a network registered in one country can perfectly legitimately use an address in another.
Most commercial databases try to record where an address is used rather than where it is registered, which is usually what you want. The two diverge most on recently transferred blocks and on networks that span borders.
Check the exit yourself
Start with the exit IP reported by the echo endpoint. The API connection test returns exit_country only when country_verified is true; otherwise the country is null. That flag records an observed country classification, not proof of a physical location. Record the source and time of any separate lookup.
The first prompts for the proxy password in a terminal; the transfer timeout does not limit password entry. The API call starts a separate check, up to six times a minute. With ondemand rotation, the checks may use different exits. A requested country is a selection; check the returned country_verified flag.
curl --disable --silent --show-error --noproxy '' --connect-timeout 5 --max-time 15 -x "http://gw.portproof.org:7000" \
--proxy-user "USERNAME-peer-us-rot-ondemand" https://api.portproof.org/v1/echo-ip
curl -X POST https://api.portproof.org/v1/traffic/test \
-H "Authorization: Bearer $PORTPROOF_API_KEY" -H "Content-Type: application/json" \
-d '{"pool":"residential","country":"US","rotation":"ondemand"}'Look the exact exit IP up in the geolocation database the site uses, if known, or compare two public services. Agreement shows how those services classify that address. It does not prove the destination saw the same exit or explain its market choice. Rotation can change the exit between requests. For connection and rotation checks, use the curl testing guide.
Other signals a site may use
- Accept-Language
- The browser’s preferred languages, which do not establish the visitor’s country.
- Timezone
- The browser timezone, which a site can read separately from the request’s source address.
- Cookies from an earlier visit
- A market or currency choice stored on a previous run and replayed.
- A signed-in account
- Account settings or a saved market choice that the site may reuse.
- A saved postcode or store
- Delivery details or a selected store that may determine the catalogue shown.
- The domain you requested
- A country-specific domain may select a market or language, according to the site’s rules.
For a controlled comparison, start with a fresh browser context and choose locale and timezone separately from the proxy route. Change one input at a time; setting them all together cannot identify which changed the result. See what Accept-Language tells a site. The search-specific method is in see search results from another country.
Network type and browser settings
A site’s classification of the exit network is separate from its country lookup. If your test requires a particular network type, record the exit ASN and the classification source. Check that requirement separately from the page’s selected market.
Mobile traffic runs on carrier modems operated by our network partner; residential traffic runs on opt-in peer devices in the partner network.
Choose mobile 4G/5G when a carrier-network route is part of your test. The residential pool uses opt-in peers on home broadband or mobile networks; it does not guarantee a household connection. For a mobile app or layout check, configure the device, viewport, locale and browser-location settings separately. Both pools use one balance; see mobile or residential.
Read availability before blaming the exit
Both pools are built from devices that come and go, so a country is true right now rather than permanently. GET /v1/traffic/countries answers what is online per pool, cached for a minute, and the same per-country counts are on locations.
When nothing is online in the country you asked for, the gateway refuses with 502 and E_NO_STOCK_COUNTRY instead of substituting a neighbour, because a silent substitution would give you data you would trust and should not. What to do about that answer is in fix CONNECT tunnel failed errors.
The order to check things in
- Print the exit with explicit proxy settings and record the time. Compare a direct request as a control; an unexpected address match calls for checking the route.
- Look that exact exit IP up and record the lookup source, time and country. Keep the lookup classification separate from the market the site displayed.
- Compare a second lookup service. Agreement is useful evidence, but does not establish which database or other inputs the site used.
- Start with a fresh browser context, no reused cookies and no signed-in account. Choose locale and timezone explicitly, then vary one input at a time.
- Confirm the pool suits the job, and that the country had devices online when you ran.
- If the mismatch remains, send support the timestamp, requested country, lookup sources and results, and the username with the account part removed. Keep passwords and API keys out of the report.
Keep the first checks small, then compare account usage before and after a representative run. Measure the traffic your workflow actually uses rather than assuming the echo response’s size describes the whole job. See per-GB pricing, the bandwidth calculator and the connection format and errors in the setup docs.
What is not allowed
What is not allowed: reading a market from the country you sell in is ordinary business research. Presenting yourself as a local person to evade a geographic restriction you agreed to, and anything else on the declined list, is not. See the acceptable-use policy.