特殊地址可能是临时标签
在 Fake-IP 类模式下，客户端可以为域名分配一个用于内部映射的地址，后续再根据映射识别目标。这个地址不必就是目标网站在公网中的真实地址。因此，单看解析结果陌生或与另一设备不同，不能立即认定 DNS 出错。应先确认当前配置是否启用了这种机制，以及请求是否由预期客户端处理，再决定观察结果是否符合设计。
映射需要后续连接配合
临时地址有意义的前提，是后续连接能够进入理解该映射的处理路径。如果解析与接管分属不协调的配置，应用可能拿到一个后续环节无法正确使用的地址。排查时把两段放在一起看：是谁回答 DNS，连接又由谁接管。不要只修改解析模式，却不检查实际流量路径；也不要把其他设备的 DNS 设置直接复制过来，期待它自动继承本机映射。
Fake-IP 不替你决定出口
地址映射与规则选择属于不同职责。即使成功使用临时映射，请求最终走直接连接、某个策略组还是具体节点，仍由相应配置决定。看到 Fake-IP 结果，并不能证明任务一定经过代理或特定地区。若路径不符合预期，继续查看规则命中与当前模式。把映射与分流分开，可以避免为一个规则问题反复切换 DNS 模式。
例外设置应对应具体不兼容
有些应用或网络场景可能需要特别处理，但不应仅凭一次异常就把大量域名加入例外。先说明哪项任务、什么错误和哪段路径不符合预期，再核对当前客户端说明。以 mihomo 等实现为例，相关字段有自己的作用与语义，不能从字段名称自行推导所有行为。修改前保存可回退版本，用最小范围验证，避免例外越来越多却失去明确理由。
缓存和映射不是同一个东西
设备或应用可能保留解析结果，客户端也可能维护映射状态。改变模式以后，旧状态可能影响观察，但它们应按各自机制处理，不能统称为清缓存。先确认运行中的配置已经切换，再考虑是否需要按官方方式刷新相关状态。随意删除所有站点数据或重置网络，可能同时影响登录和其他应用，让原本可以定位的问题变得更复杂。
用任务闭环判断是否适用
验证时选择一个能够完整完成的普通任务，记录解析、接管与规则结果，而不是仅比较 IP 字符串。若当前模式满足需要，不必为了让结果看起来像公网地址而更改；若确实存在兼容问题，则依据具体证据寻找替代配置。结论应限定到实际应用与版本，不能宣称某种模式适合所有设备，也不应由它推断速度或隐私方面的全面优势。