切换了nameserver，浏览器中的表现却和之前一样，不一定是Mihomo没有保存配置。查询可能根本没有进入核心，也可能命中了缓存或更具体的解析策略。与其继续替换一串DNS地址，不如从应用发起的一次查询开始，确认每个阶段实际使用了什么。
先画出这次查询的路径
记录应用是否使用系统DNS、是否开启自己的安全DNS，以及系统当前把查询发送给谁。接着确认 dns.enable 已启用、DNS监听地址和端口与预期一致，相关请求确实到达监听。开启TUN与启用DNS模块是两件事；dns-hijack 也只处理其匹配且能够接管的流量。
用同一个域名分别比较系统默认查询与明确指定监听入口的查询，记录所用服务器、记录类型和响应。不要把不同网络、不同缓存状态的两次结果直接比较。关于入口与模式的关系，可先对照Mihomo DNS配置指南确认自己的配置目的。
相似字段，处理不同的解析任务
nameserver 用于一般域名解析；default-nameserver 用于解析DNS服务器自身的域名，不能将它理解为所有业务查询的最高优先级入口。nameserver-policy 则为匹配域名指定解析服务器，优先于一般的nameserver与fallback处理路径。
proxy-server-nameserver 专门解析代理节点域名，direct-nameserver 面向直连出口的域名解析。专用字段为空时的后续行为需要结合当前文档和其他配置；不要把这些字段全部填成同一份列表，再期待它们发挥不同作用。尤其是通过代理访问上游DNS时，要避免节点域名解析又依赖尚未建立的代理连接。
fallback不是简单的故障开关
fallback 与 fallback-filter 共同影响结果采用逻辑，不能简单概括成“第一个DNS不通才使用第二个”。检查域名策略与过滤条件是否改变了预期上游；仅看到nameserver中列出的服务器，并不足以推断最终采用哪个答案。
同时留意A与AAAA记录的区别。DNS模块的IPv6解析选项会影响AAAA响应，但这与系统是否具有可用的IPv6出口不是同一个状态。如果返回的是Fake-IP，应该按虚拟地址映射机制理解，不能拿映射地址和公共解析结果直接判断污染或地理位置。
DoH、DoT与接管范围
DoH通过HTTPS传输DNS消息，DoT使用TLS。传统53端口的DNS接管规则不等于能够改写所有加密DNS。浏览器的独立DoH、Android的私人DNS、局域网DNS以及不同系统上的接管能力，都可能使查询路径与预期不同。
先核对当前程序的设置，再检查上游服务器本身是否可达。TLS握手、证书验证、系统时间与上游网络故障，可能造成不同类型的失败；不要通过跳过证书校验来掩盖原因。缓存检查也应分层进行，尽量先用明确入口的新查询缩小范围，而不是一次清除所有网络状态。
将解析结果与连接结果分开记录
DNS返回答案只说明这次解析完成，不代表TCP、TLS或应用请求成功。把查询时间、记录类型、回答模式和连接错误分别记录；如果查询正常而访问超时，转到连接分层排查继续检查规则和远端服务。一次只变更一个字段，再用相同目标验证，才能知道哪次调整产生了影响。
