The team tests the application for an entire sprint, releases the build — and a week later, complaints flood support: "the price is different in my city," "the push notification didn't arrive," "I can't pay with my card." The reason is almost always the same: all tests were conducted from a single corporate IP, while real users access the app from different regions, networks, and operators. In this article, we will discuss 7 specific QA scenarios that are physically impossible to test without changing the IP address and show how to set up a testing infrastructure with proxies.
Why Office IP is a QA Blind Spot
Most mobile applications today make decisions based on the IP address: they determine the user's country, interface language, currency, available payment methods, feature set, and even subscription price. When the entire QA department tests from a single office with one static IP from a data center or corporate network, the application always receives the same response from the backend — as if all testers are in one point in the world.
As a result, bugs that depend on geolocation, time zone, mobile operator, or connection type simply do not reproduce in the test environment. They only surface in production — when a user from Kazakhstan sees prices in rubles, a German user does not receive a push notification due to GCM blocking in their network, and an Indonesian client cannot pay with a card because the payment provider for their region is not connected. Fixing such a bug after release is exponentially more expensive than catching it during QA.
The solution is to emulate the real geographical and network diversity of users before release. For this, QA engineers increasingly use proxy servers: they allow you to "move" the testing device or emulator to any country, city, or even mobile operator without the need to physically go there or buy dozens of SIM cards.
Scenario 1: Geocontent and Regional Pricing
Most subscription-based applications (streaming, fitness, education) show different prices in different countries — this is called geopricing. If QA checks the subscription process only from a local IP, it is impossible to ensure that the price for a user from Turkey, Brazil, or India is displayed correctly, in the right currency, and with the correct rounding.
The same problem exists with content catalogs: a library of movies, products, or promotions is often regional. You need to physically "appear" in the desired country to see the same screen that a real user sees. For such checks, it is convenient to use residential proxies — they provide IPs of real home users from a specific country, and the application's backend perceives the request as regular organic traffic, not as a request from a data center.
Practical check: run the subscription process scenario in 8-10 key markets (USA, Germany, Brazil, India, Turkey, Japan, Nigeria, UAE), take screenshots of prices and currencies, and compare them with the product price list. This covers a large part of complaints like "why do I have a different price."
Scenario 2: Geoblocks and Access Restrictions
Fintech applications, streaming services, and some games block access from certain countries for legal or licensing reasons. QA must ensure not only that the application works where it should but also that it correctly (and not with a crash) denies access where it should not.
A typical bug: instead of a neat "service unavailable in your region" screen, the user sees a white screen or an endless loader — because developers only tested the happy path from an allowed country. Checking geoblocks requires sequential connections from several prohibited jurisdictions, which is unrealistic with live SIM cards and business trips, but takes 10-15 minutes per country through proxies.
For this scenario, proxies with precise geolocation at the city level are suitable, not just the country — it is important to check not "Germany in general," but specific states if the license is regionally restricted within the country.
Scenario 3: A/B Testing and Phased Rollouts by Country
Feature flags and gradual rollouts are almost always configured with geolocation in mind: a new feature is first enabled in Canada, a week later in Australia, and then everywhere. If the QA team is physically located in one country, it cannot see the new version before other regions until the flag reaches it.
To test a feature before the global release, you need to spoof the geolocation to the first wave rollout country. This is one of the most common tasks that proxies solve in conjunction with anti-detect browsers or device emulators — we change the IP to the desired country, restart the application session, see the feature before other users, and manage to find bugs before the flag rolls out to 100% of the audience.
An important nuance: for A/B tests, a stable "registration" of the IP is needed throughout the testing cycle — the session should not jump between countries between requests, otherwise the backend will confuse the experiment conditions and show either the control group or the test group.
Scenario 4: Localization and Push Notifications
The text of a push notification, the time it is sent, and even the fact of delivery often depend on the device's geolocation. In some countries, push providers (Firebase, APNs, local SMS gateways) operate with delays or through alternative routes — and what is perfectly delivered in a test environment from an office in Moscow may not reach a user in Indonesia due to the blocking of specific push servers by the local telecom provider.
Also, interface localization is often triggered by IP, not just by the system language: a user with an English phone language but an IP from France may see a mixed interface — headers in French, buttons in English. Such bugs are 100% invisible if the entire QA tests from one geozone.
Recommended process: take 5-7 locales from the product's priority markets, connect through proxies with the corresponding IP, change the system language on the device/emulator, and document what text and date/number formats the application displays. Mismatches between the IP country and the system language are a separate mandatory case, which is often overlooked.
Scenario 5: Payment Methods and Fraud Systems
The set of available payment methods in a mobile application almost always depends on the country: in one region, card payments and Apple Pay are available, in another — only local wallets (Mercado Pago, Boleto, UPI, QIWI), and in a third — payment through the mobile operator. If QA cannot connect from the required country, half of the payment scenarios remain untested until production, where the cost of error is lost revenue and support complaints.
A separate pain point is the anti-fraud systems of payment providers. They assess the risk of a transaction, including based on the IP: a request from a data center IP will almost certainly receive a denial or additional 3D-Secure verification, even if the card is completely valid. This distorts test results: QA sees a payment denial and reports a bug to developers, although the problem is not in the code but in the fact that the test IP looks suspicious for anti-fraud scoring.
For payment scenarios, it is better to use residential proxies or mobile proxies — they appear as regular traffic from a real user and do not trigger unnecessary activations of anti-fraud systems, providing a more accurate picture of payment flow behavior.
Scenario 6: Behavior in Mobile Operator Networks
An application that works perfectly on office Wi-Fi at 200 Mbps may behave completely differently on a mobile 3G/4G network with an unstable connection, the operator's NAT proxy, and high latency. Request timeouts, retries, degradation of video/audio quality, offline mode operation — all of this must be critically tested in conditions close to mobile internet, not in a stable office network.
An additional complexity: some telecom operators apply their own proxies and CGNAT, causing the server to see not the real user's IP but a shared IP of the operator, through which thousands of subscribers pass simultaneously. This affects rate limiting and geolocation by IP — the application may "think" that the user is in a different city than they actually are.
To reproduce such behavior, mobile proxies are needed that connect to the internet through real SIM cards of the required country's operators — this provides an accurate picture of NAT, latencies, and speeds that cannot be obtained with a regular data center IP.
Scenario 7: Rate Limiting and Bot Protection
Many backend APIs of mobile applications limit the number of requests from a single IP (rate limiting) and use bot protection similar to CAPTCHA or behavioral analysis. If the QA team runs automated tests from a single corporate IP, after a while, the server starts responding with 429 errors or blocking requests altogether — and tests fail not due to a bug in the application, but because the backend perceives the test traffic as an attack.
This is especially relevant for load and regression testing, where hundreds of similar requests (registration, login, adding to cart) need to be executed in a short time. Distributing requests among different IPs through a proxy pool allows for a fair load on the API without distorting results due to anti-fraud protection triggers.
For such mass automated testing, it is often more beneficial to use data center proxies — they are faster and cheaper for large volumes of requests, and geolocation in this scenario is not as critical as speed and connection stability.
Tools and Proxy Setup for QA
For manual QA on emulators (Android Studio Emulator, Xcode Simulator), proxies are configured through the emulator's network settings: you specify the IP and port of the proxy server, username, and password if authentication is used. For real devices, similar settings are available in the Wi-Fi connection under "Advanced Settings → Proxy → Manual."
To intercept and analyze traffic between the application and the backend, QA engineers use Charles Proxy or Proxyman — both tools allow you to route application traffic through an external proxy and simultaneously see all HTTP/HTTPS requests, geolocation headers, and server responses. This is convenient for diagnostics: it is immediately clear what IP and which country the backend "sees" at the moment of the request.
For automated testing through Appium or Espresso, the proxy is specified in the desired capabilities of the session or through the device's system settings before launching the test suite. Cloud platforms for mobile application testing (BrowserStack, Sauce Labs) also support connecting custom proxies, allowing the same automated test scenario to be run from different countries without physical devices in each location.
If the team has a web version of the application or needs to test multiple accounts with different geolocations simultaneously, it is convenient to use anti-detect browsers (Dolphin Anty, AdsPower, Multilogin) — each profile is tied to a separate proxy, and the QA engineer can keep 5-10 sessions open from different countries at the same time without confusion in cookies and cache.
Which Proxy Type to Choose for Each Scenario
| QA Scenario | Recommended Proxy Type | Why |
|---|---|---|
| Geopricing and Content | Residential | Appear as regular user traffic, do not trigger anti-bot protection |
| Geoblocks | Residential | Precise geolocation down to city/region |
| A/B Testing and Rollouts | Residential / Data Center | Stable session throughout the test cycle |
| Push Notifications and Localization | Mobile | Reproduce real delivery conditions through operators |
| Payments and Anti-fraud | Residential / Mobile | Low risk of false positives in anti-fraud systems |
| Mobile Operator Networks | Mobile | Real SIM cards from operators, accurate emulation of NAT and latencies |
| Rate Limiting / Load Tests | Data Center | High speed and low cost for large volumes of requests |
Pre-release Checklist
Before releasing the build to production, go through a short checklist related to geolocation and network — this covers most of the bugs described above:
- Prices and subscription currency checked in at least 5 key product markets
- Correct display of the geoblocking screen in prohibited countries checked
- Feature flag tested in the first wave rollout country before global release
- Push notifications checked with IP and system language from different country combinations
- Available payment methods checked for each key region separately
- Payment flow tested without false positives in anti-fraud systems
- Application tested under mobile network conditions (3G/4G), not just Wi-Fi
- Automated tests do not fail due to rate limiting when running in parallel from a single IP
Conclusion
A mobile application operates in dozens of countries, networks, and payment ecosystems simultaneously, while the QA team is physically located in one office with one IP. This gap between the real audience and testing conditions creates most of the "unexplainable" bugs that reach production. The seven scenarios above — geoprices, geoblocks, A/B rollouts, push notifications and localization, payments, mobile operator networks, and rate limiting — cover the majority of such risks.
If your team tests an application that works with regional content, pricing, or payments, it makes sense to integrate residential proxies into the testing stack to simulate real users, and for scenarios involving mobile connectivity and push delivery — mobile proxies tied to specific operators. This allows critical bugs to be found during the QA phase, not after user complaints in the stores.