Playwright Proxy Configuration for Parallel Contexts

#playwright #testing #webscraping #automation

Playwright makes parallel browser automation easy, which is exactly where proxy setups tend to go wrong. One browser context per worker sounds clean until every context leaves from the same address and the target blocks all of them at once. The fix is to give each context its own exit, or route them all through a rotating pool. Here is how to configure proxies in Playwright the right way, especially when you run many contexts in parallel.

Proxy at the browser level

The simplest setup passes the proxy when you launch the browser. Every context and page inside then uses it.

const { chromium } = require("playwright");

const browser = await chromium.launch({
  proxy: { server: "http://proxy.host:8080", username: "user", password: "pass" },
});
const page = await browser.newPage();
await page.goto("https://example.com");

This is fine for a single stream of work. The moment you want parallelism with isolation, you move the proxy down to the context level.

Proxy per context

Playwright lets you set a proxy per context, which is what you want when each context represents a separate identity that must not share an address with the others.

const browser = await chromium.launch();

async function worker(exitTag) {
  const context = await browser.newContext({
    proxy: { server: "http://proxy.host:8080", username: "user-" + exitTag, password: "pass" },
  });
  const page = await context.newPage();
  await page.goto("https://example.com");
  await context.close();
}

await Promise.all([worker("a"), worker("b"), worker("c")]);

Each context is isolated: its own cookies, its own storage, and its own exit address. That isolation is what keeps five parallel sessions from looking like one machine hammering the target.

Rotating versus sticky per context

Two patterns cover most needs, and a good pool supports both.

Rotating for independent work. When contexts scrape independent pages, point them all at one rotating endpoint and let the pool hand each request a fresh exit. Volume spreads automatically.
Sticky per identity. When a context must stay logged in or hold a cart, it needs one stable address for its whole life. You pin that context to a fixed exit so the site sees a consistent visitor.
Do not over-parallelize. Playwright will happily launch dozens of contexts. Pace them, or rotation will not save you from a self-inflicted burst.

The rule of thumb: rotate when requests are independent, stay sticky when steps depend on each other, and never let one address carry all your parallel contexts.

What the pool needs for parallel contexts

Running many contexts at once is demanding on the address pool, so its properties decide whether the setup holds.

WinGate fits this directly. It provides private proxies with SOCKS5 and user and password auth, so each context has clean credentials to present, and the addresses are private rather than shared. The rotating pool draws from a worldmix and cycles exits automatically for independent work, while you can hold a stable exit when a context must stay sticky. Traffic is unlimited, which matters when many contexts each load full pages, and it supports up to 5000 threads, enough concurrency for heavy parallel runs. It speaks HTTP, HTTPS, and SOCKS5, so the config above works unchanged.

An honest note: per-context proxies stop the address from linking your parallel sessions, they do not hide that you are automating browsers. Pacing, fingerprint isolation, and respecting the site's terms still matter. There is a free 2 hour test, so run a handful of parallel contexts against your own targets and watch how many stay clean before you scale the worker count up.