启用代理后部分网站打不开？排查 Fake-IP 与 DNS 兼容性

先确定失败发生在哪一步

“打不开”不是一个足够具体的结论。先在原来的程序里重现一次，记下时间、正在做的动作和完整错误。不要同时换线路、换 DNS、开关 TUN，再凭最后一次成功判断原因。你需要的是一组能说明变化的对照，而不是一次碰巧恢复。

先打开分流检测留下一份浏览器的基线：国内、海外、谷歌三栏分别是否成功，出口是否符合你的预期。如果首页本身有失败，先处理对应线路；如果首页正常，就把排查范围收回那个网站或程序。不要为了让一个程序工作，直接把全局配置改成另一套。

解析方式与连接出口分开看

以 Mihomo 为例，dns.enhanced-mode 可以选择 fake-ip 或 redir-host。在 Fake-IP 模式下，客户端会使用域名与虚拟地址之间的映射处理连接。你看到一个解析地址时，还要结合当前解析模式判断，不能只按地址看起来是否陌生来判断故障，更不能把它当成网站真实出口。

fake-ip-filter 用来为符合条件的域名改变是否返回 Fake-IP 映射。路由规则里的 DIRECT 或某个代理组，则是在决定连接交给谁。给域名添加 Fake-IP 例外，不等于强制这个域名直连；把路由改成直连，也不等于已经检验过它的解析兼容性。这两个方向要分别留证据。

如果你真正担心的是解析请求经过了不希望使用的服务器，继续看DNS 泄露四步排查。本文处理的是部分访问异常，不把“能访问”当作“没有泄露”，也不把 DNS 检测结果当作某个桌面软件的兼容性证明。

留下能对照的原始记录

1. 保存当前实际使用的配置副本，并记下客户端名称、内核版本、当前配置名称和模式。不要只保存订阅源而漏掉你已经加过的本地覆盖。
2. 在原程序里执行一次最小操作，例如只打开一个页面或只重试一次登录，记录时间和错误。先不要同时启动下载、更新和其他测试。
3. 到客户端连接记录或日志里查对应时间的目标域名、目标地址、匹配规则和出口。如果界面没有显示某项，就明确写“未取得”，不要补猜。
4. 确认你准备修改的是运行中的配置。客户端若通过覆写或合并机制生成最终配置，要检查最终效果；修改另一个未激活的文件，不能算完成对照。

不同客户端界面名称和可见字段可能不同，本文不规定统一菜单路径。也不要把整个配置、订阅地址或带认证信息的日志发到公开地方。排查记录只需保留与本次请求有关的字段；如果必须请人协助，先去掉凭据和不相关的个人信息。

确认目标请求用了哪条解析路径

单独打开一个查询工具取得的结果，不一定来自失败程序实际使用的路径。先确认客户端的 DNS 功能是否启用、程序是否把连接交给当前客户端，再看客户端是否确实记录到对应域名。没有找到记录时，先将结论写成“路径未确认”，不要直接认定某一种模式坏了。

Mihomo 的 nameserver-policy 可以为特定域名指定上游解析服务器，优先于 nameserver 与 fallback 的对应查询选择。因此“我只配置了一个默认 DNS”未必足以解释实际请求。你若已经使用这些规则，应把命中的域名策略一起记下来；本次不要顺手替换所有上游。

如果原程序根本没有出现在客户端连接记录中，转到TUN 流量接管排查，先查流量是否进入客户端。如果已经进入，却被某条规则送到错误出口，先按规则模式说明核对路由。只有在路径、目标和出口都基本确认后，解析模式的单项对照才有解释价值。

只给必要域名添加例外

下面是 Mihomo 配置的局部示意，只演示你已经在使用 Fake-IP，并且原有过滤模式为 blacklist 时，如何增加一个精确域名。login.example.com 是文档示例，不是要你实际访问的服务。请替换为日志里已经确认的目标，并保留原配置的其他字段和条目。

dns:
  enhanced-mode: fake-ip
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    # 保留原有条目，再添加需要对照的精确域名
    - 'login.example.com'

这个片段不是完整配置，也不是让你在文件末尾再加第二个 dns。应当在现有结构里合并，并用客户端自己的配置校验功能确认能加载。若现有模式是 whitelist 或 rule，不要照搬：它们的匹配含义或写法不同，切换模式还可能改变原有条目的含义。先按所用内核版本的说明处理，再做同样的单域名对照。

先从一个有证据的精确域名开始。页面可能还需要其他请求，若只恢复一部分功能，就继续找失败请求对应的域名；不要直接扩大到所有域名。也不要把整个 Fake-IP 例外列表删掉重建，否则你同时引入的新变化太多，无法分清是哪一项带来改善。

回到原程序验证与回退

保存并加载后，确认没有配置错误，再结束本次用于对照的旧连接，让原程序重新发起请求。若客户端提供 DNS 或 Fake-IP 缓存清理功能，先确认它的作用范围，再决定是否使用。清理会让后续请求重新建立状态，不应在没有记录的情况下反复执行，更不需要为一个域名盲目重置整台设备的网络。

1. 回到原程序，重复相同动作，记录成功或失败，以及实际域名、规则和出口。单次恢复只能支持这一次对照，不能证明所有网站都兼容。
2. 再跑一次首页三条线路，确认国内、海外和谷歌的走向仍符合预期。首页失败或结果未知时，就保留失败或未知，不能记作分流已经正常。
3. 如果仍然失败，恢复这次新增的域名例外，重新加载配置，保留前后记录。接着按日志提示排查连接、规则或应用本身，不继续无依据扩大过滤范围。
4. 如果相同操作稳定恢复，保留最小例外和修改理由；以后升级内核或调整上游时，再用同样操作复核，不把临时方案当成永久原因结论。

一份能用的排查结果，应当说清哪个程序、哪个域名、哪份配置发生了什么变化，以及原操作是否恢复。只写“换 DNS 好了”很难在下次复发时继续定位。把这几个要点留在自己的记录里，比一次修改很多开关更容易维护。