Playwright Proxy Servers

Chromium has a quirk the docs bury: per-context proxies only take effect if the browser itself was launched with a proxy option. The convention is a placeholder — chromium.launch(proxy={"server": "per-context"}) — after which every new_context(proxy=...) works as expected. Skip the placeholder and context-level proxies are silently ignored, which is easy to misread as a dead proxy list. Firefox and WebKit don't need this, so cross-browser code has to branch on the engine. The addresses themselves can come straight from your exported package list — one per context.

Not with credentials — the message is literal. Chromium's network stack has no mechanism for SOCKS5 username/password, so Playwright refuses the combination up front instead of failing silently (Firefox does support authenticated SOCKS5, if switching engines is an option). The clean fix on any engine is removing the credentials: whitelist your machine's IP in the Dashboard and pass proxy={"server": "socks5://IP:port"} with no username at all. Since every address in our packages answers on HTTP, HTTPS, SOCKS4, and SOCKS5, you can also just switch the scheme to HTTP without changing the list.

A known trap: characters like =, @, or # in credentials break URL parsing, and depending on where the values end up, auth fails silently or the connection falls back unproxied. The immediate fix is to keep credentials out of the server string — Playwright's proxy option has dedicated username and password fields precisely for this. The structural fix is not having a password in the config at all: with IP whitelisting the launch options contain nothing secret, which also means your repo, CI logs, and error traces stop leaking proxy credentials.

Yes — proxy={"server": "IP:port"} is engine-agnostic, and with a whitelisted IP all three browsers connect without extra configuration. The differences appear only at the edges: Chromium needs the launch-level placeholder for per-context proxies and rejects SOCKS5 credentials, Firefox handles authenticated SOCKS5 natively, and WebKit takes the plain server option without per-context branching. If you run the full engine matrix in CI, whitelisting is the one setup that behaves identically across all of it — worth knowing before you standardize on credential objects.