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
- OpenClaw is already on a recent version (
2026.4.1), so this does not appear to be an "old version" problem.
openclaw-gateway is actually running with the proxy env vars:
- confirmed in
systemctl --user cat openclaw-gateway.service
- confirmed again in
/proc/<pid>/environ
openclaw gateway status reports the gateway is healthy and reachable (RPC probe: ok).
- The local proxy endpoint itself is reachable and working (
http://127.0.0.1:7897).
- Despite all of the above,
web_fetch still fails for https://huggingface.co with the SSRF/private-address error.
Reproduction
- Put the machine behind Mihomo / OpenClash with
fake-ip enabled.
- Configure
openclaw-gateway with explicit env proxy variables (HTTP_PROXY / HTTPS_PROXY).
- Restart the gateway and verify the env vars are present in the running process.
- Call
web_fetch on:
Actual result
web_fetch fails with:
Blocked: resolves to private/internal/special-use IP address
Expected result
One of these should be true:
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
- 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
- Is this current behavior expected, or is it a bug / missing piece?
- 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?
- Should OpenClaw expose a documented user-facing allowlist / trusted-domains mechanism for
web_fetch specifically?
Summary
In a Mihomo/OpenClash
fake-ipnetwork,web_fetchstill fails for ordinary external URLs likehttps://huggingface.cowith:Blocked: resolves to private/internal/special-use IP addressThis still happens on a recent OpenClaw build even after configuring
openclaw-gatewayto run withHTTP_PROXY/HTTPS_PROXYand 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:
But in practice, a normal
web_fetchtarget such as Hugging Face still appears to stay on the strict pinned-DNS path and gets blocked in a common fake-ip deployment.Environment
2026.4.1fake-ip198.18.0.0/15HTTP_PROXY=http://127.0.0.1:7897HTTPS_PROXY=http://127.0.0.1:7897ALL_PROXY=http://127.0.0.1:7897NO_PROXY=127.0.0.1,localhost,::1What I verified
2026.4.1), so this does not appear to be an "old version" problem.openclaw-gatewayis actually running with the proxy env vars:systemctl --user cat openclaw-gateway.service/proc/<pid>/environopenclaw gateway statusreports the gateway is healthy and reachable (RPC probe: ok).http://127.0.0.1:7897).web_fetchstill fails forhttps://huggingface.cowith the SSRF/private-address error.Reproduction
fake-ipenabled.openclaw-gatewaywith explicit env proxy variables (HTTP_PROXY/HTTPS_PROXY).web_fetchon:https://huggingface.coActual result
web_fetchfails with:Blocked: resolves to private/internal/special-use IP addressExpected result
One of these should be true:
web_fetchshould successfully work for common public targets in fake-ip deployments when the gateway is correctly configured with a trusted env proxy, orweb_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_fetchURLs still keep strict DNS pinning even whenHTTP_PROXYis 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
web_fetchbehind Mihomo/OpenClash fake-ip when users need to fetch normal public sites like Hugging Face?web_fetchspecifically?