How to Verify Proxy Location Accuracy: Country, City, ASN and DNS Checks

A proxy advertised as “New York,” “London,” or “Singapore” can still be classified differently by websites, fraud systems, analytics platforms, and IP databases. Location is not a single property stored inside an IP address. It is an inference assembled from routing, registry, operator-published geofeeds, observed network behavior, and database refresh cycles.

This guide provides a repeatable way to test country, region, city, ASN, DNS, and session consistency before using a proxy for authorized data collection, localization checks, ad verification, or market research.

Define the accuracy level you actually need

Country-level accuracy is enough for many localization tests. City-level accuracy is harder and should be treated as a confidence range rather than an exact physical point. ASN and network-type accuracy matter when a workflow requires residential, mobile, or data-center characteristics. Write the acceptance rule before testing: for example, “country must match, ASN must remain stable, city may vary within the same metro area.”

Build a clean test matrix

Test at least five fresh sessions per advertised location. Keep the target endpoint, protocol, and request headers constant. Record UTC time, proxy endpoint, returned IP, country, region, city, ASN, organization, DNS resolver region, latency, and session identifier. Repeat the test at different times because databases and routing announcements can change.

Compare multiple independent signals

Do not accept one lookup result as ground truth. Compare several independent location datasets and note agreement at each level. Then compare the IP prefix and ASN with the advertised network type. A country match with a clearly inconsistent ASN or organization deserves investigation.

Operator-published geofeeds can help explain recent prefix moves, but consumers refresh them on different schedules. Temporary disagreement does not always mean the proxy is physically elsewhere; it may indicate stale data.

Check DNS separately

A proxy can present the expected exit IP while DNS queries use a resolver in another region. This may affect localization, content selection, or risk scoring. Record the observed resolver region and compare it with the exit region. The correct requirement depends on the use case: strict localization tests may require regional alignment, while other workflows only require that DNS does not expose the client network.

Test session consistency

For sticky sessions, repeat requests during the promised session window and confirm that the IP, ASN, and country remain stable. For rotating sessions, confirm that rotation follows the expected trigger and that the distribution remains within the selected region. Unexpected cross-country changes should fail the test even if individual IPs work.

Separate location errors from target-side behavior

A target may use its own database, cookies, account history, language settings, or device signals. Use a clean browser profile and controlled headers when testing. If a site disagrees with independent location checks, document that as target-specific classification rather than immediately labeling the proxy inaccurate.

Score results with clear thresholds

Use a simple scorecard:

• Country agreement: required for every tested session.
• Region agreement: required when the workflow depends on state or province.
• City agreement: evaluate within an agreed metro radius.
• ASN consistency: verify the ASN and organization match the product expectation.
• DNS alignment: pass, acceptable variance, or fail according to the workflow.
• Session stability: compare actual behavior with the advertised sticky or rotating policy.
• Latency: report median and tail latency separately from location accuracy.

Troubleshooting mismatches

If one database disagrees, retest after its normal refresh interval and compare operator geofeed information. If several sources disagree, isolate the IP prefix and ask the provider for clarification. If the ASN or network type is wrong, stop using the affected pool for workflows that depend on that classification. Keep evidence by prefix and timestamp rather than relying on screenshots alone.

Buyer evaluation checklist

1. Are locations tested across multiple sessions and times?
2. Is country accuracy measured separately from city accuracy?
3. Are ASN and organization checked against the promised proxy type?
4. Is DNS behavior tested independently?
5. Are sticky and rotating sessions validated differently?
6. Does the provider explain how location corrections are handled?
7. Can problematic prefixes be isolated without disrupting the full pool?

FAQ

Why do two databases show different cities?

They may use different evidence and refresh schedules. City-level IP geolocation is probabilistic; treat it as a confidence range.

Does low latency prove the proxy is in the advertised city?

No. Latency is useful supporting evidence, but routing and network architecture can make nearby and distant paths look similar.

Should every rotating IP have the same ASN?

Not necessarily. Residential pools can span multiple access networks. The important test is whether each ASN and network type fits the advertised product and selected region.

For authorized regional testing, review available locations and session models on the 98IP English site. Always follow target terms, applicable law, and data-minimization requirements.

Research basis: RFC Editor, A Format for Self-Published IP Geolocation Feeds, August 2020; RFC Editor, Finding and Using Geofeed Data, February 2025.