Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Slack Socket Mode WebSocket connections don't honor HTTPS_PROXY [3 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#57405•Fetched 2026-04-08 01:50:02
View on GitHub
Comments
1
Participants
1
Timeline
4
Reactions
0
Author
mjamivmjamiv
Participants
mjamivmjamiv
Timeline (top)
cross-referenced ×3commented ×1

Root Cause

When running OpenClaw inside a proxy-only network environment (e.g., NVIDIA OpenShell sandboxes), Slack Socket Mode WebSocket connections fail because the ws library does not natively honor the HTTPS_PROXY / HTTP_PROXY environment variables.

Fix Action

Fix / Workaround

Current Workaround

We wrote a NODE_OPTIONS=--require preload script that monkey-patches:

PR fix notes

PR #59007: fix(net): skip DNS pinning before trusted env proxy dispatch

Description (problem / solution / changelog)

Summary

Fixes fetchWithSsrFGuard() so trusted env-proxy mode can actually reach EnvHttpProxyAgent before any local DNS lookup is attempted.

This fixes the remaining proxy-only sandbox failure tracked in #59005. It is the same production gap described in #58034, but rebased cleanly on current main and with the fallback test tightened so host ALL_PROXY / all_proxy values cannot accidentally satisfy the proxy branch.

What changed

  • move DNS pinning and pinned-dispatcher creation into the non-proxy branch
  • keep trusted env-proxy dispatch as an early branch
  • clear all six proxy env keys in the tests before setting expectations
  • add an explicit regression test for trusted mode with no proxy env vars present

Why

#50650 fixed the strict-mode env-proxy path, but both main and v2026.3.31 still resolve DNS before entering the trusted env-proxy branch:

const pinned = await resolvePinnedHostnameWithPolicy(...);
const canUseTrustedEnvProxy =
  mode === GUARDED_FETCH_MODE.TRUSTED_ENV_PROXY && hasProxyEnvConfigured();
if (canUseTrustedEnvProxy) {
  dispatcher = new EnvHttpProxyAgent();
}

In proxy-only sandboxes, that ordering means the request fails on local DNS and never reaches the trusted proxy.

Testing

  • pnpm exec vitest run --config vitest.unit.config.ts src/infra/net/fetch-guard.ssrf.test.ts
  • pnpm check

Notes

  • Fixes #59005
  • Supersedes #58034

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/infra/net/fetch-guard.ssrf.test.ts (modified, +38/-0)
  • src/infra/net/fetch-guard.ts (modified, +4/-4)

PR #62241: fix(net): strip external undici dispatcher from custom fetchImpl calls

Description (problem / solution / changelog)

Summary

  • Fixes Slack file attachment downloads silently failing on OpenClaw 2026.4.5 with InvalidArgumentError: invalid onRequestStart method
  • Root cause: fetchWithSsrFGuard passes an external undici dispatcher (from the bundled undici package) through init to custom fetchImpl callers. These custom fetchers (e.g. Slack/Telegram media) wrap Node's built-in fetch(), which bundles its own undici 8.x internally. The handler interface changed between undici 7→8, causing the version mismatch error.
  • Fix: strip the dispatcher property from init before forwarding to custom fetchImpl callers. The SSRF DNS-pinning validation has already been performed before the custom fetcher is invoked, so security guarantees are preserved.

Test plan

  • Existing fetch-guard.ssrf.test.ts tests pass (no behavior change for runtime-fetch path)
  • Slack file attachment download works on Node 22+ with undici 8.x
  • Verify SSRF protection still blocks private IPs when custom fetchImpl is used

Fixes #62218

🤖 Generated with Claude Code

Changed files

  • extensions/slack/src/monitor/media.ts (modified, +6/-2)

PR #62878: fix(slack): honor HTTPS_PROXY for Socket Mode WebSocket connections

Description (problem / solution / changelog)

Summary

Slack Socket Mode ignores HTTPS_PROXY/HTTP_PROXY env vars — the ws library opens a direct WebSocket connection to wss-primary.slack.com, bypassing any configured proxy. This breaks Socket Mode in proxy-only environments (sandboxed containers, corporate networks, NVIDIA OpenShell).

This PR creates an HttpsProxyAgent from proxy env vars and passes it as the agent option through @slack/bolt → @slack/socket-mode → SlackWebSocket → ws, so the WebSocket upgrade request is tunneled through the HTTP CONNECT proxy.

Changes

  • extensions/slack/src/client.ts: resolveSlackWebClientOptions() and resolveSlackWriteClientOptions() now set agent to an HttpsProxyAgent when HTTPS_PROXY/HTTP_PROXY env vars are present. Follows undici EnvHttpProxyAgent semantics (lower-case takes precedence).
  • extensions/slack/package.json: Added https-proxy-agent dependency (same version as Discord extension).
  • extensions/slack/src/client.test.ts: Tests for proxy agent creation, env var precedence, explicit agent override, and no-op when no proxy is configured.

How it works

The agent flows through:

  1. resolveSlackWebClientOptions() → { agent: HttpsProxyAgent }
  2. new App({ clientOptions }) (Bolt)
  3. new SocketModeReceiver({ clientOptions }) → new SocketModeClient({ clientOptions })
  4. SlackWebSocket({ httpAgent: clientOptions.agent })
  5. new ws.WebSocket(url, { agent: httpAgent }) — tunneled through proxy ✅

Prior art

Mirrors the existing Discord gateway proxy support in extensions/discord/src/monitor/gateway-plugin.ts, which uses the same https-proxy-agent library.

Production validation

