[Bug]: Proxy with login pass does not work

[gudge25]

As requested moved here
#819

[gudge25]

should i just set env var

DEBUG=puppeteer:*

in order to gather logs

[gudge25]

Added as env
DEBUG: "puppeteer:*"

But don't see more logs

[Nest] 7  - 07/24/2026, 6:18:20 PM   DEBUG [EventsGateway] Client KpQYYrODJ94Ab8lXAAAD subscribed to: session:*:session.status, session:*:session.qr
{"timestamp":"2026-07-24T18:18:25.318Z","level":"info","context":"SessionService","message":"Initializing engine for session: pl-mob","sessionId":"f7585c4d-907a-48aa-9d04-aeba50a4f95a","action":"engine_init","proxyEnabled":true,"requestId":"791fe12e-7af0-4013-8752-f00e82a683ee"}
{"timestamp":"2026-07-24T18:18:25.349Z","level":"info","context":"WhatsAppWebJsAdapter","message":"Using proxy: http://p.webshare.io","requestId":"791fe12e-7af0-4013-8752-f00e82a683ee"}
{"timestamp":"2026-07-24T18:18:25.349Z","level":"info","context":"WhatsAppWebJsAdapter","message":"Pinning WhatsApp Web version 2.3000.1043755002-alpha","requestId":"791fe12e-7af0-4013-8752-f00e82a683ee"}
{"timestamp":"2026-07-24T18:18:27.779Z","level":"error","context":"SessionService","message":"Session engine failed: net::ERR_INVALID_AUTH_CREDENTIALS at https://web.whatsapp.com/","sessionId":"f7585c4d-907a-48aa-9d04-aeba50a4f95a","reason":"net::ERR_INVALID_AUTH_CREDENTIALS at https://web.whatsapp.com/","action":"engine_error","requestId":"791fe12e-7af0-4013-8752-f00e82a683ee"}
[Nest] 7  - 07/24/2026, 6:18:27 PM   ERROR [ExceptionsHandler] Error: net::ERR_INVALID_AUTH_CREDENTIALS at https://web.whatsapp.com/
    at navigate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/Frame.js:184:27)
    at async Deferred.race (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/util/Deferred.js:36:20)
    at async CdpFrame.goto (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/Frame.js:150:25)
    at async CdpPage.goto (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/api/Page.js:580:20)
    at async Client.initialize (/app/node_modules/whatsapp-web.js/src/Client.js:487:9)
    at async WhatsAppWebJsAdapter.initialize (/app/dist/engine/adapters/whatsapp-web-js.adapter.js:342:13)

[gudge25]

I captured a complete DEBUG=puppeteer:* protocol trace.
Chromium enables Fetch.enable(handleAuthRequests=true).
The browser navigates to https://web.whatsapp.com/.
The proxy responds with:

HTTP 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Invalid proxy credentials or missing IP Authorization."

Immediately afterward Chromium emits:

Network.loadingFailed
net::ERR_INVALID_AUTH_CREDENTIALS

There are no Fetch.authRequired or Fetch.continueWithAuth events anywhere in the protocol log, despite handleAuthRequests=true being enabled.

Since Puppeteer never receives Fetch.authRequired, it has no opportunity to supply the credentials. Is this a Chromium/Puppeteer regression with proxy authentication?

[gudge25]

What is unexpected

The protocol log never contains:

• Fetch.authRequired
• Fetch.continueWithAuth

Additional information

• The same proxy credentials work with curl.

[rmyndharis]

@gudge25 — thanks, this trace is exactly what I asked for, and the Fetch.authRequired observation is the load-bearing finding. You earned a proper answer, including one correction to what I wrote in #819.

What your trace actually shows

