Proxy Geo-Targeting Accuracy Audit: Test Country, Region, City and ASN Claims

Buying a “city-targeted” or “country-targeted” proxy does not automatically prove that every exit will appear in that location to every destination. IP geolocation is an estimate built from changing allocation, routing and observation data. Different databases can disagree, while mobile, carrier-grade NAT and recently reassigned blocks can move faster than a vendor's update cycle.

A useful procurement test therefore asks a precise question: does the delivered pool satisfy the location level required by the workload, across enough exits and enough time, when observed by the destinations that matter? This guide turns that question into a repeatable audit.

Define the business requirement first

Do not start with map pins. Write the minimum acceptable scope:

• country only;
• subdivision or state;
• metro or city;
• autonomous system number or ISP class;
• residential, mobile or hosting classification;
• sticky duration required by the workflow.

Country accuracy may be sufficient for localized search result collection. A state-level compliance workflow needs stronger evidence. City labels are inherently less precise and should never be interpreted as a household or street address.

Create a clean test inventory

For each proxy plan, record the product name, ordered target, protocol, session mode, rotation trigger and permitted concurrency. Assign a test identifier that contains no credentials.

Build separate cohorts for:

1. country-selected rotating sessions;
2. region-selected rotating sessions;
3. city-selected rotating sessions;
4. sticky sessions at each supported target level;
5. any ASN or ISP-selected product.

Keep authentication, client version and destination set constant inside a cohort. Changing multiple variables makes mismatches difficult to explain.

Use independent observations

Never grade a proxy using only the provider's own location response. Use at least two independent IP intelligence sources plus a destination you control. The controlled destination should return the observed source IP, request identifier and server region.

Compare structured fields rather than screenshots:

• country code;
• subdivision code;
• city label when present;
• latitude, longitude and accuracy radius when present;
• ASN and organization;
• connection or network type;
• observation timestamp.

Treat missing fields as missing, not incorrect. Treat provider disagreement as uncertainty that requires workload-specific evidence.

Respect accuracy radius and confidence

Coordinates are not exact points. When a source provides an accuracy radius or confidence value, store it with the result. A coordinate near a city center with a 100-kilometer radius is not evidence of city-level precision.

Create three evidence tiers:

• Confirmed: independent sources and the controlled destination support the purchased level.
• Ambiguous: sources disagree, a field is missing, or the confidence area spans the boundary.
• Mismatch: reliable evidence places the exit outside the purchased target.

Do not force ambiguous observations into pass or fail. Report them separately and set an allowed ambiguity ceiling.

Sample the pool, not one session

One successful exit proves almost nothing about a rotating pool. Request enough independent sessions to expose long-tail errors.

For an initial screen, sample at least 100 unique exits per purchased country and at least 30 per city or ASN target where the pool allows it. Repeat across morning and evening windows in the target region. Larger pools and higher-risk workflows need larger samples.

Deduplicate by observed exit IP before calculating accuracy. If the service repeatedly returns the same address, report both request count and unique-exit count. Otherwise a small sticky subset can make the pool appear healthier than it is.

Separate targeting accuracy from availability

Track four outcomes independently:

1. allocation succeeded;
2. connection and proxy authentication succeeded;
3. destination response completed with correct content;
4. the observed exit matched the purchased target.

A timeout is not a geolocation mismatch. A correct country attached to a truncated response is not a successful request. This separation lets procurement distinguish pool accuracy, capacity and transport quality.

Test rotating and sticky behavior

For rotating sessions, verify that a rotation trigger produces a new eligible exit without silently changing the requested target. For sticky sessions, send periodic probes throughout the promised window and record:

• whether the exit IP remains stable;
• whether country, region, city and ASN labels remain stable;
• whether authentication survives idle periods;
• whether replacement after failure stays inside the target.

Use the residential proxy session stickiness test for a fuller session protocol.

Check route and DNS evidence

Location appearance can be affected by more than the exit IP. Test IPv4 and IPv6 separately. Confirm whether the destination observes the intended address family, and ensure DNS resolution follows the approved client or proxy path.

Record redirect hops and final origin. A test that begins through the selected proxy but follows a redirect directly can produce misleading evidence. The proxy DNS leak validation guide helps isolate resolver behavior.

Build a scoring model

Calculate metrics using unique exits:

• country match rate;
• region match rate among exits with region evidence;
• city confirmed, ambiguous and mismatch rates;
• ASN or ISP match rate;
• completion rate;
• median and p95 connection latency;
• unique exits per 100 successful allocations;
• target retention after sticky-session replacement.

Do not combine levels into one opaque score. A pool can have excellent country accuracy and weak city precision. Show the denominator for every metric.

Set acceptance gates

Define gates before seeing results. A practical example is:

• country match at or above the contracted threshold;
• city mismatch below the agreed ceiling, with ambiguity reported separately;
• no unexpected hosting classification in a residential cohort beyond the allowed rate;
• minimum unique-exit diversity;
• completion and latency within operational limits;
• no target drift during the required sticky window.

Contract language and workload risk should determine the exact numbers. Do not invent an industry-wide guarantee.

Investigate mismatches safely

For every mismatch, preserve the test identifier, observed IP, requested target, timestamps, sanitized client configuration, independent observations and response integrity result. Recheck the same exit after a short delay and again after the geolocation sources' normal refresh window.

Look for clustered mismatches by prefix, ASN, gateway, region and time. A cluster is more actionable than isolated screenshots. Share only the minimum evidence required with the provider and never include proxy passwords.

Procurement checklist

• Required geographic level documented
• Rotating and sticky cohorts separated
• IPv4 and IPv6 tested independently
• At least two independent intelligence sources used
• Accuracy radius and confidence retained
• Unique exits deduplicated
• Multiple target-local time windows sampled
• Availability separated from location accuracy
• Country, region, city and ASN reported separately
• Ambiguous observations preserved
• Sticky target retention tested
• Acceptance gates defined before results
• Credentials excluded from evidence

FAQ

Why do two geolocation services disagree?

They use different data sources, update schedules and inference methods. IP assignments and routing also change. Disagreement is evidence of uncertainty, not automatic proof that one source is fraudulent.

Is a city coordinate exact?

No. It often represents a broad geographic area or population center. Use the accuracy radius and confidence information, and never use IP geolocation to identify a household.

Can the proxy provider's dashboard be the reference?

It is useful for confirming the ordered target, but it should not be the only measurement source. Independent observations better represent what external destinations may see.

How often should the audit run?

Run it before purchase, after a material pool or routing change, and on a recurring schedule proportional to business risk. High-volume ad verification or compliance-sensitive workloads need more frequent checks than occasional research.

Compliance note

Test only destinations you own or are authorized to access. Respect platform terms, rate limits, privacy requirements and regional law. Minimize retained IP data, apply an appropriate retention period, and do not use geolocation results to infer a precise personal address.

Research note: Cloudflare IP Geolocation documentation, updated August 27, 2026; MaxMind GeoIP web service documentation, response specifications and geolocation accuracy guidance, reviewed September 14, 2026.