We've been running an equivalent monkey-patch (openclaw-ws-proxy-patch.js) across 4 OpenClaw agents on NVIDIA OpenShell sandboxes since March 2026, routing all Slack Socket Mode traffic through an HTTP CONNECT proxy at 10.200.0.1:3128. This PR replaces that workaround with a proper fix.

Fixes #57405

Test plan

  • HTTPS_PROXY set → Socket Mode connects through proxy
  • No proxy env vars → Socket Mode connects directly (no behavior change)
  • Explicit clientOptions.agent → not overridden by proxy detection
  • HTTP_PROXY fallback when HTTPS_PROXY not set
  • Lower-case https_proxy takes precedence over upper-case HTTPS_PROXY
  • Unit tests pass: extensions/slack/src/client.test.ts

Changed files

  • CHANGELOG.md (modified, +4/-0)
  • extensions/slack/package.json (modified, +2/-1)
  • extensions/slack/src/client.test.ts (modified, +135/-1)
  • extensions/slack/src/client.ts (modified, +68/-0)
  • pnpm-lock.yaml (modified, +3/-0)

Code Example

const { HttpsProxyAgent } = require('https-proxy-agent');
const proxyAgent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
const ws = new WebSocket(slackWssUrl, { agent: proxyAgent });
RAW_BUFFERClick to expand / collapse

Problem

When running OpenClaw inside a proxy-only network environment (e.g., NVIDIA OpenShell sandboxes), Slack Socket Mode WebSocket connections fail because the ws library does not natively honor the HTTPS_PROXY / HTTP_PROXY environment variables.

All outbound traffic in these environments must route through an HTTP CONNECT proxy. REST API calls work correctly because undici's EnvHttpProxyAgent respects proxy env vars. However, WebSocket connections to wss-primary.slack.com and wss-backup.slack.com bypass the proxy entirely and fail.

Additionally, Slack file downloads via Node's native https module (files.slack.com) also do not honor proxy env vars, so those fail as well.

Current Workaround

We wrote a NODE_OPTIONS=--require preload script that monkey-patches:

  1. The ws WebSocket constructor — intercepts new WebSocket(url, ...) calls targeting Slack WebSocket hosts, injects a custom https.Agent (via the https-proxy-agent package) that tunnels through the CONNECT proxy.
  2. Node's https.request / https.get — intercepts calls to files.slack.com and similarly injects a proxy-aware agent.

This works but is fragile, version-sensitive, and shouldn't be necessary.

Suggested Fix

When HTTPS_PROXY (or HTTP_PROXY / ALL_PROXY) is set, OpenClaw should pass a proxy-aware agent to the ws WebSocket constructor for Slack Socket Mode connections. For example, using https-proxy-agent or hpagent:

const { HttpsProxyAgent } = require('https-proxy-agent');
const proxyAgent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
const ws = new WebSocket(slackWssUrl, { agent: proxyAgent });

The same approach should apply to any https.request / https.get calls for Slack file downloads — pass the proxy agent via the agent option.

This would bring WebSocket and file-download behavior in line with how undici already handles REST calls via EnvHttpProxyAgent.

Environment

  • OpenClaw version: 2026.3.28
  • Node.js version: 22.22.1
  • Runtime: NVIDIA OpenShell v0.0.16 sandbox (Linux, isolated network namespace)
  • Proxy: HTTP CONNECT proxy at local bridge interface, no direct internet access
  • Slack integration: Socket Mode enabled

Related

  • Upstream bug: #46306 (SSRF fetch-guard DNS pinning vs. proxy — separate but related proxy issue)
  • Fix PR: #50650 (unmerged)

extent analysis

Fix Plan

To fix the issue, we need to modify the WebSocket connections and HTTPS requests to use a proxy-aware agent. Here are the steps:

  • Install the https-proxy-agent package:
    • Run npm install https-proxy-agent or yarn add https-proxy-agent
  • Create a proxy agent:
    • const { HttpsProxyAgent } = require('https-proxy-agent');
    • const proxyAgent = new HttpsProxyAgent(process.env.HTTPS_PROXY || process.env.HTTP_PROXY || process.env.ALL_PROXY);
  • Pass the proxy agent to the WebSocket constructor:
    • const ws = new WebSocket(slackWssUrl, { agent: proxyAgent });
  • Pass the proxy agent to HTTPS requests:
    • const https = require('https');
    • const options = { ... };
    • options.agent = proxyAgent;
    • https.request(url, options, callback);

Example code:

const { HttpsProxyAgent } = require('https-proxy-agent');
const https = require('https');

const proxyAgent = new HttpsProxyAgent(process.env.HTTPS_PROXY || process.env.HTTP_PROXY || process.env.ALL_PROXY);
const slackWssUrl = 'wss-primary.slack.com';

const ws = new WebSocket(slackWssUrl, { agent: proxyAgent });

const fileDownloadUrl = 'https://files.slack.com/files-pri/T12345678-B12345678/image.png';
const options = {
  method: 'GET',
  agent: proxyAgent
};

https.request(fileDownloadUrl, options, (res) => {
  // Handle response
}).end();

Verification

To verify that the fix worked, you can test the WebSocket connections and HTTPS requests by checking if they are successfully routed through the proxy. You can do this by:

  • Checking the proxy logs to see if the requests are being forwarded correctly
  • Using a tool like curl or a browser's developer tools to inspect the requests and verify that they are being proxied
  • Testing the Slack integration to ensure that it is working as expected

Extra Tips

  • Make sure to handle errors and exceptions properly when working with proxy agents and WebSocket connections
  • Consider adding logging and monitoring to track proxy usage and detect any issues
  • Keep in mind that using a proxy can introduce additional latency and affect performance, so it's essential to test and optimize your application accordingly.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#environment variable#agent setup#task chaining

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING