Issue Draft: web_fetch blocked by SSRF protection in proxy/fake-ip environments

Title: web_fetch fails with "resolves to private/internal/special-use IP address" in proxy environments using fake-ip mode

Description

web_fetch fails for all URLs when running behind a transparent proxy (Surge, Clash, etc.) with fake-ip mode enabled. The proxy's DNS hijacking returns addresses in the 198.18.0.0/15 range (RFC 2544 Benchmark Testing), which triggers OpenClaw's SSRF protection.

Steps to Reproduce

1. Run OpenClaw on a machine with Surge/Clash in fake-ip (enhanced) mode
2. Use web_fetch to fetch any public URL (e.g., https://example.com)
3. Error: Blocked: resolves to private/internal/special-use IP address

Root Cause

The SSRF protection layer in fetchWithSsrFGuard resolves DNS locally and checks the resulting IP against blocked ranges. In fake-ip proxy environments, DNS queries return synthetic addresses (typically 198.18.x.x) that the proxy intercepts and forwards to the real destination. The local DNS result does not represent the actual connection target.

Call chain:

web_fetch → runWebFetch()
  → fetchWithWebToolsNetworkGuard() (strict mode, no policy)
    → fetchWithSsrFGuard(withStrictGuardedFetchMode(...))
      → resolvePinnedHostnameWithPolicy(hostname, { policy: undefined })
        → DNS lookup → 198.18.x.x (fake-ip from proxy)
        → assertAllowedResolvedAddressesOrThrow()
          → isBlockedSpecialUseIpv4Address(ip, { allowRfc2544BenchmarkRange: false })
          → BLOCKED ❌

Note: The codebase already has an allowRfc2544BenchmarkRange flag and uses it for trusted internal endpoints (Firecrawl API, Discord media), but the web_fetch strict mode path does not pass it through.

Proposed Solution

Add a user-facing configuration option to declare a proxy environment. When enabled, web_fetch skips DNS-based IP checks (which are meaningless behind a proxy) and relies on hostname-level blocklist only.

Configuration

network:
  assumeProxyEnvironment: true  # default: false

Behavior

What changes

• When proxy environment is detected/configured, fetchWithWebToolsNetworkGuard still resolves DNS (needed for connection establishment in transparent proxy scenarios), but skips the IP range checks in assertAllowedResolvedAddressesOrThrow
• Hostname blocklist (localhost, .internal, .local, metadata.google.internal) always remains active regardless of proxy mode
• Requests use EnvHttpProxyAgent when HTTP_PROXY/HTTPS_PROXY is set, or standard fetch otherwise (transparent proxy handles routing at network level)
• No changes to behavior when proxy is not detected/configured

Security Analysis

In proxy environments, the proxy itself controls routing and DNS resolution. OpenClaw cannot and should not attempt to enforce IP-level SSRF checks on synthetic DNS results that don't correspond to actual connection targets. The hostname blocklist provides sufficient protection against obvious SSRF vectors.

Error Message Enhancement

When web_fetch is blocked by RFC 2544 range detection, include a hint in the error message:

Blocked: resolves to private/internal/special-use IP address.
Hint: If you use a proxy with fake-ip mode (Surge, Clash, etc.), set `network.assumeProxyEnvironment: true` in your OpenClaw config.

Environment

• OpenClaw: 2026.3.28
• Proxy: Surge (Enhanced Mode / fake-ip)
• DNS returns: 198.18.x.x for all domains
• curl works fine (traffic routed through proxy)
• web_search works fine (server-side via Gemini API, no local DNS involved)