Summary

web_fetch appears to falsely block normal public URLs in Clash Verge / Mihomo fake-ip environments, returning:

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

This makes web_fetch unusable in a common China-based network setup where a proxy is required for normal access.

Environment

• OpenClaw: 2026.3.13
• OS: Windows
• Proxy: Clash Verge / Mihomo
• TUN: enabled
• System proxy: enabled
• fake-ip mode: enabled

Symptoms

The following kinds of URLs fail through web_fetch with the same error:

• https://clawhub.ai/steipete/trello
• https://raw.githubusercontent.com/...
• Gemini grounding citation redirect URLs such as:
  • https://vertexaisearch.cloud.google.com/grounding-api-redirect/...

At the same time:

• browser-based access usually still works
• direct network access is still possible through the proxy
• the issue seems specific to the SSRF / URL fetch guard path

Observed behavior

In this environment, DNS resolution for normal public domains returns 198.18.x.x, for example:

• Resolve-DnsName clawhub.ai -> 198.18.0.37

However, public DNS returns a real public IP, for example:

• Google DoH for clawhub.ai returns 216.150.1.1

Also, direct requests can still succeed, for example:

• curl -I -L https://clawhub.ai/steipete/trello returns HTTP/1.1 200 OK

So the target site is reachable; the failure happens because web_fetch sees the fake-ip result and blocks it before the request proceeds.

Root cause hypothesis

This looks like a false positive in SSRF protection when running behind fake-ip proxy setups.

In Clash fake-ip mode, public domains are intentionally resolved to addresses in 198.18.0.0/15 as an intermediate proxy/DNS mechanism. OpenClaw's URL fetch guard appears to treat this as a private/internal/special-use destination and blocks the request immediately.

In practice, this breaks legitimate public web access for users who must rely on this kind of proxy environment.

Why this matters

For users in China and similar network conditions, running without Clash/Mihomo is often not realistic. In those environments, this issue can effectively disable web_fetch and related URL-fetching features for many normal public sites.

This is not just a corner case; it affects a common real-world deployment setup.

Suggested fixes

A few possible approaches:

1. Expose SSRF policy for tools.web.fetch, for example:

   • tools.web.fetch.ssrfPolicy.allowRfc2544BenchmarkRange
   • or another explicit fake-ip compatibility option

2. Thread that config through the web_fetch implementation layer (likely src/agents/tools/web-guarded-fetch.ts) into the lower-level SSRF/IP guard.

3. Reuse existing lower-level support for RFC2544 benchmark range handling if already present.

4. Optional improvements:

   • DoH re-check before blocking when the resolved address is in a special-use range
   • better error messaging for fake-ip environments
   • browser fallback for public URLs that fail only due to fake-ip SSRF classification

Additional note

This also seems to affect Gemini grounding citation redirect fetching, which suggests the same guarded URL fetch path may be reused in multiple places.