openclaw - ✅(Solved) Fix Solution: Proxy configuration for LLM timeout and Telegram in restricted networks (China) [1 pull requests, 2 comments, 2 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#43629Fetched 2026-04-08 00:16:38
View on GitHub
Comments
2
Participants
2
Timeline
4
Reactions
0
Timeline (top)
commented ×2cross-referenced ×2

Error Message

  1. LLM Timeout Error - LLM request timed out

Root Cause

  1. LLM Timeout: System proxy was enabled in Windows Registry (ProxyEnable=1). OpenClaw accessed MiniMax LLM through the proxy, but the proxy route caused timeout due to unnecessary detour.

  2. Telegram Connection Failed: Telegram API is blocked in Mainland China and requires a proxy to access. However, OpenClaw was not properly configured with a dedicated proxy for Telegram.

Fix Action

Fixed

PR fix notes

PR #43919: Fix/global proxy dispatcher

Description (problem / solution / changelog)

Summary

  • Problem: LLM inference requests time out when the gateway runs behind a proxy (HTTP_PROXY / HTTPS_PROXY / ALL_PROXY), because Node.js 22+'s globalThis.fetch (undici) does not read proxy env vars by default, and the upstream streamSimple in @mariozechner/pi-ai does not accept a dispatcher parameter.
  • Why it matters: Users in corporate firewalls, and other restricted networks cannot use OpenClaw for LLM inference at all — the only working path (curl -x) proves the proxy itself is fine.
  • What changed: Added applyGlobalProxyDispatcher() in src/infra/net/global-proxy.ts that calls setGlobalDispatcher(new EnvHttpProxyAgent()) early in gateway startup (after dotenv loading), making all globalThis.fetch calls proxy-aware. Added ALL_PROXY / socks5:// / socks5h:// normalization in src/infra/net/proxy-env.ts. 17 unit tests.
  • What did NOT change (scope boundary): No modifications to existing Telegram, WhatsApp, media-understanding, or web-tools proxy log.

Change Type

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #20549
  • Closes #43821
  • Related #43629, #27228, #30075
  • Complements #43248 (merged) — see Relationship with #43248 below

User-visible / Behavior Changes

  • When HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY env vars are set, LLM inference requests now route through the proxy instead of timing out.
  • [net/global-proxy] global undici dispatcher set to EnvHttpProxyAgent (via ...) log line appears at startup when proxy is active.
  • ALL_PROXY with socks5:// or socks5h:// is rewritten to http:// for undici compatibility (most local proxy tools like Clash/V2Ray accept HTTP CONNECT on the same port).
  • NO_PROXY / no_proxy exclusions are respected — localhost services (Ollama, browser control, canvas host) are not affected.

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? Yes — existing globalThis.fetch calls are now routed through the user-configured proxy when env vars are set. No new outbound calls are introduced.
  • Command/tool execution surface changed? No
  • Data access scope changed? No
  • If any Yes, explain risk + mitigation: The proxy dispatcher only activates when the user explicitly sets proxy env vars. EnvHttpProxyAgent respects NO_PROXY exclusions, so internal/localhost traffic is unaffected. If EnvHttpProxyAgent construction fails (e.g. malformed URL), the error is logged and the gateway continues with direct connections.

Repro + Verification

Environment

  • OS: macOS (Darwin 25.2.0), also affects Linux
  • Runtime/container: Node.js 22+
  • Model/provider: Any (Google Gemini, Anthropic, OpenAI-compatible)
  • Integration/channel (if any): All channels — the fix is at the global fetch layer
  • Relevant config (redacted): HTTP_PROXY=http://127.0.0.1:7897 HTTPS_PROXY=http://127.0.0.1:7897 ALL_PROXY=socks5://127.0.0.1:7897

Steps

  1. Be in a network where direct connections to LLM APIs are blocked (common in China, corporate firewalls)
  2. Start gateway: env HTTP_PROXY="http://127.0.0.1:7897" HTTPS_PROXY="http://127.0.0.1:7897" openclaw gateway
  3. Send any message that triggers LLM inference

Expected

  • LLM inference requests succeed through the proxy
  • [net/global-proxy] global undici dispatcher set to EnvHttpProxyAgent (via HTTP_PROXY) in startup log

Actual (before fix)

  • Repeated LLM request timed out errors, even though curl -x http://127.0.0.1:7897 https://generativelanguage.googleapis.com/... succeeds

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Unit tests (17 cases, all passing):

✓ sets global dispatcher when HTTPS_PROXY is set
✓ sets global dispatcher when HTTP_PROXY is set
✓ sets global dispatcher when ALL_PROXY is set
✓ rewrites socks5:// ALL_PROXY to http:// for EnvHttpProxyAgent compatibility
✓ rewrites socks5h:// ALL_PROXY to http:// for EnvHttpProxyAgent compatibility
✓ passes http:// ALL_PROXY as-is
✓ passes all_proxy (lowercase) as explicit httpProxy/httpsProxy
✓ prefers lowercase all_proxy over uppercase ALL_PROXY
✓ does not pass explicit options when HTTP_PROXY is also set alongside ALL_PROXY
✓ does not pass explicit options when HTTPS_PROXY is set (no ALL_PROXY fallback needed)
✓ sets global dispatcher when lowercase proxy vars are set
✓ is a no-op when no proxy env var is set
✓ only applies once even if called multiple times
✓ skips if a proxy-like dispatcher is already installed
✓ does not skip if existing dispatcher is not proxy-like
✓ handles EnvHttpProxyAgent constructor failure gracefully

Regression tests pass with zero regressions:

  • src/infra/net/proxy-fetch.test.ts — 7/7 passed
  • src/infra/net/fetch-guard.ssrf.test.ts — 9/9 passed

Startup log confirming proxy activation:

2026-03-13T14:56:08.218+08:00 [net/global-proxy] global undici dispatcher set to EnvHttpProxyAgent (via HTTP_PROXY)

Human Verification

  • Verified scenarios:
    • Built and installed locally via npm link (OpenClaw 2026.3.13, commit 2b46c4c)
    • Started gateway with env OPENCLAW_DISABLE_BONJOUR=1 HTTP_PROXY="http://127.0.0.1:7897" HTTPS_PROXY="http://127.0.0.1:7897" ALL_PROXY="socks5://127.0.0.1:7897" openclaw gateway run --force
    • Confirmed [net/global-proxy] global undici dispatcher set to EnvHttpProxyAgent (via HTTP_PROXY) in startup log
    • Gateway started successfully, all channels connected, subagent dispatch unaffected
    • Localhost services (browser control on :18791, canvas host) remain accessible without proxy interference
  • Edge cases checked:
    • socks5h:// protocol variant (was broken by original regex, now fixed)
    • ALL_PROXY-only configuration (no HTTP_PROXY/HTTPS_PROXY set)
    • Idempotent re-invocation (safe to call multiple times)
    • Cooperative skip when another proxy dispatcher is already installed
    • Graceful failure on malformed proxy URL
  • What I did not verify:
    • Windows-specific behavior (lowercase vs uppercase env var precedence)
    • SOCKS-only proxy endpoints that do not accept HTTP CONNECT on the same port

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No — uses existing standard proxy env vars (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY)
  • Migration needed? No

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: Remove the applyGlobalProxyDispatcher() call in src/gateway/server.impl.ts (single line). Or simply unset proxy env vars — the function is a no-op without them.
  • Files/config to restore: src/gateway/server.impl.ts (remove import + call)
  • Known bad symptoms reviewers should watch for: If a SOCKS-only proxy does not accept HTTP CONNECT, the rewrite from socks5:// to http:// will cause connection failures. Users would see fetch errors instead of timeouts.

Risks and Mitigations

  • Risk: SOCKS5-to-HTTP rewrite assumes the proxy accepts HTTP CONNECT on the same port.
    • Mitigation: This is true for all major local proxy tools (Clash, V2Ray, Shadowsocks, Surge). For truly SOCKS-only endpoints, the connection will fail at connect time with a clear error, which is still better than silently timing out.
  • Risk: Global dispatcher affects all globalThis.fetch calls process-wide.
    • Mitigation: This is intentional — the whole point is to cover streamSimple which only uses globalThis.fetch. EnvHttpProxyAgent respects NO_PROXY so internal traffic is excluded. The function is cooperative (skips if a proxy dispatcher is already installed) and idempotent.

Comparison with existing open PRs

PRApproachLimitations
#33990ProxyAgent in server-startup.tsDoes not respect NO_PROXY; modifies Telegram code
#42320EnvHttpProxyAgent in undici-global-dispatcher.tsOnly covers embedded runner path, not startup/heartbeat/web-search
#41455Similar to #42320Excludes ALL_PROXY; only covers embedded runner

Files changed

  • src/infra/net/global-proxy.ts — New module: applyGlobalProxyDispatcher() + test reset helper
  • src/infra/net/global-proxy.test.ts — 17 unit tests
  • src/infra/net/proxy-env.ts — Added resolveAllProxyFallbackOptions(), SOCKS protocol normalization (builds on resolveEnvHttpProxyUrl / hasEnvHttpProxyConfigured from #43248)
  • src/gateway/server.impl.ts — Import and call applyGlobalProxyDispatcher() after readConfigFileSnapshot()

Relationship with #43248

#43248 (merged 2026-03-11) added ensureGlobalUndiciEnvProxyDispatcher() in undici-global-dispatcher.ts, called inside the embedded runner's runEmbeddedAttempt(). This PR complements it with two things #43248 does not cover:

#43248 (merged)This PR
Injection pointrunEmbeddedAttempt() — per-run, embedded runner onlystartGatewayServer() — once at gateway startup, covers all fetch paths
CoverageModel traffic via embedded runnerAll globalThis.fetch: LLM inference, heartbeat, web search, usage tracking, etc.
ALL_PROXY supportNo — explicitly excludedYes — resolveAllProxyFallbackOptions() bridges undici's EnvHttpProxyAgent gap
SOCKS protocolNoYes — socks5://, socks5h://, socks4:// rewritten to http://
dotenv timingN/A (runs after config is loaded)Explicitly placed after readConfigFileSnapshot() so .env-defined proxy vars are visible

This PR reuses the resolveEnvHttpProxyUrl and hasEnvHttpProxyConfigured helpers that #43248 added to proxy-env.ts, and adds resolveAllProxyFallbackOptions() on top for the ALL_PROXY/SOCKS gap.

Changed files

  • src/gateway/server.impl.ts (modified, +9/-0)
  • src/infra/net/global-proxy.test.ts (added, +276/-0)
  • src/infra/net/global-proxy.ts (added, +120/-0)
  • src/infra/net/proxy-env.ts (modified, +114/-0)

Code Example

{
  "env": {
    "vars": {
      "JINA_API_KEY": "your_jina_api_key",
      "HTTP_PROXY": "",
      "HTTPS_PROXY": "",
      "http_proxy": "",
      "https_proxy": "",
      "ALL_PROXY": "",
      "all_proxy": "",
      "NO_PROXY": "*"
    }
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "dmPolicy": "pairing",
      "botToken": "your_telegram_bot_token",
      "groupPolicy": "open",
      "streaming": "partial",
      "timeoutSeconds": 60,
      "proxy": "http://127.0.0.1:10809"
    }
  }
}
RAW_BUFFERClick to expand / collapse

Solution: Proxy Configuration for LLM Timeout and Telegram in Restricted Networks (China)

Problem Description

Encountered the following issues when using OpenClaw:

  1. LLM Timeout Error - LLM request timed out
  2. Telegram Connection Failed - deleteWebhook failed: Network request failed

Environment

  • OpenClaw Version: 2026.3.8
  • Proxy Software: v2rayn (listening on 127.0.0.1:10809)
  • System Proxy: Enabled in Windows Registry
  • LLM: MiniMax-M2.5
  • Deployment Environment: Mainland China

Root Cause

  1. LLM Timeout: System proxy was enabled in Windows Registry (ProxyEnable=1). OpenClaw accessed MiniMax LLM through the proxy, but the proxy route caused timeout due to unnecessary detour.

  2. Telegram Connection Failed: Telegram API is blocked in Mainland China and requires a proxy to access. However, OpenClaw was not properly configured with a dedicated proxy for Telegram.

Solution

Config File Location

~/.openclaw/openclaw.json

Complete Configuration

{
  "env": {
    "vars": {
      "JINA_API_KEY": "your_jina_api_key",
      "HTTP_PROXY": "",
      "HTTPS_PROXY": "",
      "http_proxy": "",
      "https_proxy": "",
      "ALL_PROXY": "",
      "all_proxy": "",
      "NO_PROXY": "*"
    }
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "dmPolicy": "pairing",
      "botToken": "your_telegram_bot_token",
      "groupPolicy": "open",
      "streaming": "partial",
      "timeoutSeconds": 60,
      "proxy": "http://127.0.0.1:10809"
    }
  }
}

