iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If page.goto('https://www.google.com') hangs in Playwright when you use an authenticated proxy, check the Chrome network log before changing proxy settings. A proxy vendor’s report describes a specific failure pattern: Google sends an HTTP/2 ACCEPT_CH frame, Chromium aborts the first navigation, and the expected retry does not appear in the automated run. That explanation is plausible for the reported setup, but it is not confirmed as a general Chromium bug.
What may be happening
A RoamProxy report published October 5, 2026, describes Playwright 1.63 with bundled Chromium 153 in headless mode and a username-and-password authenticated proxy. In that setup, the author observed an HTTP/2 session to www.google.com, an ACCEPT_CH frame from Google, and then -3 (ERR_ABORTED) on the first main-frame request. The automated run timed out without a second navigation request. In a manually launched Chrome run, the author says a retry followed and the page loaded. Read the report.
The report’s proposed explanation is that the frame requests client hints during connection setup. If the navigation has already started without those hints, Chromium may cancel it and restart with the requested hints. The author suspects the restart fails to proceed with Playwright’s proxy-credential handling, but says they did not trace the mechanism into Chromium source. Treat this as one vendor’s diagnosis of one reproduction, not an established explanation for all authenticated proxies or Chromium versions.
The report also says curl --http2 and a Node HTTP/2 client worked through the same tunnel, as did manually launched headed Chrome. Those observations suggest the tunnel itself was not generally unavailable in that reproduction; they do not prove that other proxy configurations or browser paths will behave the same way.
#1 Best Overall
How to confirm whether this is your failure
Record the exact setup
Before comparing runs, note the Playwright version, browser type and version, headless mode, proxy protocol, destination, and navigation timeout. Playwright normally uses its bundled Chromium, and its documentation distinguishes the headless shell from other Chromium modes; recording these details makes a reproduction meaningful. Playwright browser documentation.
Inspect the navigation sequence
- Capture a Chrome network log using Chrome’s official network troubleshooting guidance.
- Find the main-frame request to Google and check for HTTP/2 session setup followed by
RECV_ACCEPT_CHor an equivalent frame event. - After
ERR_ABORTED, check whether a new main-frame navigation request appears before the timeout. - Compare an automated run with a controlled manual Chrome run, keeping the destination and proxy route the same where possible.
ERR_ABORTED by itself does not establish that navigation is permanently broken. In the vendor’s manual Chrome reproduction, the author describes it as part of a cancellation followed by a retry. The absence or presence of that next request is the more useful clue.
Change one variable at a time
Where your environment permits, compare the authenticated proxy with a route that does not require browser-facing proxy credentials, compare HTTP/2 with HTTP/1.1, or test the feature flag described below. These are diagnostic comparisons, not guaranteed fixes. Playwright documents HTTP(S) and SOCKSv5 proxy support, including optional username and password fields for HTTP(S) proxy authentication at browser or context scope; support for configuring credentials does not guarantee every Chromium navigation flow is free of version-specific issues. Playwright proxy documentation.
Workarounds and what they change
| Option | What the report says | Trade-off |
|---|---|---|
| Disable the ACCEPT_CH frame feature | Launch with --disable-features=AcceptCHFrame. The report says this preserves HTTP/2 and leaves the older Accept-CH response-header mechanism available. |
Validate the flag and behavior against your exact Chromium build; the report is not a guarantee for other versions. |
| Use a local forwarding proxy | Have the browser connect without proxy credentials to a local forwarder, which then connects to the authenticated upstream proxy. | This adds a component to configure and secure. The report’s sketch says rewriting only the first request on a connection suits its stated HTTPS CONNECT design; plain HTTP keep-alive traffic needs request-head handling on every request. It is not a maintained or security-reviewed product recommendation. |
| Disable HTTP/2 | The report says this worked in its case. | It affects protocol use more broadly across sites, so consider it a diagnostic fallback rather than the default fix. |
After any change, repeat the network-log check and verify that the page loads in the same Playwright and Chromium build that originally failed. A workaround that changes the symptom without confirming the navigation sequence may conceal a different issue.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What the related Playwright issue does—and does not—show
A separate Playwright GitHub issue describes a Chromium redirect hang involving proxy credentials in a particular version range. The reporter says registering a no-op route changed that reproduction, and the issue was closed as not planned. This is evidence that proxy-authentication and navigation interactions have been reported elsewhere, but it concerns redirects and does not confirm the ACCEPT_CH explanation or establish a general route-based fix. Playwright GitHub issue.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
