openclaw - 💡(How to fix) Fix Telegram media download fails: SSRF blocks 'api.telegram.org' when using proxy [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#61782Fetched 2026-04-08 02:54:36
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Participants
Timeline (top)
subscribed ×2

Error Message

  1. Gateway error log shows: Blocked hostname (not in allowlist): 127.0.0.1

Root Cause

The SSRF protection logic appears to be incorrectly using the proxy hostname (127.0.0.1) as the target for SSRF hostname allowlist checking, instead of the actual destination api.telegram.org.

Fix Action

Fix / Workaround

  • curl with the same proxy successfully downloads Telegram files (returns HTTP 200) — confirming the proxy itself works
  • The issue occurs on all Telegram accounts/bots when they have proxy configured
  • A workaround using /etc/hosts to force IPv4 for api.telegram.org helps but does not fully resolve the issue since the SSRF check is matching the proxy hostname, not the target

Code Example

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

---

{
  "channels": {
    "telegram": {
      "accounts": {
        "prostudy": {
          "botToken": "...",
          "proxy": "http://127.0.0.1:15236"
        }
      }
    }
  }
}
RAW_BUFFERClick to expand / collapse

Bug Description

When a Telegram bot receives an image from a user and attempts to download it via the Bot API getFile endpoint, OpenClaw's SSRF protection blocks the request with:

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

The target URL is api.telegram.org but the SSRF check is seeing the proxy hostname 127.0.0.1 as the request target, triggering the private IP block.

Environment

  • OpenClaw version: 2026.4.2 (d74a122)
  • OS: macOS 15.6.1 (Darwin arm64)
  • Node: v25.6.1
  • Telegram bot configured with proxy: http://127.0.0.1:15236 (Veee)

Steps to Reproduce

  1. Configure a Telegram bot with a proxy URL in channels.telegram.accounts.<accountId>.proxy
  2. Send an image to the bot via Telegram DM or group
  3. The bot shows: "⚠️ Failed to download media. Please try again."
  4. Gateway error log shows: Blocked hostname (not in allowlist): 127.0.0.1

Expected Behavior

Telegram media downloads should succeed when a proxy is configured. The SSRF check should see the target hostname (api.telegram.org) not the proxy's hostname.

Root Cause Analysis

The SSRF protection logic appears to be incorrectly using the proxy hostname (127.0.0.1) as the target for SSRF hostname allowlist checking, instead of the actual destination api.telegram.org.

Additional Context

  • curl with the same proxy successfully downloads Telegram files (returns HTTP 200) — confirming the proxy itself works
  • The issue occurs on all Telegram accounts/bots when they have proxy configured
  • A workaround using /etc/hosts to force IPv4 for api.telegram.org helps but does not fully resolve the issue since the SSRF check is matching the proxy hostname, not the target

Config Snippet

{
  "channels": {
    "telegram": {
      "accounts": {
        "prostudy": {
          "botToken": "...",
          "proxy": "http://127.0.0.1:15236"
        }
      }
    }
  }
}

Suggested Fix

Telegram bot media downloads should either:

  1. Bypass SSRF check for api.telegram.org (trusted Telegram Bot API endpoint), or
  2. Fix the SSRF logic to correctly use the target URL hostname rather than the proxy hostname when checking against the allowlist

extent analysis

TL;DR

  • The most likely fix involves updating the SSRF protection logic to use the target URL hostname (api.telegram.org) instead of the proxy hostname (127.0.0.1) for allowlist checking.

Guidance

  • Review the SSRF protection logic to ensure it correctly handles proxy configurations by using the target URL's hostname for allowlist checks.
  • Consider temporarily bypassing the SSRF check for trusted endpoints like api.telegram.org to mitigate the issue.
  • Verify that the proxy itself is functioning correctly by using tools like curl to download files via the proxy.
  • Investigate why the workaround using /etc/hosts to force IPv4 for api.telegram.org does not fully resolve the issue.

Example

  • No explicit code example is provided due to the lack of specific implementation details in the issue description. However, the fix would involve modifying the SSRF protection logic to correctly handle proxy configurations.

Notes

  • The issue seems to be specific to the interaction between the Telegram bot, the proxy configuration, and the SSRF protection logic in OpenClaw.
  • The provided workaround and curl test suggest that the proxy itself is not the primary cause of the issue.

Recommendation

  • Apply workaround: Bypass SSRF check for api.telegram.org as a temporary solution until the SSRF logic can be updated to correctly handle proxy configurations. This is recommended because it allows for immediate mitigation of the issue while a more permanent fix is developed.

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