Geo QA testing proxies: test your own site from 22 countries

What should a geo QA test check?

A geo QA test should check every part of your site that changes with the visitor's country. Teams often find bugs in the places nobody opens from the office.

Pick the countries that make most of your traffic, then the ones with special rules.

Which country will my site think the IP is in?

Your site places the IP using its own geolocation source, and that source can disagree with the datacenter's real location. Datacenter IPs are registered to hosting networks, not to home internet providers. IP geolocation databases can place the same IP in a different city, or even a different country, from the datacenter that announces it.

Before a test run, check three things for each IP:

1. Your own source. Look up the IP in the database, CDN header or API your site really uses, such as the country header your CDN adds to requests.
2. The registry record. An RDAP lookup shows the network that holds the address. The check a datacenter IP guide shows how.
3. The geofeed. Some networks publish an RFC 8805 geofeed, which many databases read. The geolocation guide explains why a database can still be wrong.

If your source places the IP in the wrong country, write to support with the lookup result. If an IP does not work or is unusable for a lawful use, write to support: we fix it or replace it with an IP in the same country, subject to stock.

How do I run geo tests through a datacenter IP?

Run geo tests by giving each country its own IP and its own browser profile or test job. Fixed addresses keep results repeatable: the same IP on Monday and Friday shows whether a change came from your release, not from the network.

# Documentation addresses: replace with two IPs from your account
for P in 203.0.113.24:8000 203.0.113.97:8000; do
  echo "== $P"
  curl -s -o /dev/null -x "http://USERNAME:PASSWORD@$P" \
    -w "%{http_code} -> %{redirect_url}\n" https://example.com/
done

When does a datacenter IP give the wrong test result?

A datacenter IP gives the wrong result when your site treats hosting networks differently from home connections. If your bot management, firewall or fraud rules challenge or block hosting ASNs, the test sees that rule, not the page a customer sees.

Three ways to handle it:

• Add your test IPs to an allowlist in those rules for the QA environment, so tests reach the real page.
• Test the country logic in staging, where hosting-network rules are off.
• For questions about what home users see in practice, use real-user monitoring from your analytics, not a proxy.

The datacenter vs residential comparison explains the difference in network type.