[Duplicate of #5202] web_fetch 在 Clash fake-ip 环境下对所有域名失败，且报错无法自诊

[Agzer0]

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

提交时我只检索了 Issues（该仓库已禁用），未检索 Discussions，因此漏判了重复，抱歉。
我的两点增量（ipaddr.js 1.9.1/2.5.0 分类相反、~/.dsh/.env 逃生路径实测）已补充到 #5202。
本主题保留仅为搜索可发现性（Discussion 作者无删除权限，需要仓库维护者处理）。

---

Summary

开启 Clash/Mihomo 类代理客户端的 fake-ip 模式（TUN + enhanced-mode: fake-ip，即 Clash 系默认配置）后，web_fetch 对所有域名一律失败：

Error: URL hostname "damodev.csdn.net" resolves to a non-public IP address

失败率 100%，与目标域名、域名归属地、站点实际可达性均无关。报错文本没有任何线索指向 DNS 已被代理接管，用户难以自诊——本次排查先后怀疑过网络故障、代理未生效、目标站点被墙，数轮之后才定位到根因。

需要先说明：network.ts 的公网地址校验是有意且正确的安全设计，本报告不建议放宽它。 问题在于 fake-ip 是 Clash 系的默认配置，命中后既没有可诊断的报错，也没有文档化的出口。

Reproduction

环境：macOS + Clash Verge Rev，TUN 模式（tun.enable: true + dns-hijack: any:53），enhanced-mode: fake-ip，fake-ip-range: 198.18.0.1/16。

不依赖具体客户端：任何使 DNS 应答落在 RFC 2544 保留段 198.18.0.0/15 的配置都能复现。

1. 打开 VPN，确认 DNS 已被接管：

$ dig +short damodev.csdn.net
198.18.0.77

2. 调用 web_fetch 抓任意 URL：

web_fetch("https://damodev.csdn.net/")

3. 必然失败：

Error: URL hostname "damodev.csdn.net" resolves to a non-public IP address

对照实验（同一会话、同一时刻、同一条网络）

工具	目标	结果
web_search	"google"	正常返回结果
web_fetch	https://damodev.csdn.net/	resolves to a non-public IP address
web_fetch	https://www.google.com/	同上
web_fetch	https://www.baidu.com/	同上
web_fetch（关闭 VPN 后）	https://damodev.csdn.net/	HTTP 200

www.baidu.com 同样失败，可排除"墙"或域名归属地的解释；web_search 成功，可排除网络故障。

Current behavior

packages/web/web-fetch-http/src/network.ts 在建立连接之前解析域名并逐个校验应答：

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

isPublicIpAddress() 用 ipaddr.js 的 range() 判定，要求结果等于 'unicast'。fake-ip 分配的地址落在 198.18.0.0/15：

198.18.0.77  => range: reserved   -> 判为非公网，拒绝
1.2.3.4      => range: unicast    -> 放行

于是校验在发包前就拒绝，TUN 无从接管——一个数据包都没有发出。

版本敏感点：仓库 .pnpm 下同时存在 ipaddr.js@1.9.1 与 2.5.0，两者对该段的分类不同——1.9.1 判为 unicast（放行），2.5.0 判为 reserved（拒绝）。web-fetch-http 声明 ^2.5.0，故当前行为是拒绝。也就是说该行为随依赖升级而变，建议用测试固定。

为什么 web_search 不受影响

web-search-deepseek/src/provider.ts:225 用原生 fetch 直接发请求，全程不检查解析结果，198.18.x.x 对它只是透明标签（实测其 api.deepseek.com 同样解析到 198.18.3.5，工作正常）。全仓 resolvePublicAddresses 仅被 web-fetch-http 使用。

同理，Claude Code、Codex、curl、浏览器等不做 IP 校验的工具在同一环境下均正常——这是 DSH 独有的失败模式。

Expected behavior

不改变安全不变量，只补上可诊断性与出口：

1. 错误信息识别 fake-ip 段。当被拒地址落在 198.18.0.0/15 时，在报错中说明这通常是代理 fake-ip 模式所致，并给出可操作提示：切换 Clash 的 enhanced-mode 为 redir-host，或设置 HTTPS_PROXY 走代理分支。
2. 文档记录该限制。packages/web/web-fetch-http/README.md 目前未提及此环境下的失败模式。

已存在但未文档化的逃生通道：设置 HTTPS_PROXY 后，provider.ts:134 的 proxyRouteFor(url) 会判定为 proxied，走 requestVia 跳过本机解析与 pinning，由代理完成真实解析。本次经 ~/.dsh/.env 配置 HTTPS_PROXY=http://127.0.0.1:7897 后实测有效：同一 URL 返回 HTTP 200，https://www.google.com/ 返回 HTTP 302。

Environment

• 仓库：deepseek-ai/deepseek-harness @ master
• 平台：macOS (darwin)，Node v24.3.0
• 相关包：@deepseek-ai/dsh-web-fetch-http，依赖 ipaddr.js@2.5.0
• 代理客户端：Clash Verge Rev，TUN 模式，enhanced-mode: fake-ip，fake-ip-range: 198.18.0.1/16，mixed-port: 7897