Skip to content

web_fetch network failure: Blocks Fake-IP (198.18.x.x) and ignores OS System Proxy #1867

Open

Description

@TomMao23

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions