Complete guide to using HTTP, HTTPS, SOCKS5, and rotating proxies with Playwright in 2026. Includes per-context proxies, authentication, geo-targeting, and anti-detection tips with working Node.js and Python examples.
Playwright has quickly become the default choice for modern browser automation. It supports Chromium, Firefox, and WebKit out of the box, runs in Node.js, Python, .NET, and Java, and gives you a clean, modern API that's a pleasure to work with.
But the same things that make Playwright powerful for testing — real browsers, real fingerprints, real JavaScript execution — also make it a target for bot detection systems. Without proxies, you'll hit rate limits, captchas, and outright bans within minutes.
This guide shows you exactly how to configure HTTP, HTTPS, SOCKS5, authenticated, and rotating proxies with Playwright, with working code in both Node.js and Python.
Playwright is an open-source browser automation library maintained by Microsoft. Originally released as a successor to Puppeteer (built by some of the same engineers), it offers a few major advantages:
Multi-browser support — Chromium, Firefox, and WebKit (Safari engine) from a single API Multi-language — Node.js, Python, .NET, and Java all officially supported Auto-waiting — built-in waiting for elements, reducing flaky tests Browser contexts — isolated browser sessions inside one browser instance (huge for proxy rotation) Powerful network interception — modify, mock, and inspect requests easily
Common use cases:
End-to-end (E2E) testing Web scraping (especially JavaScript-heavy sites) Automated form submissions Screenshot and PDF generation Multi-account social media management Price monitoring and competitor research
The catch: every one of these activities looks suspicious to bot defenders without a proper proxy strategy.
Run Playwright on a fresh server and within a few requests you'll see:
HTTP 429 (Too Many Requests) responses Captchas appearing on every page Cloudflare challenge pages instead of content Outright IP bans that persist for hours or days
This happens because:
Your server IP is from a known datacenter range (AWS, GCP, Azure, DigitalOcean) — these are flagged by default on most major sites All requests come from one IP, making volume detection trivial Browser fingerprint + IP correlation — even with anti-detection patches, a single IP making many requests gets banned
Proxies fix this by:
Distributing traffic across many residential or mobile IPs Hiding your real infrastructure from the target site Enabling geo-targeting — appear to browse from any country: USA, UK, Germany, Spain, and more Bypassing per-IP rate limits by rotating addresses
Playwright accepts proxy configuration directly in browser.launch() or browser.newContext(). This is cleaner than Puppeteer's command-line argument approach.
> Tip: The proxy passed to browser.launch() applies to the entire browser. Every context and page inside it will use the same proxy.
Most premium proxies — including all plans on xProxy Market — require authentication. Playwright supports this natively via the username and password fields, no extra event handlers needed.
This is much cleaner than Puppeteer's page.authenticate() approach — Playwright handles the proxy auth dialog for you.
SOCKS5 proxies tunnel raw TCP connections rather than just HTTP, so they handle any protocol your browser uses. Playwright supports SOCKS5 with the socks5:// scheme.
> Note: Playwright's built-in proxy does not support authenticated SOCKS5 directly. If your SOCKS5 proxy requires a username and password, you have two options: > > Use an HTTP/HTTPS proxy instead (Playwright authenticates these natively) > Run a local proxy chain (e.g., proxychains) that handles SOCKS5 auth and exposes an unauthenticated local endpoint to Playwright
This is where Playwright truly shines compared to Puppeteer. You can assign a different proxy to each browser context — meaning a single browser instance can run multiple isolated sessions, each through its own proxy.
This is perfect for:
Multi-account management (one account per IP) A/B geo-testing (test US vs UK vs DE simultaneously) Parallel scraping without spawning many browsers
> Important: To use per-context proxies, you must launch the browser without a proxy. If you also pass a proxy to browser.launch(), the launch-level proxy takes precedence on Chromium.
For large-scale scraping, you want the proxy to rotate the exit IP automatically. There are two common patterns:
Your proxy provider gives you a single endpoint (e.g., rotating.xproxy.io:8080). Each new connection gets a fresh IP from the pool. Just point Playwright at it once and forget about it.
xProxy Market mobile and residential plans all include automatic IP rotation — you just keep using the same credentials and the upstream rotates the exit IP per request or on a schedule.
Maintain a list of proxies and create a fresh context for each request:
This pattern gives you full control — useful when different URLs need different geo-locations.
Mobile proxies (4G/LTE) are the gold standard for hard-to-scrape sites like Instagram, TikTok, and Cloudflare-protected pages. Real carrier IPs are virtually never banned because banning them would block real users.