Skip to content

web_fetch still blocked by fake-ip SSRF in Mihomo/OpenClash setup even with HTTP_PROXY/HTTPS_PROXY configured #60785

@Silronin

Description

@Silronin

Summary

In a Mihomo/OpenClash fake-ip network, web_fetch still fails for ordinary external URLs like https://huggingface.co with:

Blocked: resolves to private/internal/special-use IP address

This still happens on a recent OpenClaw build even after configuring openclaw-gateway to run with HTTP_PROXY / HTTPS_PROXY and verifying those env vars are present in the live gateway process.

From a user perspective, the current behavior is confusing because recent changelog entries suggest improved support for:

  • RFC2544 fake-IP compatibility
  • proxy-aware SSRF guard paths
  • trusted env-proxy routing for web tools

But in practice, a normal web_fetch target such as Hugging Face still appears to stay on the strict pinned-DNS path and gets blocked in a common fake-ip deployment.

Environment

  • OpenClaw gateway version: 2026.4.1
  • OS: Linux
  • Upstream network: OpenClash / Mihomo with fake-ip
  • Fake-IP range involved: 198.18.0.0/15
  • Explicit gateway proxy configured via user systemd drop-in:
    • HTTP_PROXY=http://127.0.0.1:7897
    • HTTPS_PROXY=http://127.0.0.1:7897
    • ALL_PROXY=http://127.0.0.1:7897
    • NO_PROXY=127.0.0.1,localhost,::1

What I verified

  1. OpenClaw is already on a recent version (2026.4.1), so this does not appear to be an "old version" problem.
  2. openclaw-gateway is actually running with the proxy env vars:
    • confirmed in systemctl --user cat openclaw-gateway.service
    • confirmed again in /proc/<pid>/environ
  3. openclaw gateway status reports the gateway is healthy and reachable (RPC probe: ok).
  4. The local proxy endpoint itself is reachable and working (http://127.0.0.1:7897).
  5. Despite all of the above, web_fetch still fails for https://huggingface.co with the SSRF/private-address error.

Reproduction

  1. Put the machine behind Mihomo / OpenClash with fake-ip enabled.
  2. Configure openclaw-gateway with explicit env proxy variables (HTTP_PROXY / HTTPS_PROXY).
  3. Restart the gateway and verify the env vars are present in the running process.
  4. Call web_fetch on:
    • https://huggingface.co

Actual result

web_fetch fails with:

Blocked: resolves to private/internal/special-use IP address

Expected result

One of these should be true:

  1. web_fetch should successfully work for common public targets in fake-ip deployments when the gateway is correctly configured with a trusted env proxy, or
  2. the docs/config should clearly expose the intended user-facing mechanism for this case (for example, a documented trusted-domain / allowlist path for web_fetch).

Additional findings from local source inspection

From local source/tests in the OpenClaw repo, this behavior appears related to the fact that ordinary / untrusted web_fetch URLs still keep strict DNS pinning even when HTTP_PROXY is configured.

In other words, the current trusted env-proxy path seems to exist, but not in a way that solves this user-facing case for normal external fetch targets behind fake-ip.

Questions

  1. Is this current behavior expected, or is it a bug / missing piece?
  2. What is the officially recommended solution for web_fetch behind Mihomo/OpenClash fake-ip when users need to fetch normal public sites like Hugging Face?
  3. Should OpenClaw expose a documented user-facing allowlist / trusted-domains mechanism for web_fetch specifically?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions