Proxy Geolocation Consensus Test: Validate Country, Region and Usability

A proxy exit can be routed from the expected country while one database still labels it elsewhere. It can also appear correct in several databases yet deliver the wrong language, currency or availability on the authorized destination. A single lookup is therefore not enough to approve a proxy pool for localization, ad verification or market research.

The right question is not “Which lookup is true?” It is “What location precision does this workflow require, which independent signals support it, and does the destination behave as expected?” This guide turns those questions into a repeatable acceptance test without treating IP geolocation as household-level positioning.

Define the required precision before testing

Country, region and city claims are different products. Approving a country-level use case does not validate a city-level claim.

IP geolocation is inherently approximate. It should not be used to identify a household, person or street address. City labels often represent a network registration point, routing hub or database estimate rather than the physical user location.

Use four evidence families

1. Operator-published location

RFC 8805 defines a simple geofeed format that lets a network operator publish prefix-to-location mappings at coarse granularity. RFC 9092 describes how consumers can discover geofeeds and recommends cross-validation because publication authority and repository authentication can vary.

Treat an authenticated or registry-linked geofeed as valuable operator intent, not infallible observation. Record the prefix match and feed freshness, not just the returned country.

2. Independent geolocation databases

Query at least two independently maintained datasets whose update times are known. Avoid counting multiple products built on the same upstream dataset as independent votes. Record country, region, city, confidence or accuracy radius when available, and dataset build date.

3. Network and ownership evidence

Record the observed exit address, IP family, prefix, ASN and reverse path characteristics at a coarse level. RIR registration and ASN country are ownership signals, not physical-location proof. They can explain disagreements but should not automatically override operational observations.

4. Authorized destination behavior

Use destinations you own or are permitted to test. Observe language, currency, catalog, tax presentation, availability, consent flow and region marker. Keep cookies, account locale, request headers and redirects controlled so the test measures the network path rather than stale application state.

Build a weighted consensus model

Do not simply count votes. Weight each signal according to independence, freshness, precision and relevance to the use case.

signal_score = independence × freshness × precision_fit × source_reliability
country_confidence = supporting_country_score / total_usable_score

One practical starting policy is:

• operator geofeed: strong for intended country or region when authority and freshness are verified;
• independent databases: medium to strong, reduced when datasets share lineage or are stale;
• ASN and registry: contextual, not decisive for physical location;
• destination behavior: decisive for that authorized workflow, but not universal proof of physical location.

Publish the weights and thresholds before testing. Do not change them after seeing a difficult pool.

A reproducible eight-step test

1. Freeze the sample plan

Choose a random sample across providers, products, countries, IP families and time windows. Do not let the proxy provider select only known-good exits. Use a minimum sample large enough to expose disagreement and reallocation, then expand high-risk pools.

2. Capture the actual exit

Use an endpoint you control to record the public exit address, protocol, timestamp and sanitized session alias. Never assume the configured gateway address is the exit. Keep raw IP access restricted and remove it from public reports.

3. Normalize the prefix

Map the address to the most specific relevant prefix and record IPv4 or IPv6. For geofeeds, RFC 8805 says nested entries are allowed and the longest matching prefix should be preferred.

4. Collect evidence independently

Query the operator feed, two independent location datasets, registry context and the authorized destination. Record each result separately before calculating consensus. Cache responsibly and respect provider query limits.

5. Control application state

Start from an isolated cookie jar or browser context. Set the account locale, Accept-Language, timezone and test parameters explicitly. Redirects must remain inside the approved destination set. The regional price validation guide provides a stricter protocol for currency and catalog checks.

6. Score each precision tier

Calculate country first. Only score region if country passes, and only score city if region passes. Missing city data is not the same as a contradictory city result. Keep “unknown,” “missing” and “conflict” separate.

7. Repeat over time

Re-run the same sample after 24 hours and seven days, then after any provider reallocation. Database corrections and route changes do not arrive simultaneously. A pool that passes once but changes labels frequently needs a stability flag.

