web_fetch network failure: Blocks Fake-IP (198.18.x.x) and ignores OS System Proxy
- Dominant language
- No language data
- Stars
- 2.1k
- Forks
- 153
- PR merge metrics
- No merged PRs in 30d
Description
### Short summary
web_fetch cannot access the internet in standard proxy environments (e.g., Clash/Mihomo/Surge). It aggressively blocks RFC 2544 Fake-IP ranges due to SSRF protection when TUN mode is on, while simultaneously ignoring OS system proxy settings when TUN mode is off
### Affected version or release
v1.019
### Installation context
windows x64
### What happened?
When using proxy tools (Clash/Mihomo) to access globally blocked sites (like Google), the app's web_fetch fails entirely under both common network setups. The issue stems from two overlapping networking limitations in the app:
Scenario 1: Using TUN Mode (Fake-IP)
When TUN mode is enabled, the proxy router resolves DNS to the 198.18.0.0/15 range (Standard RFC 2544 Fake-IP). web_fetch intercepts this locally and throws an SSRF protection error, refusing to connect:
WebFetchBlockedUrlError: Error: web_fetch URL "https://www.google.com/" resolves to blocked address 198.18.0.9. URLs must not target loopback, private, or link-local addresses.
Scenario 2: Using Standard OS System Proxy (TUN disabled)
If I disable TUN mode and use standard OS proxy routing (Rule Mode), websites that are not blocked (like baidu.com) can be fetched. However, blocked sites (like google.com or httpbin.org) throw:
TypeError: fetch failed or status code 503
This occurs because the underlying Node.js fetch implementation natively ignores OS System Proxy settings and attempts a direct connection, which then hits the firewall.
### Steps to reproduce
case1:use poxy tools like clash verge, turn off TUN mode, then try github copilot app's webfetch tool, you will see webfetch tool ignoring OS system proxy settings.
case2:use poxy tools like clash verge, turn on TUN mode, then try github copilot app's webfetch tool, you will see: WebFetchBlockedUrlError: Error: web_fetch URL "https://www.google.com/" resolves to blocked address 198.18.0.9. URLs must not target loopback, private, or link-local addresses.
### Expected behavior
Comparison & Expected Behavior:
Other AI IDEs and desktop clients (like Trae and OpenCode) handle this environment flawlessly because they:
Provide a bypass/whitelist for the 198.18.0.0/15 range in their SSRF policies.
Explicitly inject OS proxy settings into their fetch agents.
Suggested Fixes:
Please whitelist the 198.18.0.0/15 subnet for SSRF checks, as this is the industry standard for Fake-IP environments.
Provide a configuration option to respect OS system proxies or at least read HTTP_PROXY / HTTPS_PROXY environment variables.
### Additional context
_No response_
Contributor guide
Research direction
Start at the web_fetch network request, reviewing its SSRF address checks and the underlying Node.js fetch configuration. Reproduce both Clash/Mihomo setups described in the issue; done means web_fetch handles the Fake-IP case and uses the system proxy for blocked sites without losing SSRF protection.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100