Configuration Explanation

Config ItemPurpose
HTTP_PROXY: "" etc.Disable global proxy, allow LLM to connect directly
NO_PROXY: "*"Exclude all domains from proxy
channels.telegram.proxyDedicated proxy for Telegram
channels.telegram.timeoutSeconds: 60Telegram timeout setting (fixes unstable proxy connections)

Core Strategy

  • LLM Requests: Disable proxy, connect directly to domestic API (fixes timeout)
  • Telegram: Configure dedicated proxy separately (fixes connection issue)

Steps

  1. Edit config file: ~/.openclaw/openclaw.json
  2. Add the configuration above
  3. Restart Gateway: openclaw gateway restart
  4. Verify both Telegram and LLM are working properly

Related References

  • GitHub Issue: #41704 - Telegram polling stalls when using proxy
  • GitHub Issue: #25676 - Telegram API calls fail in restricted networks

Author

Abner Date: 2026-03-12

extent analysis

Fix Plan

To resolve the LLM timeout and Telegram connection issues, follow these steps:

  • Edit the ~/.openclaw/openclaw.json configuration file.
  • Add the following configuration:
{
  "env": {
    "vars": {
      "JINA_API_KEY": "your_jina_api_key",
      "HTTP_PROXY": "",
      "HTTPS_PROXY": "",
      "http_proxy": "",
      "https_proxy": "",
      "ALL_PROXY": "",
      "all_proxy": "",
      "NO_PROXY": "*"
    }
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "dmPolicy": "pairing",
      "botToken": "your_telegram_bot_token",
      "groupPolicy": "open",
      "streaming": "partial",
      "timeoutSeconds": 60,
      "proxy": "http://127.0.0.1:10809"
    }
  }
}
  • Replace your_jina_api_key and your_telegram_bot_token with your actual API key and bot token.
  • Restart the OpenClaw gateway using the command openclaw gateway restart.

Verification

After applying the configuration changes, verify that:

  • LLM requests are connecting directly without proxy.
  • Telegram is using the dedicated proxy.
  • Both LLM and Telegram are working properly.

Extra Tips

  • Ensure the proxy software (v2rayn) is configured correctly and listening on the specified port (127.0.0.1:10809).
  • If issues persist, check the GitHub issues (#41704 and #25676) for additional troubleshooting steps.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING