问题边界
定位污染、超时、分流和浏览器安全 DNS 造成的差异。
机制与操作建议
- 应用可能使用系统 DNS，也可能通过 DoH 自行解析，第一步先确认查询入口。
- 系统查询若进入 Mihomo，本地监听会按 nameserver-policy 或默认服务器选择上游。
- 解析结果进入缓存，并与 fake-ip 或真实地址模式结合。
- 连接阶段再根据规则选择出口，DNS 选择与代理出口并非同一个概念。
可观察指标
- 查询是否出现在 DNS 日志。
- 命中了哪个上游策略。
- 返回地址与实际连接地址是否一致。
边界条件只替换上游 DNS 不能修复所有问题；浏览器绕过、路由失败和规则错误都可能表现为“DNS 坏了”。
知识条目结论
先画出查询路径，再改变其中一段。
萝卜云 · 注册礼注册送 1GB 香港高速流量，24 小时有效；支持支付宝与虚拟币。领取体验流量 →网页打不开时，先确认哪一个名称没有解析成功。浏览器要访问的域名、代理节点的域名和客户端自己的更新地址，可能走不同的解析路径。
把三个名称写清楚
记录实际访问的目标域名、节点服务器域名，以及报错来自哪个操作。不要把订阅更新失败的解析错误，当成浏览器访问目标的同一个故障。日志中的时间与名称要能对应到一次具体请求。
确认请求有没有进入内核
系统或浏览器可能使用自己的 DNS 设置。先检查请求是否进入 Mihomo；若应用根本没有使用当前代理，直接改 nameserver 未必会影响它。TUN、系统代理和浏览器加密 DNS 的关系也需要分别确认。
区分节点域名与目标域名
连接代理节点之前，节点自身的域名可能需要先取得地址。目标域名则可能按配置交给相应解析或出站流程。将代理节点的解析完全依赖一个尚未建立的代理连接，可能造成启动阶段的循环依赖。
检查配置字段时按版本说明逐项看
先核对 dns 是否启用、监听方式、nameserver 和相关策略的适用范围，再检查代理节点解析设置。不要把多个教程中的 fallback、fake-ip、TUN 和过滤项拼成一份配置，却不知道每一项影响哪种请求。
用同一目标验证改动
每次改一项，重新发起同一个请求并看日志。缓存可能让前后结果不同，需要记录是否清理过客户端或应用缓存。恢复可用后，保留有效配置与版本信息，避免下次更新再次丢失对照。
| 问题发生在哪一步 | 先看的证据 |
|---|---|
| 节点还没连上 | 节点域名解析与连接日志 |
| 网页请求没进入客户端 | 应用接管与浏览器设置 |
| 进入客户端后无法解析 | 目标域名、解析策略与错误 |
| 改完短时没有变化 | 应用与内核缓存、是否重新发起请求 |
操作中常见的疑问
- 换成某个公共 DNS 就能解决所有问题吗？
- 不能。解析请求是否到达那里、网络是否可达、具体域名与路由怎样处理，都可能影响结果。
相关文档：Mihomo 配置文档 · Mihomo 配置文档