You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Users running VPN/proxy tools with fake-IP mode (Surge Enhanced Mode, Clash fake-ip, Shadowrocket, etc.) cannot use web_fetch because the SSRF guard blocks the 198.18.0.0/15 (RFC 2544 benchmarking) range these tools use for DNS interception.
How fake-IP mode works
These proxy tools create a virtual network interface (e.g. utun) and assign fake IPs in the 198.18.0.0/15 range for all DNS queries. When an app connects to a fake IP, the proxy intercepts it at the IP layer and routes it through the configured proxy rules. This is essential for users in China and other restricted networks — it ensures ALL traffic (including apps that ignore system proxy / HTTP_PROXY env vars, like Node.js undici) goes through the proxy.
Current behavior
runWebFetch() → fetchWithSsrFGuard() → resolvePinnedHostnameWithPolicy() resolves the hostname, gets 198.18.x.x, and blocks it as a "special-use" IP address.
The blocking check in isBlockedSpecialUseIpv4Address() already supports an opt-out:
But runWebFetch() calls fetchWithSsrFGuard()without passing any policy, so allowRfc2544BenchmarkRange is always false. There is no config path to change this.
Proposed solution
Add ssrfPolicy (or at minimum allowRfc2544BenchmarkRange) to the tools.web.fetch config schema:
This request only asks to allow a single, specific, non-routable IP range (198.18.0.0/15, RFC 2544 benchmarking) that is never used on the public internet.
The SSRF guard continues to block all other private/internal/special-use ranges (RFC 1918, loopback, link-local, etc.).
The code already implements this check — it just needs a config path to reach it.
Who is affected
Every user running Surge (macOS/iOS), Clash, Shadowrocket, Quantumult X, or similar tools in Enhanced/fake-IP mode. This is effectively the entire user base in mainland China plus users in other restricted network environments.
Alternatives considered
Approach
Problem
always-real-ip = * in Surge
Defeats fake-IP benefits (zero-latency DNS, DNS pollution immunity, privacy)
Turn off Enhanced Mode
Node.js/undici ignores system proxy → blocked sites become unreachable
exec + curl fallback
Works but loses web_fetch features (readability extraction, caching, redirect handling)
browser.ssrfPolicy
Only affects browser tool, not web_fetch
Environment
OS: macOS (Darwin, arm64)
Proxy: Surge Mac with Enhanced Mode
DNS resolution: all domains → 198.18.x.x (Surge fake-IP)
Summary
Users running VPN/proxy tools with fake-IP mode (Surge Enhanced Mode, Clash fake-ip, Shadowrocket, etc.) cannot use
web_fetchbecause the SSRF guard blocks the198.18.0.0/15(RFC 2544 benchmarking) range these tools use for DNS interception.How fake-IP mode works
These proxy tools create a virtual network interface (e.g.
utun) and assign fake IPs in the198.18.0.0/15range for all DNS queries. When an app connects to a fake IP, the proxy intercepts it at the IP layer and routes it through the configured proxy rules. This is essential for users in China and other restricted networks — it ensures ALL traffic (including apps that ignore system proxy /HTTP_PROXYenv vars, like Node.jsundici) goes through the proxy.Current behavior
runWebFetch()→fetchWithSsrFGuard()→resolvePinnedHostnameWithPolicy()resolves the hostname, gets198.18.x.x, and blocks it as a "special-use" IP address.The blocking check in
isBlockedSpecialUseIpv4Address()already supports an opt-out:But
runWebFetch()callsfetchWithSsrFGuard()without passing anypolicy, soallowRfc2544BenchmarkRangeis alwaysfalse. There is no config path to change this.Proposed solution
Add
ssrfPolicy(or at minimumallowRfc2544BenchmarkRange) to thetools.web.fetchconfig schema:And pass it through to
fetchWithSsrFGuard()inrunWebFetch().Why this is different from #6298 (proxy support, closed as not planned)
198.18.0.0/15, RFC 2544 benchmarking) that is never used on the public internet.Who is affected
Every user running Surge (macOS/iOS), Clash, Shadowrocket, Quantumult X, or similar tools in Enhanced/fake-IP mode. This is effectively the entire user base in mainland China plus users in other restricted network environments.
Alternatives considered
always-real-ip = *in Surgeexec + curlfallbackbrowser.ssrfPolicyEnvironment
198.18.x.x(Surge fake-IP)