Fake-IP 模式下，应用拿到的是客户端分配的映射地址，客户端再通过映射识别原始域名。切换配置或重启后，如果应用保留旧地址而映射已经改变，就可能出现网页打不开、连接指向未知目标等现象。恢复时应处理相关缓存和连接，不必立即重装客户端。
先判断是否真的涉及映射
Fake-IP 不是目标网站的真实地址，也不是一个对所有网络都有效的公网入口。它用于客户端内部关联域名与连接。应用拿着该地址发起连接时，流量必须进入理解这份映射的客户端，否则其他设备并不知道该地址对应什么业务。
核验当前配置确实启用了这一模式，并确认异常应用的解析请求是否由相应客户端处理。如果应用使用自己的解析服务，拿到的可能是真实地址，那么问题就不能仅凭“开着 Fake-IP”来解释。连接日志中的目标信息与解析日志需要对应同一时间。
典型线索是问题紧接着配置切换、内核重启、缓存清理或接管方式变更出现，并且关闭再打开应用后改善。但这些都只是线索，不能独立证明原因。重启同时影响连接池、代理设置和网络接口，因此需要保留更细的时间记录。
缓存可能分布在多个地方
应用自己的连接池、应用解析缓存、系统解析缓存以及客户端映射各自有生命周期。刷新网页可能继续复用已有连接；关闭一个标签页也未必结束浏览器后台进程。只清理其中一层，有时会让另外几层继续使用旧状态。
示例情境中，浏览器记住某业务的映射地址，客户端切换到另一份配置并重新分配映射。浏览器随后请求旧地址，客户端却找不到对应域名。此时增加域名代理规则未必有用，因为识别域名的步骤已经失败。应先使查询、映射与新连接重新同步。
不同内核对映射持久化、缓存保存和重载处理的支持会变化。应查阅当前版本文档，不要从另一客户端复制所谓万能缓存选项。能持久化映射也不等于任何模式切换都安全，尤其是地址范围和解析架构同时发生变化时。
按最小范围恢复
先暂停受影响应用的操作，保存尚未提交的内容，记录当前配置名称和异常时间。确认客户端解析服务正常运行，再关闭该应用的相关连接，按系统与应用提供的方法刷新相关解析缓存，最后重新发起查询与连接。尽量不要一开始就清空整个家庭网络的状态。
恢复顺序的目的，是避免应用在客户端尚未就绪时再次取得不适用的结果。完成后观察新查询是否出现、客户端是否建立映射、连接是否进入正确入站。如果仍失败，记录失败在哪一步，而不是连续执行多种清理操作后只留下“好像好了”的印象。
客户端提供缓存操作界面时，先区分清理普通解析缓存与清理映射的影响。不要为了修复一个网站删除整个配置目录，其中可能保存订阅、证书和本地规则。需要更深入的清理时，先备份并确认恢复方法。
兼容性问题需要有限例外
部分应用会把地址作为业务数据使用，或者绕过预期入口连接，这可能与映射模式产生兼容性问题。发现疑似情况时，先用真实解析模式对同一业务做一次受控对照。若只有该模式能工作，再查应用要求及客户端过滤机制，而不是永久关闭全部分流。
例外应从精确目标开始，并记录为什么需要返回真实地址。范围过大的例外会改变大量业务的解析与路由行为，后续遇到另一个问题就更难定位。不要把失败过的所有域名不断追加，应该先确认失败与映射确实相关。
局域网发现和设备访问还可能依赖本地名称解析机制。打印机名字打不开，不代表公共网站的映射机制有故障。测试设备真实管理地址能否访问、名称由谁解析，再决定在哪一层处理。不要把局域网设备名交给不认识它的外部解析服务。
让下一次切换可预测
配置变更前列出是否修改映射地址范围、解析上游、入站接管方式和持久化设置。一次只改一个关键因素，并安排短暂的业务中断窗口。对于长期运行的下载器或工作应用，提前说明需要重新建立连接，避免误认为服务端发生故障。
保存恢复结果时，写明具体动作和作用对象，例如“关闭浏览器进程后重新解析恢复”，而不是“清缓存解决”。这种记录能在复发时减少操作，也能帮助维护者判断是否需要修复重载流程。
进一步排查可结合解析出口解释检查查询来源，用TUN 环路检查确认映射连接进入正确通道。先让映射状态一致，再处理规则与出口，能避免在错误层面反复修改。
如果只有另一台设备异常，还要确认它是否把当前机器当作解析服务器，却没有把业务流量交给相同代理。跨设备使用映射要求解析和连接的处理关系一致，单纯把本机的解析地址填写到全家设备上，并不能自动完成这种配合。
参考资料
- mihomo DNS 配置与映射相关选项，核验日期：2026-10-15。具体字段以运行版本文档为准。