web_fetch rejects public domains resolved to Surge Fake-IP addresses on macOS (CLI 1.0.98) #5180

Describe the bug

On macOS with Surge Enhanced Mode enabled, Copilot CLI's built-in web_fetch rejects public HTTPS URLs because system DNS returns Surge Fake-IP addresses in 198.18.0.0/15.

This makes ordinary public documentation browsing fail even though the domain is intended to be reached through Surge. This report concerns the CLI specifically; a similar report exists for Copilot App in github/app#1867.

Environment

• GitHub Copilot CLI: 1.0.98 (copilot --version)
• OS: macOS
• Proxy: Surge for Mac, Enhanced Mode / Fake-IP DNS
• System HTTP and HTTPS proxy enabled
• DNS resolver list includes Surge's 198.18.0.2

Steps to reproduce

1. Enable Surge Enhanced Mode with Fake-IP DNS on macOS.
2. Confirm that a public hostname resolves to a Fake-IP address through the system resolver, for example:

   python3 -c 'import socket; print(socket.gethostbyname("lobehub.com"))'

   Observed result in this environment: 198.18.2.212.
3. Ask Copilot CLI to fetch https://lobehub.com/skills/vinitu-macos-music-skill using its built-in web_fetch tool.
4. The tool fails before retrieving the page.

Actual behavior

WebFetchBlockedUrlError: web_fetch URL "https://lobehub.com/skills/vinitu-macos-music-skill" resolves to blocked address 198.18.2.212. URLs must not target loopback, private, or link-local addresses.

The same problem was observed for other public sites, including docs.github.com and context7.com, when they resolved to Surge Fake-IP addresses.

Expected behavior / requested improvement

Please provide or document a supported, security-preserving way for web_fetch to work in Fake-IP proxy environments without requiring users to change system-wide DNS behavior.

Potential approaches to evaluate include explicit trusted-proxy integration that safely handles target validation, or a narrowly scoped compatibility mechanism for synthetic DNS mappings. The implementation should continue protecting real loopback, private, link-local, metadata-service destinations, and redirects to unsafe destinations; this is not a request to disable SSRF protection globally.

If an existing setting already supports this setup, please document the exact configuration and whether target-address validation still uses the system resolver.

Current workaround and limitations

Surge supports always-real-ip under [General], allowing selected domains to resolve to real IPs while retaining Enhanced Mode. However:

• Per-domain configuration needs maintenance as the agent visits new public sites.
• always-real-ip = * changes DNS behavior for all domains and loses the benefits of Fake-IP resolution.

CLI help documents proxyUrl / HTTP_PROXY / HTTPS_PROXY and URL permissions, but I could not find a documented Fake-IP compatibility setting. Whether configuring an explicit proxy alone fixes this particular validation failure has not been verified.

Related issues

• web_fetch network failure: Blocks Fake-IP (198.18.x.x) and ignores OS System Proxy app#1867 — same Fake-IP failure reported in Copilot App.
• Allow option to restore web_fetch access to private networks #3731 — request for controlled access to private networks; related target-address restrictions, but this report involves public domains mapped to synthetic proxy addresses.