openclaw - 💡(How to fix) Fix web_fetch still blocked by fake-ip SSRF in Mihomo/OpenClash setup even with HTTP_PROXY/HTTPS_PROXY configured [1 participants]

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?