The fastest way to debug Playwright proxy authentication is to separate three boundaries: the browser context that owns the proxy setting, the credential string that reaches the proxy server, and the target-site limit that may look like a proxy failure. If those three checks are mixed together, teams often rotate IPs, change providers, or rewrite browser code before confirming where the failure actually starts.<\/p>\n
Use this workflow when a Playwright, Selenium, or Chromium automation job loads forever, returns Playwright accepts proxy settings at browser launch or browser-context creation, depending on language and setup. The first check is therefore simple: verify the code path that creates the actual page is using the same proxy object you think it is using. A common failure pattern is testing the proxy in one launch path, then creating a new context or helper wrapper that does not inherit the same settings.<\/p>\n Start with a single page, one proxy endpoint, and a neutral IP-check URL. Do not begin with the final target site. If the IP-check page does not show the proxy exit IP, the page is outside the intended proxy boundary. Re-check where the proxy is passed, whether the framework wrapper overrides it, and whether the runner creates a new browser context after your setup code.<\/p>\n The Playwright proxy option reference<\/a> is useful here because it shows the expected shape of When a browser automation run fails on the first navigation, credentials should be tested outside the browser with the same host, port, username, and password. Use a command-line request to an IP-check endpoint and keep the target site out of the test. If this fails, the browser is not the first suspect.<\/p>\n A minimal credential test should answer four questions:<\/p>\n For example, if your browser code stores credentials in an environment variable, print only the presence and length of each variable in logs, not the value. Then test from the same host or container that runs Playwright. A proxy that works on your laptop but fails in CI may be blocked by missing allowlisting, NAT egress changes, or a runner that strips environment variables.<\/p>\n After the proxy passes a neutral IP-check page, move to a plain HTTPS site before testing the final target. This step prevents a target-site block from being mislabeled as proxy authentication failure. A target may return a CAPTCHA, 403, 429, or endless challenge loop even when the proxy authenticated correctly.<\/p>\n Read the browser symptom carefully:<\/p>\n This separation keeps the troubleshooting order honest. If the neutral IP-check works and the target fails, rotating credentials is usually a distraction. The next checks should be pacing, session stickiness, target reputation, and whether the target expects a more stable browser identity.<\/p>\n Browser automation usually keeps state: cookies, local storage, TLS connections, and sometimes long-lived pages. That means the proxy session policy matters. A rotating proxy that changes exit IP mid-login can break an account workflow even though each individual request authenticates. A static proxy can keep identity stable but may concentrate too much traffic on one IP if the job is too parallel.<\/p>\n For login, checkout, ad verification, or account QA tasks, keep one browser context tied to one proxy session for the length of the workflow. For stateless scraping, rotation can be more aggressive, but it still needs pacing and retry rules. If you need a rotating residential setup, choose a rotating residential pool with session controls<\/a> and test both sticky and rotating behavior before scaling the browser workers.<\/p>\n A useful small-scale test is to open three pages in one context and record the exit IP from each page. Then open three separate contexts and repeat the check. If the IP changes inside a workflow that expects a stable login identity, change the session rule before changing application logic.<\/p>\n Authentication can succeed while the job still fails because the browser opens too many tabs, contexts, or connections through the same proxy endpoint. This often appears as random timeouts, partial page loads, or a hanging navigation that disappears when the worker count is reduced.<\/p>\n Reduce concurrency to one browser, one context, and one page. If the job stabilizes, increase load in small steps and record the first failure point. Also check whether your code reuses a browser context across unrelated accounts. Shared contexts can carry cookies and storage across identities, while too many contexts on one proxy can trigger rate limits or provider-side connection caps.<\/p>\n Use this rule of thumb:<\/p>\n Good logs make proxy automation cheaper to operate. Record the proxy label, scheme, country or pool, context ID, worker ID, target hostname, first navigation error, HTTP status when available, and whether the neutral IP-check succeeded. Do not log proxy passwords or full account identifiers.<\/p>\n Before a run is considered healthy, confirm these conditions:<\/p>\nnet::ERR_TUNNEL_CONNECTION_FAILED<\/code>, shows a proxy auth prompt, or works locally but fails in a runner. The goal is not to prove that every failed page is a proxy problem. The goal is to locate whether authentication, context scope, connection limits, or the target site is the first broken boundary.<\/p>\nConfirm the proxy is attached at the browser boundary you think it is<\/h2>\n
server<\/code>, username<\/code>, and password<\/code>. Selenium has a different driver-options model, so use the Selenium browser options documentation<\/a> when the same test is being ported across frameworks. Treat these docs as boundary checks, not copy-paste fixes: your job is to confirm which layer owns the proxy.<\/p>\nTest credentials outside the browser before changing browser code<\/h2>\n
\n
http:\/\/host:port<\/code> rather than a mismatched SOCKS or HTTPS form?<\/li>\nIsolate proxy authentication from target-site blocking<\/h2>\n
\n
ERR_TUNNEL_CONNECTION_FAILED<\/code> before any target response points to CONNECT, scheme, port, DNS, or upstream proxy availability.<\/li>\nMatch session behavior to the browser job<\/h2>\n
Check concurrency before assuming the proxy is bad<\/h2>\n
\n
Keep logs that distinguish proxy, browser, and target failures<\/h2>\n
\n