[Duplicate of #5202] fake-IP 代理（Surge 增强模式 / Clash、Mihomo）下 web_fetch 恒报 "resolves to a non-public IP address"

[axinhouzilaoyue]

本条与 #5202 重复，后续请在 #5202 跟进。

我在 #5202 下补充了 macOS + Surge（增强模式）的数据点：discussioncomment-18381735。
该线程已包含同类分析、resolver 注入点的核实，以及 #3051（安全边界）/ #4893（CIDR 白名单需求）的关联。
本主题保留仅为搜索可发现性（Discussion 作者无删除权限，需要仓库维护者处理）。

Summary

macOS 上开着增强模式（TUN + fake-IP）的代理时，内置 web_fetch（@deepseek-ai/dsh-web-fetch-http）会把代理分配的 fake-IP 当成真实目的地地址，在发起连接前直接拒绝：

Error: URL hostname "www.themoviedb.org" resolves to a non-public IP address

结果是这类环境下 web_fetch 对任何站点都不可用，而同一台机器上的浏览器 / curl 访问同一 URL 完全正常。

Reproduction

1. macOS + Surge 开启增强模式，系统 DNS 被其接管（scutil --dns 中可见 nameserver[0] : 198.18.0.2、if_index : utun）；Clash / Mihomo 的 enhanced-mode: fake-ip（默认 fake-ip-range: 198.18.0.1/16）同理。
2. 用官方 profile 启动：dsh web（v0.1.5-rc.1，next 通道，也是当前最新）。
3. 让会话调用 web_fetch，目标为任意公网站点，例如 https://www.themoviedb.org/。
4. 必现。

注意：不需要配置 http_proxy / https_proxy。dsh 不读取 macOS 系统代理（见 network-proxy 文档），所以默认就走"自己解析地址"的分支。

Current behavior

系统层面（同机、同一时刻）：

$ dig +short www.themoviedb.org @198.18.0.2
198.18.2.78

$ curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://www.themoviedb.org/
200 198.18.2.78

dsh 里：

URL hostname "www.themoviedb.org" resolves to a non-public IP address   # WEB_BLOCKED_URL

定位在 dsh-web-fetch-http 的 resolvePublicAddresses()：它用 ipaddr.js 要求每个解析结果 range() === 'unicast'，而 198.18.0.0/15 在 ipaddr.js 中是 reserved（RFC 2544 benchmark 段），所以任何 fake-IP 都会命中：

if (!isPublicIpAddress(entry.address)) {
  throw new WebError(`URL hostname "${hostname}" resolves to a non-public IP address`, "WEB_BLOCKED_URL");
}

核心是语义错位：fake-IP 不是真正的目的地地址，而是代理工具用来把连接映射回域名的令牌——本机 TUN 收到发往该地址的连接后，会还原成真实域名再转发。dsh 把它当字面目的地做公网校验，就必然误判。

补充：若配置了 http_proxy / https_proxy，requestOnce() 会走 route.proxied 分支、完全不做本地解析，因此不会报错——但代价是整个 harness 的出站（含 LLM 请求）都改走代理。

Expected behavior

希望为"非公网地址校验"提供显式、可配置的例外，例如：

- id: web-fetch-http
  name: '@deepseek-ai/dsh-web-fetch-http'
  config:
    allowNonPublicCidrs: ['198.18.0.0/15']   # 或 allowFakeIpRange: true

安全边界可以保持不变：只放行配置中列出的网段，loopback / RFC1918 / link-local 等仍拒绝，DNS 全答案校验与连接 pin 逻辑照旧。当前 web-fetch-http 只有 maxResponseBytes / maxBodyChars / timeoutMs / maxRedirects / userAgent 五个配置项，没有任何方式解除 WEB_BLOCKED_URL。

Environment

• dsh: 0.1.5-rc.1（next，当前最新）
• 相关包: @deepseek-ai/dsh-web-fetch-http@0.1.5-rc.1
• 系统: macOS 15.7.7（Darwin 24.6.0, arm64）
• Node: v22.23.2
• 代理: Surge 增强模式（fake-IP 池 198.18.0.0/15），未设置 http_proxy / https_proxy

附：现有变通手段的代价

1. 在 Surge 中给每个域名加 always-real-ip：需要逐个域名维护，且会让 Surge 丢掉该域名的 fake-IP→域名映射（always-real-ip = * 会破坏 DOMAIN 规则匹配，官方文档亦不推荐）。
2. 给 dsh 配 https_proxy：全部出站改走代理端口，SSRF 校验在代理分支被整体跳过，代理一关 dsh 即断网。
3. 社区已有第三方插件在做可配置白名单（dsh-web-fetch-enhanced），说明需求真实存在；不过由上游提供配置项，或至少在文档中标注"与 fake-IP 模式代理不兼容"，会更合适。