openclaw - 💡(How to fix) Fix [Bug]: WhatsApp login handshake times out when OpenClaw is used behind env-var proxy, while curl/browser succeed [1 participants]

Summary

With proxy environment variables set, openclaw channels login --channel whatsapp --verbose consistently fails with status=408 Request Time-out WebSocket Error (Opening handshake has timed out) even though the same machine can reach https://web.whatsapp.com/ via browser and curl, and a direct Node/WebSocket repro succeeds once an explicit HttpsProxyAgent is supplied.

Steps to reproduce

1. On macOS, export proxy env vars in the shell:

export http_proxy=http://127.0.0.1:10808
export https_proxy=http://127.0.0.1:10808
export all_proxy=socks5://127.0.0.1:10808
export HTTP_PROXY=http://127.0.0.1:10808
export HTTPS_PROXY=http://127.0.0.1:10808
export ALL_PROXY=socks5://127.0.0.1:10808

1. Verify browser can open https://web.whatsapp.com/.
2. Verify curl can reach WhatsApp through the proxy. Observed locally: curl logs that it uses https_proxy, connects to 127.0.0.1:10808, establishes the CONNECT tunnel, and completes TLS.
3. Run:

openclaw channels login --channel whatsapp --verbose

1. Observe:

Waiting for WhatsApp connection...
WhatsApp Web connection ended before fully opening. status=408 Request Time-out WebSocket Error (Opening handshake has timed out)
Channel login failed: Error: status=408 Request Time-out WebSocket Error (Opening handshake has timed out)

1. In the same shell, run a Node HTTPS request without an explicit proxy agent. Observed locally: timeout.
2. In the same shell, run a Node WebSocket to wss://web.whatsapp.com/ws/chat without an explicit proxy agent. Observed locally: Error Opening handshake has timed out.
3. Repeat step 7 with an explicit HttpsProxyAgent('http://127.0.0.1:10808'). Observed locally: the WebSocket reaches open.

Expected behavior

When proxy env vars are present, WhatsApp login should either (a) honor the configured proxy path for the Node/WebSocket login flow or (b) document that this flow does not support env-var proxies. The observed local evidence suggests the login flow should be able to establish the WebSocket when an explicit proxy agent is used.

Actual behavior

Observed output from openclaw channels login --channel whatsapp --verbose:

Waiting for WhatsApp connection...
WhatsApp Web connection ended before fully opening. status=408 Request Time-out WebSocket Error (Opening handshake has timed out)
Channel login failed: Error: status=408 Request Time-out WebSocket Error (Opening handshake has timed out)

Observed local comparisons:

• Browser can open https://web.whatsapp.com/ on the same machine.
• curl succeeds through the exported proxy.
• Node https.get('https://web.whatsapp.com/') times out without an explicit proxy agent.
• Node WebSocket to wss://web.whatsapp.com/ws/chat reproduces the same handshake timeout without an explicit proxy agent.
• The same Node WebSocket reaches open when configured with HttpsProxyAgent('http://127.0.0.1:10808').

Environment

• OpenClaw version: 2026.4.2 (d74a122)
• OS: macOS Darwin 25.3.0 (arm64)
• Install method: Homebrew-installed OpenClaw CLI/gateway on macOS; login attempted from terminal with gateway running via LaunchAgent
• Model: NOT_ENOUGH_INFO
• Provider / routing chain: Shell env proxy -> local proxy at 127.0.0.1:10808 -> WhatsApp Web endpoints; OpenClaw WhatsApp login path appears to use Node HTTPS/WebSocket without picking up the env-var proxy automatically.

Additional observations

• Shell env contains both lowercase and uppercase proxy vars.
• curl clearly honors https_proxy.
• Plain Node https.get() in the same env times out until an explicit HttpsProxyAgent is supplied.
• Plain Node ws to wss://web.whatsapp.com/ws/chat reproduces the same timeout until an explicit HttpsProxyAgent is supplied.
• Local schema lookup did not show a documented channels.whatsapp.*proxy* or plugin proxy config field.

This suggests the WhatsApp login implementation path may not be wiring env-var proxy support into its HTTPS/WebSocket client path.