PR #60565: fix: Telegram media download fails when proxy is socks5

• Repository: openclaw/openclaw
• Author: KChow-ctrl
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/60565

Description (problem / solution / changelog)

Summary

Telegram media downloads fail when using socks5:// proxy because the SSRF guard enforces pinned DNS checks that expect HTTP(S) proxy URLs. Since undici natively handles socks5:// proxies and the target media URL is always HTTPS, we disable the pinned DNS checks for media downloads by setting pinDns: false.

Changes

• Added pinDns: false to fetchWithSsrFGuard call in src/media/fetch.ts for media downloads
• This allows Telegram media to be downloaded through socks5:// proxies without SSRF pinned DNS validation errors

Testing

• Ran vitest run src/media/fetch.test.ts - 7 tests passed
• Ran vitest run extensions/telegram/src/fetch.test.ts - 22 tests passed

Fixes openclaw/openclaw#60472

Changed files

• extensions/feishu/src/media.ts (modified, +3/-1)
• extensions/ollama/index.ts (modified, +4/-1)
• extensions/ollama/src/stream.ts (modified, +21/-2)

---

PR #63633: fix: support socks5/socks4 proxy via undici Socks5ProxyAgent

• Repository: openclaw/openclaw
• Author: heichaowo
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/63633

Description (problem / solution / changelog)

Fixes openclaw/openclaw#60472

makeProxyFetch() previously passed any proxy URL directly...

No new dependencies required.

Summary

• Problem: makeProxyFetch() passes any proxy URL directly to undici's ProxyAgent, which only supports HTTP/HTTPS schemes. When channels.telegram.proxy is set to socks5:// or socks4://, undici throws on connection and all Telegram media downloads fail.
• Why it matters: Users behind SOCKS5-only networks (e.g. Shadowsocks/Shadowrocket) cannot receive Telegram media at all; the failure is silent with no actionable error.
• What changed: makeProxyFetch() now detects SOCKS schemes via isSocksProxyUrl() and dispatches to undici's built-in Socks5ProxyAgent instead of ProxyAgent. HTTP/HTTPS proxy paths are unchanged.
• What did NOT change: SSRF guard logic, Telegram transport retry/fallback, env-proxy path, any other channel.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Integrations

Linked Issue/PR

• Closes #60472

Root Cause (if applicable)

• Root cause: undici.ProxyAgent does not support SOCKS protocols; passing a socks5:// URI causes an immediate connection error.
• Missing detection / guardrail: No scheme validation before constructing ProxyAgent.
• Contributing context: undici 8.x ships Socks5ProxyAgent natively but it was never wired into makeProxyFetch().

Regression Test Plan (if applicable)

• Coverage level:
  • Unit test
• Target test: src/infra/net/proxy-fetch.test.ts
• Scenario: makeProxyFetch("socks5://...") routes to Socks5ProxyAgent; makeProxyFetch("http://...") continues to use ProxyAgent; agent is reused across calls; getProxyUrlFromFetch() returns correct URL for SOCKS proxies.
• Why smallest reliable guardrail: The fix is entirely within makeProxyFetch(); unit-level mock of undici constructors is sufficient.
• Existing test that already covers this: None (SOCKS path was untested).

User-visible / Behavior Changes

Users can now set channels.telegram.proxy: "socks5://host:port" and Telegram media downloads will work correctly. Previously this silently failed.

Diagram (if applicable)

Before: makeProxyFetch("socks5://...") -> new ProxyAgent("socks5://...") -> undici error

After: makeProxyFetch("socks5://...") -> isSocksProxyUrl() == true -> new Socks5ProxyAgent({ uri }) -> OK makeProxyFetch("http://...") -> isSocksProxyUrl() == false -> new ProxyAgent(url) -> OK (unchanged)

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No (routing path changes, destination unchanged)
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS 26 (arm64)
• Runtime: Node.js v24.13.0
• Integration/channel: Telegram
• Relevant config: channels.telegram.proxy: "socks5://127.0.0.1:1080"

Steps

1. Set channels.telegram.proxy to a socks5:// URL
2. Send a photo/video via Telegram
3. Agent attempts to download the media

Expected

Media downloads successfully through the SOCKS5 proxy.

Actual (before fix)

undici throws on connection; media download fails silently.

Evidence

• Unit tests added: 5 new cases in proxy-fetch.test.ts

Human Verification (required)

• Verified scenarios: socks5 proxy routing on macOS arm64 with Shadowrocket SOCKS5 (127.0.0.1:1080)
• Edge cases checked: socks4://, agent reuse, proxyUrl metadata round-trip
• What you did not verify: socks5h://, socks4a:// (added to isSocksProxyUrl() by spec but not tested against a live socks5h server)

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
• Migration needed? No

Risks and Mitigations

• Risk: Socks5ProxyAgent constructor signature may differ between undici versions.
  • Mitigation: Checked against undici 8.0.2 (the pinned version); constructor accepts { uri: string }.

Changed files

• extensions/telegram/src/fetch.ts (modified, +26/-4)
• src/infra/net/proxy-fetch.test.ts (modified, +61/-1)
• src/infra/net/proxy-fetch.ts (modified, +24/-6)