Bug type

Behavior bug (incorrect output/state without crash)

Summary

On a corporate Windows 11 VM, OS DNS for web.whatsapp.com is blocked (NXDOMAIN), but outbound HTTPS works via an authenticated HTTP proxy (https_proxy). OpenClaw’s WhatsApp linking fails because the Baileys WebSocket path performs direct DNS resolution and does not honor proxy env vars. A NODE_OPTIONS preload workaround that forces proxy usage for undici fetch() and https.request() makes WhatsApp linking succeed (QR scan works).

Network evidence (DNS blocked, proxy works)
OS DNS fails:

Resolve-DnsName web.whatsapp.com
# -> NXDOMAIN / "DNS name does not exist"

But HTTPS works through the proxy via CONNECT:

curl -v https://web.whatsapp.com/ 2>&1 | Select-String -Pattern "CONNECT|proxy|Connected"
# Shows:
# * Uses proxy env variable https_proxy == 'http://127.0.0.1:3128'
# > CONNECT web.whatsapp.com:443 HTTP/1.1
# < HTTP/1.1 200 Connection established
# * Established connection to 127.0.0.1:3128 ...

Steps to reproduce

1. On a machine where Resolve-DnsName web.whatsapp.com fails (NXDOMAIN) but curl succeeds via https_proxy, configure OpenClaw with WhatsApp enabled (default account).

2. Attempt to link WhatsApp:

• via onboarding (link now / QR), or
• via the internal linker used by CLI (loginWeb)

Observed failure:

Waiting for WhatsApp connection…
WhatsApp Web connection ended before fully opening. status=408 Request Time-out WebSocket Error (getaddrinfo ENOTFOUND web.whatsapp.com)

The underlying error originates from Baileys/ws:

WebSocket Error (getaddrinfo ENOTFOUND web.whatsapp.com)

Expected behavior

If https_proxy/HTTPS_PROXY is set (and proxy supports CONNECT), WhatsApp linking should route all required WhatsApp HTTPS/WSS traffic through the proxy (or at least offer a config option to do so), instead of attempting direct DNS resolution.

Actual behavior

WhatsApp linking fails because the WS connection path resolves web.whatsapp.com directly using OS DNS (which is NXDOMAIN in this corporate environment).

OpenClaw version

2026.3.13 (61d171a)

Operating system

Windows 11

Install method

npm install -g openclaw@latest

Model

openai/chatgpt-5.4

Provider / routing chain

openclaw -> px local proxy -> corporate proxy -> whatsapp

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Workaround / Proof of concept

A NODE_OPTIONS preload script that:

1. installs undici’s EnvHttpProxyAgent as the global dispatcher (so Node/undici fetch is proxy-aware), and
2. forces a CONNECT-tunneling https.Agent into https.request() for WhatsApp domains
   makes WhatsApp linking succeed (QR displayed and scan completes).

POC patch: (link to gist/pastebin or attach file)
openclaw-proxy-preload.cjs (attached)

Usage:
$env:OPENCLAW_PROXY_PRELOAD_DEBUG="1"
$env:NODE_OPTIONS="--require \openclaw-proxy-preload.cjs"

Run the linker (example: call the internal loginWeb function)

$openclawRoot = Join-Path (npm root -g) "openclaw"
$loginModule = Join-Path $openclawRoot "dist\login-CC_UlAJF.js"
$env:OPENCLAW_LOGIN_URL = 'file:///' + ($loginModule -replace '\','/')

node --input-type=module -e "import(process.env.OPENCLAW_LOGIN_URL).then(m => m.t(true, undefined, undefined, 'default')).catch(e => { console.error(e); process.exit(1); })"

Proposed fix
Add first-class proxy support for the WhatsApp channel/Baileys transport, e.g.:
If proxy env vars are present (or a dedicated config like channels.whatsapp.proxyUrl), ensure:
undici/global fetch uses an env proxy dispatcher (EnvHttpProxyAgent)
the Baileys socket is created with a proxy-capable agent so the WSS connection does not require OS DNS resolution
Document supported proxy behavior and limitations.

Here is the Patch that I'm currently using for me to run WhatsApp
openclaw-proxy-preload.js

Extra notes
The proxy does allow CONNECT to web.whatsapp.com and WSS (confirmed by successful linking with the preload shim).
I also observed an occasional Windows libuv assertion during failures:
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING) ... win/async.c
Might be unrelated, but mentioning in case it helps triage.