Proxies for QA & Cross-Browser/Geo Testing

What actually needs geo-testing

Localized pricing and currency. A checkout flow that correctly converts currency in a staging environment can still show the wrong number once real geo-IP-based pricing logic kicks in for an actual regional visitor.

Compliance banners and legal text. Consent banners, cookie disclosures, and region-specific terms are often served conditionally based on the visitor's detected location — a test running from the company's home country may never see the version required for GDPR, LGPD, or other regional frameworks.

Content and feature availability. Streaming catalogs, product availability, and feature flags frequently differ by region. Confirming that the right version renders for the right market requires actually appearing to be in that market.

CDN and latency behavior. Performance testing from a single region misses how a page actually loads for users served by a different CDN edge or a slower regional connection.

Wiring proxies into existing test frameworks

This isn't a separate testing process — it plugs into the same browser automation most QA teams already run.

Playwright:

python

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={
            "server": "http://ip.simplynode.io:9003",
            "username": "login",
            "password": "country-de-city-berlin"
        }
    )
    page = browser.new_page()
    page.goto("https://example.com/pricing")
    # assert localized price, currency, and consent banner render correctly

Selenium:

python

from selenium import webdriver
from selenium.webdriver.common.proxy import Proxy, ProxyType

proxy = Proxy()
proxy.proxy_type = ProxyType.MANUAL
proxy.http_proxy = "login:country-jp@ip.simplynode.io:9003"
proxy.ssl_proxy = "login:country-jp@ip.simplynode.io:9003"

options = webdriver.ChromeOptions()
options.add_argument(f'--proxy-server=http://login:country-jp@ip.simplynode.io:9003')
driver = webdriver.Chrome(options=options)
driver.get("https://example.com")

For a test flow that spans multiple pages — a full checkout, a multi-step signup — hold a sticky session for the length of that run so the site sees one consistent visitor throughout:

python

import hashlib

test_run_id = "checkout-flow-de-2026-08-20"
session_id = hashlib.md5(test_run_id.encode()).hexdigest()[:8]
password = f"country-de-session-{session_id}-ttl-1800"
# use this password string across every step of the same test run

Building a real geo-test matrix

The practical version of this isn't testing one country once — it's running the same test suite across every market that matters, on a schedule, the same way a cross-browser matrix runs the same suite across Chrome, Firefox, and Safari. A compliance check that passes for Germany doesn't confirm anything about how the same page behaves for a visitor in Brazil or Japan, where different rules and different localized content apply. Treating geography as another axis of the test matrix — alongside browser and device — catches regressions that a browser-only matrix has no way to see.

Common mistakes

Testing compliance from the company's home country. The banner or disclosure a regional regulation requires often only renders for visitors detected in that region — testing from anywhere else can pass a check that would fail for a real user.

Running geo-tests as a manual, pre-launch-only step. A price display bug or missing content issue introduced by a routine deploy won't get caught until the next scheduled manual check, potentially weeks later. Wiring geo-tests into the same CI pipeline as the rest of the suite catches it immediately.

Losing session consistency mid-flow. A rotating IP mid-checkout can make a single test run look like several different visitors abandoning and restarting the same flow — hold a sticky session for the length of any multi-step test.

Assuming one city represents a whole country. Some geo-restrictions and pricing logic vary by state, province, or city, not just by country — city-level targeting catches regional differences a single country check would miss.

FAQ

How do I test geo-restricted content without traveling or using a VPN for each check? Integrate country-targeted residential proxies directly into your existing browser automation framework (Playwright, Selenium, Cypress) so each test run appears to come from the target market automatically.

Do I need a different proxy for every country I test? You need the ability to target each country you're testing, typically through one proxy connection string with the country specified as a parameter — not a separate proxy account per market.

Should geo-testing be part of automated CI, or a manual pre-launch check? Automated and continuous. A manual pre-launch check only catches issues that existed at that specific moment; wiring geo-tests into CI catches regressions introduced by any later deploy.

What's the difference between testing with a proxy versus a VPN for QA? A VPN typically routes an entire machine's traffic through one location at a time, which is awkward to script and parallelize. A proxy integrates directly into test automation code, letting different test runs target different countries simultaneously without reconfiguring anything manually.