8. Decide by workflow

Use four outcomes:

• accept: required tier meets the threshold and destination behavior matches;
• accept with limitation: country passes, but region or city does not;
• quarantine: evidence conflicts or changes materially between runs;
• reject: required country fails or mandatory destination behavior is wrong.

Suggested evidence schema

sample_id
provider_alias
product_type
session_alias
ip_family
exit_fingerprint
prefix_alias
asn_alias
operator_geofeed_country
geofeed_checked_at
database_a_country_region_city
database_a_build_date
database_b_country_region_city
database_b_build_date
destination_country_marker
destination_currency_language
country_confidence
region_confidence
city_confidence
decision
tested_at

Use a keyed or salted fingerprint instead of publishing a full exit address. Keep supplier credentials, account cookies, user identifiers and proprietary dataset responses out of shared evidence.

Separate location from residential quality

A country match does not prove that an exit is residential, dedicated, stable or suitable for the destination. ASN type, reverse DNS, hosting classification, session behavior, latency and block rate are separate dimensions.

Combine this test with the shared versus dedicated proxy acceptance test and the residential proxy session stickiness test. Do not let a high geolocation score compensate for unstable sessions or unacceptable destination results.

Diagnose common disagreement patterns

Geofeed correct, databases stale: retain the exit in quarantine until the datasets relevant to the workflow update, or accept it with an explicit limitation when the authorized destination already behaves as required.

Databases agree, destination differs: inspect cookies, account locale, language headers, timezone, DNS path, redirects and destination-side classification. Re-test from a clean context.

ASN country differs from exit country: this can be legitimate for globally operated networks. Treat registry country as ownership context, not a location verdict.

IPv4 passes, IPv6 fails: score address families separately. Confirm the client is not leaking or bypassing the intended route on one family.

City labels disagree within one metro area: compare the workflow’s real tolerance. A city-specific promise requires stronger proof than a country-level use case.

Release checklist

• [ ] Required precision tier is defined before testing.
• [ ] Samples are random and span time, region and IP family.
• [ ] Actual exits are observed through an authorized endpoint.
• [ ] Longest-prefix matching is applied to geofeed data.
• [ ] At least two genuinely independent databases are used.
• [ ] Dataset build dates and feed freshness are recorded.
• [ ] ASN and registry country are not treated as physical truth.
• [ ] Cookies, locale, headers, timezone and redirects are controlled.
• [ ] Country, region and city are scored separately.
• [ ] Unknown and conflicting results remain distinct.
• [ ] Retests cover 24-hour and seven-day stability.
• [ ] IPv4 and IPv6 outcomes are reported separately.
• [ ] Full exits, credentials and customer data are not published.
• [ ] Mandatory proxy routing fails closed instead of going direct.

FAQ

How many databases should agree?

There is no universal number. Use at least two independent datasets, but weight freshness, lineage and required precision. Two stale copies of one upstream source are not two independent confirmations.

Is an operator geofeed ground truth?

It is an important statement of operator intent. Verify authority and freshness, then cross-check it with other sources and authorized destination behavior.

Can a proxy be accepted when the city is wrong?

Yes, if the approved workflow requires only country or region accuracy and its threshold is met. The product must not be marketed or used as city-accurate in that case.

Does a correct country prove the IP is residential?

No. Location, network type, exclusivity, stability and destination acceptance are separate properties and need separate tests.

Compliance note

Test only proxy resources, accounts and destinations you are authorized to use. Respect database licenses, lookup limits, destination terms, privacy requirements and data-retention policies. Do not use IP geolocation to infer a person’s precise location, evade geographic restrictions, manipulate offers or bypass access controls.

Source note: RFC Editor, “A Format for Self-Published IP Geolocation Feeds,” August 2020; RFC Editor, “Finding and Using Geofeed Data,” July 2021; MaxMind, “Geolocation Accuracy,” reviewed September 11, 2026.