Playwright is one of the most widely used browser automation frameworks. It handles JavaScript-rendered pages, supports Chromium, Firefox, and WebKit, and runs reliably in headless mode across CI environments. But at scale — or when targeting sites with anti-bot protection — a bare Playwright instance gets blocked quickly.
The fix is straightforward: route traffic through a proxy. This guide covers every practical configuration pattern for Playwright proxies, from the simplest single-IP setup through context-level rotation. Code examples are provided in both Python and Node.js.
How Playwright Proxy Configuration Works
Playwright supports proxy settings at two levels:
1. Browser-level: Set once at launch(). Every page and context in that browser instance uses the same proxy IP. This is the right choice when you want one IP for the entire session.
2. Context-level: Set in newContext(). Different contexts can use different proxies while sharing the same browser process. This is the pattern for running parallel scraping tasks with IP isolation.
Playwright's official docs confirm that both HTTP(S) and SOCKSv5 proxies are supported, with optional username and password fields for authenticated connections, and a bypass field to exclude specific hosts.
The proxy configuration object looks like this across all languages:
Method 3: Context-Level Proxy for Parallel IP Isolation
This is the pattern to use when running multiple concurrent tasks that each need their own IP. A single browser process hosts multiple contexts, each configured with a different proxy. This avoids the heavy performance overhead of launching multiple separate browser instances.
import asyncio
from playwright.async_api import async_playwright
PROXIES =[{"server":"http://gate.nstproxy.io:24125","username":"user1","password":"pass1"},{"server":"http://gate.nstproxy.io:24126","username":"user2","password":"pass2"},{"server":"http://gate.nstproxy.io:24127","username":"user3","password":"pass3"},]asyncdefscrape(browser, proxy, url):# Launch an isolated context with its own proxy settings context =await browser.new_context(proxy=proxy)try: page =await context.new_page()await page.goto(url)returnawait page.content()finally:await context.close()asyncdefmain():asyncwith async_playwright()as p: browser =await p.chromium.launch()try: tasks =[ scrape(browser, proxy,"https://httpbin.org/ip")for proxy in PROXIES
] results =await asyncio.gather(*tasks)for r in results:print(r)finally:await browser.close()asyncio.run(main())
Each context is fully isolated — separate cookies, storage, and IP. This is the standard approach for agency-scale crawling when you need concurrent sessions without cross-contamination.
Method 4: Rotating Proxies Across Requests (Session-based or TTL=0 Rotation)
Playwright does not rotate IPs automatically. To rotate IPs, you create a new context (which establishes a new connection) for each task. With Nstproxy, you can achieve automatic rotation per context by either generating a unique session ID or setting ttl=0 (using the r_0m parameter) in the username.
Here is how to implement rotation using dynamic session IDs in Python:
import uuid
from playwright.sync_api import sync_playwright
urls =["https://example.com/page/1","https://example.com/page/2","https://example.com/page/3",]with sync_playwright()as p: browser = p.chromium.launch()try:for url in urls:# Generate a random session ID to force Nstproxy to rotate the IP for this context session_id = uuid.uuid4().hex[:8] proxy ={"server":"http://gate.nstproxy.io:24125",# Append the unique session ID (-s_...) to the username"username":f"6EEA899B5A77B936-residential-country_ANY-r_10m-s_{session_id}","password":"YOUR_NSTPROXY_PASSWORD"} context = browser.new_context(proxy=proxy)try: page = context.new_page() page.goto(url)print(f"URL: {url} | Title: {page.title()}")finally: context.close()finally: browser.close()
Rotating with TTL = 0 (No Session Management)
If you do not want to manage session IDs in your code, you can set the TTL parameter to r_0m (which represents ttl=0). This signals Nstproxy to automatically assign a new residential IP for every new connection/context established by Playwright.
# Proxy configuration with TTL=0 (r_0m) for automatic rotation on every new contextproxy ={"server":"http://gate.nstproxy.io:24125","username":"6EEA899B5A77B936-residential-country_ANY-r_0m","password":"YOUR_NSTPROXY_PASSWORD"}
Which Proxy to Use for Each Playwright Task
Task
Recommended Proxy
Rotation
Notes
General web scraping
Residential
Per-context
Best success rate on anti-bot sites
Local SERP checks
Residential (city-targeted)
Per-request
Requires geo-targeting at city level
Account-based automation
Static ISP
Sticky session
Consistent IP per account
High-volume keyword harvesting
Datacenter
Per-request
Faster, lower cost for low-risk targets
Mobile-specific content
Mobile proxy
Per-request
Carrier IP for mobile rendering paths
CI/testing environments
Datacenter
Static
Speed and predictability matter more
Some reports notes that free proxies carry 70–90% failure rates and are suitable only for local testing, never production scraping. The distinction between browser-level and context-level configuration is also what separates basic single-IP setups from production-grade multi-IP parallelism.
Connecting Nstproxy Residential Proxies to Playwright
Nstproxy supports HTTP(S) and SOCKS5 protocols directly, and their residential proxy endpoint assigns a new IP on each new session by default — which maps cleanly onto Playwright's context-per-request rotation model.
The integration uses Nstproxy's standard gate endpoint with your account credentials:
For city-level targeting, append location parameters to the username following Nstproxy's format (e.g., username-country-US-city-NewYork). This gives Playwright sessions geo-targeted IPs without any additional infrastructure.
Nstproxy's residential network covers 195+ countries with city and ASN-level targeting, which matters for tasks like local SERP checking and geo-restricted content access directly inside Playwright.
For teams running rotating proxy workflows at scale, the same endpoint works without a static IP list — the rotation happens server-side on each new context.
The proxy server is unreachable. Check the host, port, and whether your network/firewall blocks that port. Test with curl -x http://proxy:port https://httpbin.org/ip before running Playwright.
407 Proxy Authentication Required
Credentials were not passed or are malformed. Confirm username and password are both set in the proxy config object. Do not embed credentials in the server URL string — pass them as separate fields.
Page timeout without a clear error
The proxy connected but the target site did not respond in time. Increase the navigation timeout:
page.goto("https://example.com", timeout=60000)
Also check whether the proxy's geo-location is blocked by the target — some sites block traffic from specific countries at the CDN level.
Proxy works in headless:false but fails headless
Some anti-bot systems detect headless Chromium independently of the proxy. Add standard browser launch args (--no-sandbox, --disable-blink-features=AutomationControlled) and verify your user-agent string is not a default headless string. Running headless: false temporarily helps confirm whether the proxy itself is the failure point.
Inconsistent results across contexts
If you are reusing the same proxy across contexts, the IP may be shared and already flagged. Use per-context proxy assignment with different credentials or a rotating endpoint.
3 Real-World Playwright + Proxy Use Cases
1. E-commerce Price Monitoring
A retail analytics team scrapes pricing data from 15 competitor sites daily. Each site uses a different anti-bot vendor. Running all requests from a datacenter IP block gets detected within the first crawl cycle.
With Nstproxy residential proxies and context-level rotation in Playwright, each page load appears as a different organic user. The team runs 500 concurrent contexts across asyncio, collecting 50,000 pages per hour with a block rate under 1%.
2. Local SEO SERP Verification
An SEO agency checks Google rankings for 300 client keywords across 20 US cities. Each check needs to appear to originate from the target city, or the result is geographically irrelevant.
Using Playwright with city-targeted Nstproxy residential IPs, each context is assigned a local IP matching the client's market. The same code runs for all 20 cities by changing the username location parameter — no separate infrastructure per city.
3. Ad Verification Across Markets
A marketing team verifies that ad campaigns display correctly in Germany, Japan, and Brazil. Without geo-targeted proxies, every check returns the same locally-served ad content from their office IP.
Playwright contexts with country-targeted residential proxies return the actual ad creative each market sees, catching localization errors before campaigns go live.
Comparison: Playwright Proxy Approaches
Approach
Use Case
Rotation Control
Complexity
Browser-level static proxy
Single-session scraping, testing
None — one IP per run
Low
Context-level static proxy
Parallel isolated sessions
Manual — one IP per context
Medium
Context-level with proxy pool
Custom rotation logic
Full — pick any IP per task
Medium
Rotating residential endpoint
Large-scale scraping
Automatic server-side
Low (simplest at scale)
For most production use cases, a rotating residential endpoint is the easiest to maintain: one endpoint, credentials that include optional geo-targeting, and automatic IP assignment per context.
Conclusion
Playwright proxy configuration is not complex — the API is clean, and both browser-level and context-level patterns are well-documented. The harder part is choosing the right proxy type, managing rotation correctly, and debugging failures that come from anti-bot systems rather than proxy configuration itself.
For serious scraping or automation at scale, residential proxies with automatic rotation and city-level targeting cover most production scenarios. Nstproxy integrates directly with Playwright's proxy config in a few lines, supports both HTTP(S) and SOCKS5, and handles geo-targeting through credential parameters without additional infrastructure.
Q: Can I set a different proxy for each page in Playwright?
Playwright sets proxies at the browser or context level — not at the individual page level. To use a different proxy per page, create a new context for each page.
Q: Does Playwright support SOCKS5 proxies?
Yes. Use socks5:// as the protocol prefix in the server field: "server": "socks5://gate.nstproxy.io:24125". SOCKS5 behavior can vary by browser engine, so test with a minimal script before scaling.
Q: Can I configure multiple proxies in one Playwright context?
No. A single browser context uses one proxy configuration. If you need multiple proxies at the same time, use multiple contexts or multiple browser processes.
Q: How do I verify my proxy is working inside Playwright?
Navigate to https://httpbin.org/ip or https://api.ipify.org?format=json and read the response. The IP returned should match the proxy's location, not your real IP.
Q: Will Playwright proxies work in headless mode?
Yes, proxy support is identical in headless and headed modes. If you see failures only in headless, the issue is typically anti-bot detection (not the proxy) — try adding --disable-blink-features=AutomationControlled to launch args.
Q: How many proxies do I need for large-scale scraping?
A general baseline is one rotating IP per 10–20 concurrent requests. For 500 concurrent Playwright contexts, a pool of 50–100 residential IPs with automatic rotation keeps any single IP well below detection thresholds. With a rotating endpoint (server-side rotation), this is handled automatically.
Proxifier lets desktop apps route traffic through proxy servers, even when those apps do not support proxy settings directly. This guide explains how Proxifier works, how to add Nstproxy, how to create proxification rules, and how to fix common connection problems. It is written for legitimate use cases such as app routing, access troubleshooting, testing, research, and controlled proxy workflows.
Lena Zhou
Jul. 1st 2026
110M+ real IPs with 99.9% access success
Blazing-fast average response ~0.5s for high-concurrency tasks
From only $0.1/GB
Get immediate access to premium residential, datacenter, IPv6 and ISP proxy pools.
