最近排查 AI 工具联网失败时，我遇到过一种很容易走错方向的现象：访问的是正常公网域名，OAuth、下载或网页读取工具却提示目标地址不安全，甚至直接按照 SSRF 风险拦截。
进一步检查后发现，域名被本地代理的 Fake-IP 模式解析到了 198.18.x.x。这不是目标网站的真实公网地址，而是代理为了接管连接临时返回的映射地址。
问题的本质不是“网站有毒”，也不是“安全工具太保守”，而是代理 DNS 语义与服务端安全校验发生了冲突。
证据说明：Fake-IP 与特殊地址的定义来自 Mihomo、IANA 和 OWASP 公开资料；排障顺序与最小例外策略来自个人实践。不同代理版本和网络结构可能存在差异。
Fake-IP 做了什么
在 Fake-IP 模式下，代理 DNS 不一定把域名的真实公网 IP 直接交给应用，而是返回一个保留网段中的临时地址。应用连接这个地址后，代理再根据映射关系识别原始域名并转发流量。
Mihomo 官方 DNS 文档的示例配置使用 enhanced-mode: fake-ip，示例网段为 198.18.0.1/16；文档同时提供 fake-ip-filter，让指定域名不再获得 Fake-IP 映射。[1]
dns:
enhanced-mode: fake-ip
fake-ip-filter:
- 'auth.example.com'上面只是结构示例，真实配置应使用实际受影响且已经核验的最小域名范围，不能把所有域名一股脑加入过滤列表。
为什么 SSRF 防护会拦截它
IANA 将 198.18.0.0/15 登记为网络设备基准测试使用的特殊地址空间，并标记为非全球可路由。[2] 对一个负责抓取任意 URL 的服务来说，解析结果落入特殊地址、私网、回环或链路本地网段，本来就应该保持警惕。
这是因为 SSRF（服务端请求伪造）可能诱导服务器访问内网管理接口、云元数据服务或其他不应暴露的目标。OWASP 建议校验解析后的 IP、重定向链和 DNS 变化，并在条件允许时采用允许列表，而不是只检查 URL 字符串。[3]
因此，看到 SSRF 拦截时，最危险的处理不是修 DNS，而是直接关闭安全校验或允许所有特殊地址。那会把一次兼容性问题变成真实安全缺口。
如何确认是不是 Fake-IP 冲突
我会按以下顺序排查：
- 记录失败域名和工具返回的解析地址；
- 判断该地址是否属于 IANA 特殊用途网段；
- 比较本机系统 DNS、代理 DNS 和可信外部解析结果；
- 确认相同域名在普通浏览器中是否由代理正常接管；
- 检查代理是否启用了 Fake-IP，以及该域名是否命中过滤规则；
- 修改后重新解析并验证工具访问，不只看配置保存成功。
如果公网域名在代理 DNS 下落入 198.18.x.x，而在可信外部 DNS 中得到正常公网地址，并且失败工具明确拒绝特殊地址，那么基本可以把问题缩小到 Fake-IP 与安全校验的兼容边界。
正确修复：保留安全，只做最小例外
我的处理原则是：
- 不全局放宽 SSRF 检查；
- 不把整个顶级域或大范围通配符排除在 Fake-IP 外；
- 只为确实需要真实解析的具体认证、下载或 API 域名添加过滤；
- 修改前保存活动配置，修改后使用受支持的重载方式；
- 同时验证原故障恢复和其他代理流量没有回归。
有些代理环境重启会造成全网短暂中断。若软件支持无中断重载，应优先使用；如果不能确认，就把重启放进单独维护窗口，而不是为了验证一条 DNS 规则直接影响所有设备。
最容易犯的三个错误
1. 把特殊地址当成目标网站真实 IP
Fake-IP 只是本地映射。拿它做地理位置、归属或网站安全判断，结论都会错。
2. 关闭 SSRF 保护证明“工具能用”
这只能证明防线被拆掉，不能证明问题被正确修复。
3. 为了省事加入过大的过滤范围
过滤规则越宽，越可能改变原有分流、DNS 防污染和代理接管行为。最小域名例外虽然需要多一点核验，但更容易回滚，也更不容易制造新的网络问题。
结语
这类故障最有价值的经验，是不要在“网络能通”和“安全校验正确”之间二选一。好的修复应该同时满足两点：目标域名得到安全工具能够理解的真实解析，SSRF 防护继续拒绝真正的私网和特殊地址访问。
当 AI 工具、OAuth 或下载服务突然提示特殊地址时，先检查 DNS 和 Fake-IP，再决定是否调整应用。不要从拆掉安全门开始。
参考资料
- Mihomo 官方文档：DNS 与 Fake-IP 配置
- IANA：IPv4 Special-Purpose Address Space
- OWASP：SSRF Prevention Cheat Sheet
