Geo testing proxy guide: QA your app as users in other countries

A geo testing proxy lets your QA team see an app or website the way a user in another country sees it, without flying anyone to Tokyo or Seoul. You route the test browser or device through an IP address located in the target country, then check what changes: currency, language, legal banners, blocked content, and which CDN edge answers. This guide gives you a practical checklist, explains how to configure desktops and phones, and is honest about what an IP address can and cannot simulate.

What a country IP actually changes

Most location logic on the web starts with the visitor's IP address. A server or CDN looks the address up in a geolocation database and decides what to serve. When you test through a proxy in Japan, every request from your browser leaves from that Japanese IP, so the site makes the same decisions it would make for a real visitor there.

That covers a lot of behaviour:

• Default currency and price display on product pages and checkout.
• Default language and locale formatting (dates, decimal separators, address forms).
• Country-specific legal notices, cookie banners and age gates.
• Content licensing blocks, such as video or music not available in a region.
• Redirects to a regional domain or store.
• Payment method lists that differ by market.
• Which CDN point of presence serves your assets, and whether regional caching rules work.

It does not cover everything. Native mobile apps often decide region from the device locale, the app store account country, the SIM card or GPS. A proxy changes none of those. Treat the IP as one input among several and write test cases that state which input they exercise.

Choosing countries and proxy type for QA

Start from your market list, not from the proxy catalogue. If you ship to Japan and South Korea, those are the two locations you need, plus one "control" location such as your home market.

Cloudj sells dedicated proxies in Vietnam, the United States, Japan, South Korea, Singapore, Hong Kong and the United Kingdom. Each dedicated IPv4 proxy is a static ISP IP assigned to one customer only, which matters for QA: you get the same address every session, so a bug you saw yesterday is reproducible today. The Japan proxy guide and the South Korea proxy guide go deeper on those two markets, and the dedicated proxy guide explains the product in general.

A note on IP type: Cloudj's dedicated IPv4 addresses are ISP-registered static IPs, but they are not home broadband lines. If your product or a third-party widget behaves differently for home connections, a static residential ISP proxy is closer to a normal user. Cloudj offers that type only in the United States and Vietnam. For Japan and Korea, plan on dedicated static ISP proxies and note in your test plan that bot-detection behaviour may differ from real consumer traffic.

One IP per country is usually enough for functional QA. If several testers work in parallel and you want clean, separate sessions, order one proxy per tester per country. Orders run from 1 to 1,000 IPs, so a small QA setup is a normal order.

The geo testing proxy QA checklist

Run this list per country, per release, and save screenshots named by country code.

Pricing and checkout

1. Product page shows the expected currency symbol and formatting.
2. Tax or VAT wording matches the market.
3. Checkout offers the payment methods you expect in that country.
4. Shipping or availability messages are correct for the region.

Language and content

1. First visit lands on the expected language, or on a language picker.
2. Switching language manually is remembered and not overridden by the IP on the next page.
3. Locale formatting is correct for dates, numbers and phone fields.
4. Region-locked content shows the right message instead of a broken player or empty grid.

Legal and compliance

1. Cookie and consent banners appear where required and not where they are not.
2. Age gates and restricted categories behave per market rules.
3. Terms and privacy links point to the regional version.

Routing and performance

1. Response headers show the CDN edge you expect for that region (most CDNs expose a header naming the location).
2. Regional redirects do not loop.
3. Assets load from the regional cache rather than the origin.

A quick header check from a terminal is often faster than opening DevTools. The curl proxy test guide covers the command in detail; the short version looks like this:

curl -s -o /dev/null -D - -x http://USER:PASS@HOST:PORT https://www.example.com/ | grep -i -E "location|cache|server"

Replace the host, port, username and password with the values shown for your proxy in the console.

Setting up browsers and phones

Desktop browsers

The cleanest approach is a separate browser profile per country. Point each profile at its proxy, so a tester can keep "JP" and "KR" windows side by side without cross-contaminated cookies. The Chrome and Firefox proxy setup guide walks through both browsers. Clear cookies and local storage between test runs, or use a fresh profile, because many sites store the first detected region and ignore the IP afterwards.

Android and iPhone

Both platforms let you set a manual HTTP proxy on a Wi-Fi network. That works for the browser and for apps that respect the system proxy setting. The Android and iPhone proxy guide walks through the settings.

Be aware of two limits. First, some apps ignore the system proxy and connect directly, so their traffic will still leave from your office IP. Second, Cloudj proxies carry HTTP and SOCKS5 traffic, not UDP, so anything that relies on UDP (some streaming and real-time features) will not be tunnelled. If a test result looks like it ignored the proxy, check this before filing a bug.

To confirm the device is really using the proxy, open a "what is my IP" page in the phone browser and compare it with the proxy IP from the console.

Authentication for shared test labs

Proxies use a username and password by default. For a lab where many devices share one office connection, you can switch to an IP whitelist of up to 20 addresses instead. Whitelisting replaces password access, so devices behind your office IP connect without typing credentials. The trade-off is covered in whitelist vs password authentication.

Fitting geo tests into your release cycle

Geo bugs often return after unrelated changes, such as a new CDN rule. Two habits help:

• Keep a short "geo smoke test" of five to ten checks per country and run it before every release.
• Automate the header and redirect checks with the curl command above, or with a headless browser. The Playwright and Puppeteer proxy guide shows how to pass a proxy to automated tests.

If you also track how your pages rank by country, the same proxies are useful for that work; see local SEO rank tracking with proxies.

When a proxy is the wrong tool

A proxy is not a full device in another country. If you need to test store availability, SIM-based features, GPS-based logic or carrier billing, you need real devices or a device lab in that market. If you need to test server-side performance from inside the region, a short-lived cloud server in that location tells you more than a proxy does; Cloudj runs cloud servers in Tokyo and other cities, billed by the hour if you only need them for a test day.

FAQ

Can a geo testing proxy change the app store country?

No. The store country follows the account and payment details on the device. A proxy only changes the IP address that websites and APIs see.

Do I need a different proxy for each tester?

Not strictly, but separate proxies keep sessions and rate limits independent, which makes results easier to reproduce when several people test at once.

Which protocol should I pick for testing?

HTTP is the easiest to set on phones and browsers. SOCKS5 suits tools that support it natively. You can switch the protocol of an order in the console; see SOCKS5 vs HTTP proxy.

What if a country I need is out of stock?

Availability per country can change. The console shows what is in stock at the moment you order.

Start testing from Japan, Korea and beyond

Pick the markets your release targets, order one dedicated proxy per country in the Cloudj console, and run the checklist above before your next launch. Current prices per IP are on the proxy page, and proxies are usually ready a few minutes after you order.