Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug] Telegram media download fails: proxy users api.telegram.org resolves to 127.0.0.1, SSRF blocks it [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#62539•Fetched 2026-04-08 03:02:48
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
ChuishiMengChuishiMeng
Participants
ChuishiMengChuishiMeng
Timeline (top)
cross-referenced ×1

When using a transparent proxy (e.g. Clash Verge, Surge, Quantumult), api.telegram.org DNS resolves to a proxy virtual IP (127.0.0.1 or 198.18.0.68 — RFC 2544 benchmark range). OpenClaw SSRF guard blocks the download with:

[security] blocked URL fetch (url-fetch) target=https://api.telegram.org/file/bot.../photos/file_XX.jpg 
  reason=Blocked hostname (not in allowlist): 127.0.0.1

User-facing error: ⚠️ Failed to download media. Please try again.

Error Message

User-facing error: ⚠️ Failed to download media. Please try again.

Root Cause

buildTelegramMediaSsrfPolicy() in the compiled bundle sets allowRfc2544BenchmarkRange: false (as noted in #57452). Even after that fix was merged, proxy users whose DNS resolves api.telegram.org to private/loopback addresses are still blocked because the hostname api.telegram.org itself is not in the default hostname allowlist (which only allows api.telegram.org when it resolves to a public IP).

Fix Action

Workaround

None currently. The user either has to:

  1. Disable their proxy for api.telegram.org (breaks other things)
  2. Wait for a fix

Code Example

[security] blocked URL fetch (url-fetch) target=https://api.telegram.org/file/bot.../photos/file_XX.jpg 
  reason=Blocked hostname (not in allowlist): 127.0.0.1
RAW_BUFFERClick to expand / collapse

Environment

  • OpenClaw version: 2026.4.5
  • Channel: Telegram
  • OS: macOS
  • Proxy: Clash Verge (transparent proxy mode)
  • Node: v25.6.0

Description

When using a transparent proxy (e.g. Clash Verge, Surge, Quantumult), api.telegram.org DNS resolves to a proxy virtual IP (127.0.0.1 or 198.18.0.68 — RFC 2544 benchmark range). OpenClaw SSRF guard blocks the download with:

[security] blocked URL fetch (url-fetch) target=https://api.telegram.org/file/bot.../photos/file_XX.jpg 
  reason=Blocked hostname (not in allowlist): 127.0.0.1

User-facing error: ⚠️ Failed to download media. Please try again.

Root Cause

buildTelegramMediaSsrfPolicy() in the compiled bundle sets allowRfc2544BenchmarkRange: false (as noted in #57452). Even after that fix was merged, proxy users whose DNS resolves api.telegram.org to private/loopback addresses are still blocked because the hostname api.telegram.org itself is not in the default hostname allowlist (which only allows api.telegram.org when it resolves to a public IP).

Reproduction

  1. Run any transparent proxy (Clash Verge, Surge, etc.) that rewrites DNS for proxied domains
  2. Configure OpenClaw Telegram bot
  3. Send any image to the bot via Telegram
  4. Observe: ⚠️ Failed to download media. Please try again.

Expected Behavior

Telegram media downloads should work when:

  • The proxy is transparent (system-level)
  • Bot API polling/webhook works fine (which it does — only file downloads fail)
  • The user has NOT configured channels.telegram.accounts.<id>.proxy explicitly (system proxy handles everything)

Workaround

None currently. The user either has to:

  1. Disable their proxy for api.telegram.org (breaks other things)
  2. Wait for a fix

Suggested Fix

One of:

  1. Add api.telegram.org to the default hostname allowlist for Telegram media downloads (regardless of resolved IP)
  2. Honor channels.telegram.accounts.<id>.network.dangerouslyAllowPrivateNetwork for media downloads
  3. Make the Telegram media SSRF policy accept RFC 2544 / loopback addresses (it already does for the benchmark range in some builds, but not loopback)

extent analysis

TL;DR

Add api.telegram.org to the default hostname allowlist for Telegram media downloads to resolve the SSRF guard block issue.

Guidance

  • Review the buildTelegramMediaSsrfPolicy() function to understand how the allowlist is currently configured and how it can be modified to include api.telegram.org regardless of its resolved IP.
  • Consider implementing one of the suggested fixes, such as adding api.telegram.org to the allowlist or honoring the dangerouslyAllowPrivateNetwork setting for media downloads.
  • Test the changes with a transparent proxy setup to ensure that Telegram media downloads work as expected.
  • Evaluate the potential security implications of allowing private network addresses in the SSRF policy.

Example

No code snippet is provided as the issue does not contain sufficient information to generate a specific example.

Notes

The suggested fix may have security implications, and it is essential to evaluate the potential risks before implementing the changes. Additionally, the issue may be specific to the OpenClaw version and configuration, so testing and verification are crucial to ensure the fix works as expected.

Recommendation

Apply a workaround by adding api.telegram.org to the default hostname allowlist for Telegram media downloads, as this is the most straightforward solution to resolve the issue. This change should allow Telegram media downloads to work with transparent proxies without requiring users to disable their proxy or wait for a fix.

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#tool integration#LLM response#prompt template

Still need to ship something?

×6

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

Back to top recommendations

TRENDING