IP Geolocation Isn't Enough for Regional App Testing

Xavier Fok — Tue, 22 Sep 2026 08:38:08 +0000

You point your test at a proxy in the right country, the app store shows the right storefront, and you ship. Then support tickets come in from real users on actual carrier networks seeing a different payment flow than what you tested.

I run a mobile proxy network on real SIM cards in Singapore, and this came out of running it. The gap usually isn't the IP's country. It's the IP's ASN classification. Platforms that do regional testing at scale check whether an IP belongs to a "hosting," "residential," or "mobile" range, and a VPN or datacenter exit almost always lands in "hosting" no matter what country it geolocates to.

Here's a script that checks that classification directly instead of trusting the country field alone:

import os
import requests

PROXY_URL = os.environ["PROXY_URL"]  # e.g. socks5h://user:pass@host:port

session = requests.Session()
session.proxies.update({"http": PROXY_URL, "https": PROXY_URL})
session.headers.update({"Accept-Language": "en-SG,en;q=0.9"})

ip_data = session.get("https://ipapi.co/json/", timeout=15).json()
print("IP:", ip_data.get("ip"))
print("Org:", ip_data.get("org"))
print("Mobile:", ip_data.get("mobile", "not reported"))

the country check passes, the classification doesn't

When your app makes a request through a proxy, the server on the other end doesn't just read the IP's country. It reads the IP's ASN, and IP intelligence providers classify most ASN blocks as roughly "hosting," "residential," or "mobile." A VPN exit or a datacenter proxy in the right country still resolves to a "hosting" ASN, because that's genuinely what it is. A consumer SIM issued by an actual carrier resolves to "mobile," because that's genuinely what it is too.

This matters because platforms that maintain IP reputation scoring (which by now includes most app stores, ad networks, and payment processors) use that classification as a signal independent of the country field. Your test session can show the correct storefront and still get routed through a different code path than a real subscriber would see, because the country check passed but the carrier check didn't. You won't notice in testing. You'll notice when a support ticket describes a payment flow you never saw.

reading the ASN instead of the flag

The script above checks org and mobile from an IP intelligence API. That catches the obvious case: a datacenter IP shows a hosting company in org and nothing in mobile, a carrier IP shows the carrier's registered ASN name and mobile: true. A few fields worth reading closely in the response:

org: the ASN's registered organization; you want a carrier name, not a hosting company
mobile: a boolean some providers report separately from org, worth checking even when org looks right
country: the field everyone checks first and the one that matters least here

If you need to go further and confirm which carrier specifically, not just mobile-or-not, checking a proxy's ASN before you trust it covers the WHOIS lookup in more detail than fits here.

don't stop at the storefront

A clean ASN doesn't guarantee the rest of the flow behaves correctly. Extend the same session to check what you actually care about:

# continues using `session` from above

store_resp = session.get(
    "https://play.google.com/store/apps",
    timeout=15,
    allow_redirects=True,
)
print("store url:", store_resp.url)

cdn_resp = session.get(os.environ["CDN_URL"], timeout=15)
geo_headers = ["cf-ipcountry", "x-amz-cf-pop", "x-geo", "x-country"]
for key, value in cdn_resp.headers.items():
    if key.lower() in geo_headers:
        print(f"{key}: {value}")

The storefront URL tells you which region the app store resolved you into. The CDN headers tell you which edge and geo-routing bucket actually served the response, which matters if your app pulls region-specific assets or feature flags from a CDN rather than from the store itself.

For flows that involve login, cart, or checkout, keep the same session and the same proxy connection for every step. A proxy that rotates IP on every new connection hands you a different IP mid-flow, breaks session cookies, and sometimes trips fraud checks that a real single-session user would never hit.

the DNS leak that undoes all of it

Worth checking explicitly: if you're using SOCKS5, make sure DNS resolution happens through the proxy, not locally. In requests, that's the difference between socks5h:// and socks5://: the h routes the hostname lookup through the tunnel. Without it, your traffic exits from the right IP but the DNS query that preceded it left from your real location. Some platforms cross-reference the two and flag the mismatch even when the HTTP request itself looks clean.

what actually bit us running this on real hardware

Real carrier IPs sit behind carrier-grade NAT, and carriers reassign addresses on their own schedule as part of normal CGNAT operation. That's standard, documented behavior, not a fault in any particular proxy. The practical effect: a sticky session that's supposed to hold one IP for the length of a test can still get reassigned mid-flow if the test runs long enough, because the reassignment happens at the carrier level, underneath the proxy layer entirely. We've had multi-hour automated test runs lose their IP partway through for exactly this reason. If you're running anything longer than a few minutes against a mobile carrier IP, build in a check that confirms the IP hasn't changed before you trust a multi-step result.

the tradeoff you're actually making

Datacenter proxies are faster. Sub-100ms round trips are normal. A real SIM going through an actual carrier network typically lands somewhere between 80 and 350ms depending on signal conditions at the moment you test. For geo-testing, that difference almost never matters, because you're checking correctness of a code path, not throughput. For a high-volume automated pipeline making thousands of requests an hour, it might, and that's worth weighing against how accurately the test needs to reflect what a real subscriber sees.

If your platform makes any decision (payment method, feature flag, content variant) based on whether a connection looks like a real mobile subscriber, testing that decision from a hosting-classified IP will tell you the storefront works and nothing about whether the decision itself is correct.