Proxies for Localization Testing: Verify the Page, Not Just the IP

A localization test is not a request sent through a country exit. It is a check that your owned site shows the intended language, currency, catalogue, delivery rule or campaign for a defined customer context. IP is one signal inside that context. IP is not an entire locale. Cookies, account state, request headers, browser locale, time zone, selected store and target logic can change the page after the request leaves the proxy.

Use a proxy when your site needs a permitted network route to exercise regional behavior. Keep the route, browser state and expected output separate so a failed currency or catalogue check has an owner.

Define the locale scenario as a test contract

Write the customer context before opening a browser. Include the product or catalogue slice, the expected final URL and the field that proves the page is the right regional variant.

A country exit may help create the scenario. It does not prove that the server selected the country’s currency or catalogue. If the site uses an account or delivery address, use a test account and an authorized address that you control. Never use a real customer’s state for QA.

Control the browser context and headers

Playwright’s BrowserContext lets a test define context-level state such as locale, time zone, extra HTTP headers and cookies. Its network documentation covers proxy configuration and request or response observation. Keep one context per scenario and close it after the run so cookies and storage do not leak into the next locale.

A minimal context shape is a test fixture, not a guarantee that the site will honor every setting. Keep the proxy endpoint separate from its credentials so the values match Playwright's proxy options rather than a Requests-style URL assumption:

const proxy = {
  server: process.env.PROXY_URL,
  username: process.env.PROXY_USERNAME,
  password: process.env.PROXY_PASSWORD,
};

const context = await browser.newContext({
  proxy,
  locale: 'fr-FR',
  timezoneId: 'Europe/Paris',
  extraHTTPHeaders: {
    'Accept-Language': 'fr-FR,fr;q=0.9',
  },
});

context.setDefaultTimeout(15_000);

try {
  await context.addCookies([
    { name: 'market', value: 'FR', domain: 'owned.example', path: '/' },
  ]);

  const page = await context.newPage();
  await page.goto('https://owned.example/catalog/item-123', {
    timeout: 15_000,
    waitUntil: 'domcontentloaded',
  });

  const result = {
    finalUrl: page.url(),
    language: await page.locator('[data-locale]').getAttribute('data-locale'),
    currency: await page.locator('[data-currency]').getAttribute('data-currency'),
    catalogueId: await page.locator('[data-catalogue-id]').getAttribute('data-catalogue-id'),
  };
  console.log(result);
} catch (error) {
  console.error({ error: 'localization_check_failed', type: error.constructor.name });
} finally {
  await context.close();
}

The data-* selectors in this fixture must be replaced with markers owned by the site under test. Log the field values or pass them to an assertion helper; do not log page bodies, credentials or account tokens.

Keep credentials and real account tokens outside the fixture. Use an isolated test account and document whether the cookie was set by the site, by the test, or by an approved consent step.

The Accept-Language header expresses a client’s language and locale preference. It is a negotiation input, not proof that the server used that language. The site may choose another language from account or URL state. Intl.NumberFormat formats numbers for a locale; it does not establish that your catalogue or price source is correct.

Test one cause at a time

Start with a direct baseline on the owned site. Then repeat the same URL with the regional route and the same browser version. Hold the following constant unless the scenario explicitly tests it:

• URL, SKU or catalogue slice
• Account, consent and cookie state
• Browser locale and time zone
• Accept-Language and other application headers
• Delivery or store selection
• Proxy session and page sequence
• Parser and expected-field validator

When the result changes, preserve the first failing field. An exit lookup can pass while the page stays in USD. A French header can pass while the catalogue remains global. A cookie can select a market while the proxy exit remains outside it. Diagnose these as separate controls before changing providers.

Record the page result, not only the route

Use a redacted observation record. Do not export page bodies, customer data or credentials to a shared log.

scenario,requested_country,browser_locale,accept_language,cookie_market,observed_exit,final_url,language_ok,currency_ok,catalogue_ok,status,reason
fr-price,FR,fr-FR,fr-FR,FR,COUNTRY_OR_UNKNOWN,https://owned.example/catalog/item-123,true,true,true,accepted,
id-catalog,ID,id-ID,id-ID,ID,COUNTRY_OR_UNKNOWN,https://owned.example/catalog/item-123,true,false,true,rejected,currency_mismatch

This is a fixture example, not a real site result or ProxyLane experiment. COUNTRY_OR_UNKNOWN is intentional: the exit lookup belongs in the run log, and an IP database may not provide city-level certainty. Keep the lookup source and date when the city or ASN matters.

For each rejected observation, record whether the first failure was route geography, language negotiation, cookie or account state, catalogue selection, currency formatting, redirect, consent, authentication or target logic. Re-run the same scenario after one controlled change. Changing the proxy, cookie and header together only tells you that something changed.

Decide whether the proxy helped

A localization test passes when the owned page satisfies the scenario’s fields. That might be a visible language marker, an ISO currency code, an expected amount, a catalogue identifier, a selected store or a delivery method. A route passes its part of the test when the observed exit matches the requested route within the declared tolerance. Keep those assertions separate.

The proxy geotargeting guide covers exit and target checks. The cost per successful request guide explains why a localized page that fails the record validator is not an accepted result. Do not use a localization pass to claim that every user in a city, country or language group will see the same page.

ProxyLane’s public residential offer lists country, city and ISP targeting, HTTP and SOCKS5, rotating or sticky sessions and non-expiring traffic. Confirm the requested geography, session behavior, billing unit and target terms for your owned-site test. Request access with the scenario matrix and fields you need to verify.