[Bug]: Proxy with login pass does not work

[gudge25]

Pre-flight

• I searched existing issues and this isn't a duplicate
• I'm on the latest released version (or noted my version below)

OpenWA version

0.8.7

Deployment

Other (describe below)

Database

PostgreSQL

WhatsApp engine

whatsapp-web.js

What happened?

Proxy (website webshare.io )with login and password does not work
if IP auth -> all good

proxy applied:
{"timestamp":"2026-07-05T11:53:55.432Z","level":"info","context":"WhatsAppWebJsAdapter","message":"Using proxy: socks5://socks5://jkxivowr-2:***@p.webshare.io:80"}

Steps to reproduce

1- Use a proxy (login/pass) from webshare.io
Free Proxy List

2- it is working from curl
curl --proxy "socks5://jkxivowr-2:***@p.webshare.io:80/" https://ipv4.webshare.io/
45.38.107.97

Expected behavior

No response

Relevant logs

[Nest] 7  - 07/05/2026, 12:03:17 PM   ERROR [ExceptionsHandler] ProtocolError: Page.navigate timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.
    at <instance_members_initializer> (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/common/CallbackRegistry.js:103:14)
    at new Callback (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/common/CallbackRegistry.js:107:16)
    at CallbackRegistry.create (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/common/CallbackRegistry.js:25:26)
    at Connection._rawSend (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/Connection.js:108:26)
    at CdpCDPSession.send (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/CdpSession.js:74:33)
    at navigate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/Frame.js:173:51)
    at CdpFrame.goto (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/Frame.js:151:17)
    at CdpFrame.<anonymous> (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/util/decorators.js:109:27)
    at CdpPage.goto (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/api/Page.js:580:43)
    at Client.initialize (/app/node_modules/whatsapp-web.js/src/Client.js:487:20)

Environment / additional context

No response

[gudge25]

When without password (IP auth) -> all good
(for IP auth port is diff)

[rmyndharis]

Thanks for the report and the clear reproduction (curl-works-but-Chrome-doesn't is the key signal).

Root cause: the whatsapp-web.js engine runs inside Chromium, and the gateway was passing your proxy as --proxy-server=socks5://user:pass@host:port. Chromium ignores credentials embedded in --proxy-server, which is why an IP-authorized proxy (no credentials) works but a username/password one doesn't. The socks5://socks5:// you saw in the log was just a cosmetic duplication in the log line, not the actual flag.

There are two parts to this:

1. HTTP/HTTPS proxies with authentication — fixed (fix(proxy): authenticate HTTP/HTTPS proxies via wwjs proxyAuthentication (#628) #632). The credentials are now handed to whatsapp-web.js's proxyAuthentication option (Chromium's page.authenticate), and --proxy-server gets a credential-less URL. Authenticated HTTP/HTTPS proxies will work after this ships.

2. SOCKS5 with authentication — not fixable, unfortunately. Chromium does not support SOCKS proxy authentication at all (chromium#256785) — there's no flag or option for it. The fix above adds a clear warning for this case instead of the opaque navigation timeout.

What to do for your webshare setup: switch from the SOCKS5 endpoint to webshare's HTTP proxy endpoint (same username/password) and set the session proxyType to http. That path authenticates correctly. If you must stay on SOCKS, use the IP-authorized endpoint (which you confirmed works) or run a local SOCKS relay that handles the auth and expose an unauthenticated local proxy to the gateway.

Will land on the next release.