openclaw - 💡(How to fix) Fix [Bug]: Discord channel WebSocket fails TLS hostname check when proxy.enabled is set (validates against localhost instead of gateway.discord.gg) [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On 2026.4.29, configuring proxy.enabled: true + proxy.proxyUrl: "http://127.0.0.1:6152" (the operator-managed outbound HTTP proxy added in 2026.4.27) breaks all Discord channels: the Discord plugin's WebSocket transport opens through the HTTP forward proxy but validates the TLS certificate against the proxy host (localhost) instead of the original target (gateway.discord.gg), putting every configured Discord bot into an infinite reconnect loop. Telegram's symmetrical issue was fixed via #74014 in this same release; Discord did not receive the equivalent fix.

Steps to reproduce

1. Run a local HTTP forward proxy on 127.0.0.1:6152 (any plain http:// forward proxy — Surge HTTP proxy in this case).
2. Add to openclaw.json:

   "proxy": { "enabled": true, "proxyUrl": "http://127.0.0.1:6152" }

3. Configure one or more Discord bot accounts under channels.discord and channels.discord.accounts.
4. Restart the gateway.
5. Observe the gateway log. With 4 configured Discord bots, ~600 ERROR lines accumulated in 30 minutes from gateway/channels/discord before the proxy config was reverted.

Expected behavior

The Discord channel plugin's WebSocket transport, when using an HTTP forward proxy, should pass the original target hostname (gateway.discord.gg) as the TLS servername / checkServerIdentity target so the end-to-end cert validates against the cert's actual SANs (DNS:discord.gg, DNS:*.discord.gg). This mirrors the Telegram Bot API transport fix in #74014. Alternatively, exposing a per-channel proxy-bypass knob (analogous to NO_PROXY) would also let operators opt Discord out of the global proxy.proxyUrl.

Actual behavior

The WebSocket TLS handshake validates the cert (which IS the genuine Discord cert — note the cert SANs in the error) against the proxy's connect address (localhost) and rejects it. The Discord client logs the error, the gateway tears down the channel, the channel restart logic re-attempts after 15s, and the loop never converges. All Discord channels remain non-functional for the duration. Verbatim primary error:

[gateway/channels/discord] discord gateway error: Error: Hostname/IP does not match certificate's altnames: Host: localhost. is not in the cert's altnames: DNS:discord.gg, DNS:*.discord.gg

Cascading errors triggered by this primary failure (counts observed in a 30-minute window with 4 configured Discord bots):

• gateway/channels/discord discord gateway error: ... Hostname/IP does not match certificate's altnames — 322
• gateway/channels/discord discord: gateway was not ready after 15000ms; restarting gateway — 43
• gateway/channels/discord discord: suppressed late gateway other error after dispose: ... Hostname/IP does not match — 42
• Per-bot [<bot>] channel exited: discord gateway did not reach READY within 15000ms after restart — 4 × ~10

OpenClaw version

OpenClaw 2026.4.29

Operating system

macOS 26.3.1 (Apple Silicon — Mac mini M4 Pro)

Install method

npm global install (/opt/homebrew/lib/node_modules/openclaw), launchd LaunchAgent supervisor

Model

Not model-specific — defect is in the Discord channel plugin's WebSocket-over-HTTP-proxy transport, independent of agent model selection.

Provider / routing chain

Not provider-specific.

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Verbatim primary error already included under Actual behavior above. Restart timeline showing the loop pattern (per-minute error count over 30 min, with proxy.enabled: true):

16:25–30   78
16:35–40  382
16:45–50  130

After reverting proxy.enabled (back to direct egress with the SSRF fake-IP patch re-applied), Discord channels reconnect cleanly within ~50s and the gateway log shows zero Hostname/IP does not match certificate's altnames errors.

Impact and severity

High for any operator who tries to use the new proxy.enabled feature alongside Discord. The Discord bots remain entirely non-functional (no inbound or outbound delivery) and the gateway log fills at ~20 errors/minute. The operator must revert the proxy config and use a different SSRF-bypass mechanism. Any documentation that recommends proxy.enabled as a unified outbound-routing mechanism should call out that Discord is not yet covered.

Additional information

#74014 fixed the symmetric issue for Telegram in 4.29 (Channels/Telegram: honor ALL_PROXY / all_proxy and service-level OPENCLAW_PROXY_URL when constructing the HTTP/1-only Telegram Bot API transport). The Discord channel plugin needs the equivalent end-to-end-aware proxy support: when wrapping the WebSocket through HTTP CONNECT, the underlying TLS socket must validate against the original target hostname, not the proxy's connect address.

Workaround used: remove proxy.enabled + proxy.proxyUrl from openclaw.json, restore direct egress, and (for fake-IP networks like Surge with TUN-mode DNS) re-apply the local SSRF patch that allows 198.18.0.0/15 (RFC2544) through resolveIpv4SpecialUseBlockOptions until OpenClaw natively supports that range or a clean per-host proxy bypass lands.