The expected CDP sequence when page.authenticate({username, password}) is wired up (which is how OpenWA wires it — credentials split out of --proxy-server and handed to whatsapp-web.js's proxyAuthentication option, called before goto web.whatsapp.com) is:

Fetch.requestPaused  →  proxy 407  →  Fetch.authRequired  →  Fetch.continueWithAuth(credentials)

Your trace has the first two steps — proxy responds 407 Proxy Authentication Required with Proxy-Authenticate: Basic realm="Invalid proxy credentials or missing IP Authorization." — and then nothing. No Fetch.authRequired, no Fetch.continueWithAuth. That means Puppeteer never got the chance to supply credentials through the standard path.

So I owe you a correction. In #819 I wrote that the error means "the proxy received and rejected your credentials." Your trace contradicts that — it's consistent with the credentials never having been delivered via the CDP auth path at all. The curl success you noted fits either reading (curl puts Proxy-Authorization directly on the CONNECT, not via Fetch.continueWithAuth), so it doesn't by itself separate the two, but it does confirm the credentials themselves are valid.

This is a known rough edge in Puppeteer/Chromium proxy auth (tracked upstream, e.g. puppeteer#7405, #3253): page.authenticate() reliably covers the case where the proxy challenges after an initial request succeeds, but can miss the case where the proxy 407s on the very first CONNECT. That matches your symptom — it fails immediately on navigation, not after a successful load.

The one test that closes it

Both of these can be true at once, so the question is which one is doing the work for your setup:

• (A) IP allowlist — Webshare rejects because the pod's egress IP isn't authorized; credentials are irrelevant.
• (B) Chromium never delivered the credentials — IP is fine, but the Fetch.authRequired path didn't engage, so the proxy never saw auth.

To separate them, do exactly one of:

1. Check the Webshare dashboard access log for the failing request. A 407 with a Proxy-Authorization header present → (A). A 407 with no auth header on the request → (B).
2. Or, more definitive: point the session at a local mitmproxy (mitmproxy --mode regular -p 8080, proxy URL http://user:pass@127.0.0.1:8080) and inspect whether Proxy-Authorization is present on the CONNECT. mitmproxy logs headers unconditionally and has no IP allowlist, so it isolates the delivery path cleanly.

If it's (A): authorize the pod's egress IP in Webshare, or switch to IP-allowlist auth and drop user:pass. No OpenWA change possible or needed.

If it's (B) with the IP correctly authorized: that's genuinely a Puppeteer/Chromium-side problem in the proxy-auth path, and at that point it belongs upstream rather than in OpenWA — OpenWA is already doing the only thing the API exposes (page.authenticate); there's no additional hook to force Fetch.continueWithAuth from our side without forking whatsapp-web.js.

The robust path, regardless

For any proxy-heavy deployment the Baileys engine is the right call. It authenticates the proxy at the Node layer (socks-proxy-agent / https-proxy-agent) on the socket itself, so this entire class of CDP-timing problem doesn't exist there. Set ENGINE_TYPE=baileys and run the same proxy URL — if it connects clean, that's near-proof the issue lives in the Chromium auth path, not in your credentials or in OpenWA.

[gudge25]

thanks for reply
i tried to switvh to baileys
but is says that proxy is unsupported there

{"timestamp":"2026-07-27T15:36:18.490Z","level":"info","context":"SessionService","message":"Initializing engine for session: pl-mob","sessionId":"f7585c4d-907a-48aa-9d04-aeba50a4f95a","action":"engine_init","proxyEnabled":true,"requestId":"e6037d17-2b29-4601-971d-cada10a67bc5"}
{"timestamp":"2026-07-27T15:36:18.491Z","level":"warn","context":"BaileysAdapter","message":"**Proxy configured but not supported by the baileys engine in this slice; ignoring it**","action":"baileys_proxy_unsupported","sessionId":"pl-mob","requestId":"e6037d17-2b29-4601-971d-cada10a67bc5"}
{"timestamp":"2026-07-27T15:36:19.679Z","level":"info","context":"SessionService","message":"Session ready: XXXXXXX","sessionId":"f7585c4d-907a-48aa-9d04-aeba50a4f95a","phone":"XXXXXXX","pushName":"Anton","action":"ready","requestId":"e6037d17-2b29-4601-971d-cada10a67bc5"}

[gudge25]

tried both http and socks5
both -> baileys_proxy_unsupported

[rmyndharis]

@gudge25 — you were right, and the warning you hit was the real story: the Baileys adapter shipped without proxy support. The baileys_proxy_unsupported gate has been there since the engine's first slice, so my earlier "switch to Baileys, it handles proxies at the Node layer" described what the underlying library can do — not what OpenWA actually wired up. That's on me, and your log settled it.

It's now implemented: #973, merged to main, and it will be in the next release.

What you get on the Baileys engine:

• The session proxyUrl — http, https, socks4 or socks5, credentialed user:pass@host form included — is applied to both the WhatsApp WebSocket and media uploads/downloads.
• Credentials are authenticated on the socket itself, the same way your successful curl test does it. There is no Fetch.authRequired round-trip involved, so the Chromium first-CONNECT 407 failure from your trace structurally cannot occur on this engine.
• Credentialed SOCKS works too — something Chromium cannot do at all.
• Fail-closed: if a stored proxy value can't be honored, the session now refuses to start with a clear engine error instead of silently connecting direct. The surprising "READY without proxy" you observed (which briefly exposed your pod's real egress IP) can't happen again.

To try it before the release: run a build of current main (git pull && docker compose up -d --build), set ENGINE_TYPE=baileys, and keep the exact same proxy URL on the session.

One nice side effect: this doubles as the discriminating test from my earlier comment. If the Baileys session connects cleanly through the same Webshare URL from the same pod, your credentials and egress IP are both fine — which pins the wwjs failure squarely on Chromium's proxy-auth path. If you specifically need the wwjs engine, IP-allowlist auth remains the reliable configuration there.

Please report back either way — if anything about the proxy path misbehaves on Baileys, that's now a bug I want to know about.