客户端指南

Mihomo 配置里四种 nameserver 有什么区别？节点域名为什么会卡住

网页域名、DNS 上游域名、代理节点域名与直连请求可能走不同解析路径。读懂 default-nameserver、nameserver、proxy-server-nameserver 和 direct-nameserver，避免改 DNS 后客户端无法连接。

发布于 2026/8/19 · 更新于 2026/8/19 · 3 项可核验来源

先看重点nameserver 处理常规域名；default-nameserver 用来解析 DNS 上游自己的域名；proxy-server-nameserver 专门解析代理节点主机名；direct-nameserver 服务直连出口。节点地址本身是域名时，如果解析它又依赖尚未连上的代理，就会形成循环依赖。不要把四项当成同义词批量覆盖。

订阅导入后原本能用，你照着一份“优化 DNS”配置改了几个 nameserver，客户端仍能启动，节点却全部超时；换回旧配置又恢复。此时不一定是机场故障，也不能只用“DNS 能不能解析网页”来判断。

Mihomo 的几组 nameserver 不是同一选项的四种写法。 它们分别处理普通目标域名、DNS 上游自己的域名、代理节点主机名和直连出口。最容易卡住的场景，是“必须先解析节点才能建立代理，但解析节点又被要求走这条尚未建立的代理”。

四组名字相似，工作对象不同

配置项	主要解析对象	最容易误解的地方
`nameserver`	普通域名查询的默认上游	命中 policy 的查询不一定交给它
`default-nameserver`	DNS 上游地址里出现的域名	不是所有查询的“默认 DNS”
`proxy-server-nameserver`	代理节点服务器的主机名	留空时才跟随 `nameserver-policy`、`nameserver` 和 `fallback`
`direct-nameserver`	最终从 `DIRECT` 出口访问的域名	留空时才跟随 `nameserver-policy`、`nameserver` 和 `fallback`

Mihomo 官方文档把 nameserver 定义为默认域名解析服务器；nameserver-policy 命中时优先于 nameserver 与 fallback。因此，看到配置里写了一个 nameserver，不代表每个域名一定都交给它。

default-nameserver 的名字尤其容易误导。它不是“所有查询默认使用的 DNS”，而是给 DNS 上游自己的域名做引导解析。假设某个 DoH 上游写成域名，内核得先知道这个域名的 IP，才能向它发送后续查询。

proxy-server-nameserver 只关心代理节点地址。订阅里的服务器若已经写成 IP，这一层不需要解析该节点；写成域名时，它才直接影响内核能否找到节点服务器。

direct-nameserver 则与直连出口有关。官方解析流程显示，域名或解析出的 IP 命中 DIRECT，且配置了这一项时，Mihomo 会为直连连接重新解析。它不是“备用 DNS”，也不会自动替代节点域名解析。

为什么普通网页能解析，节点仍可能连不上

网页域名和节点域名是两个对象。浏览器查询 example.com 能得到结果，只能说明普通查询路径在当时可用，不能证明订阅里的 node.example 也走到了合适的解析器。

循环依赖通常长这样：节点服务器使用域名；DNS 查询按路由规则要求走代理；代理尚未建立，因为内核还不知道节点域名对应的 IP。Mihomo 官方 DNS 文档因此要求在 respect-rules 开启时配置 proxy-server-nameserver，并明确提醒，通过代理查询 DNS 时要避免这种“鸡与蛋”问题。

这也解释了几种看似矛盾的现象：

配置文件能载入，但所有使用域名的节点连接失败；
同一配置里，服务器写成 IP 的节点可用，写成域名的节点失败；
只替换 DNS 区块后出问题，恢复订阅原始配置便正常；
日志先出现节点域名解析错误，随后才出现连接超时。

这些现象只能缩小排查范围，不能单独证明是哪一个字段写错。NXDOMAIN、SERVFAIL 和纯超时的含义也不同，可以对照DNS 报错区别继续判断。

不要把四项全部填成同一组公共 DNS

把所有字段复制成相同地址，看起来统一，实际会抹掉原配置对启动解析、节点解析和直连解析的分工。某个公共 DNS 本身可访问，也不代表它适合每一条出口、每一种网络和当前规则。

更稳妥的判断是看“谁需要被解析、解析请求从哪条路径发出”。订阅原始配置能够稳定工作时，没有必要只因为网上模板字段更多就覆盖它。问题恰好在修改 DNS 后出现，优先恢复上一份可用配置，比继续叠加 fallback、nameserver-policy 和 respect-rules 更容易确认因果。

客户端界面还可能用覆写、Merge 或 Script 生成运行时配置。你编辑的原始 YAML 与内核真正加载的内容未必相同；如果字段对不上，应查看客户端导出的运行时配置，而不是假定订阅文件就是最终结果。陌生配置能改变的范围，可参考订阅 YAML 与客户端 Script 的区别。

怎样判断问题确实落在 DNS 这一层

节点域名解析成功，只代表内核拿到了候选地址；节点端口、TLS、协议参数和网络路径仍可能让连接失败。反过来，客户端显示“节点超时”也可能是连接阶段的问题，并不自动等于 DNS 故障。

较可靠的边界是同时满足这些信息：日志明确指向节点主机名解析；故障随 DNS 区块变化稳定出现和消失；服务器为 IP 的对照节点不受影响。缺少这组对照时，不要删订阅、关闭证书校验，也不要把系统、浏览器和 Mihomo 的 DNS 一次全改掉。

如果担心解析是否离开预期路径，先明确自己的边界，再看DNS 泄漏的判断方法。检测页出现多个解析器，不足以反推出某个 nameserver 字段写错。

四组字段里，没有一项是“越多越保险”。能说明每个域名为什么交给这条解析路径，配置才算清楚；说明不了时，保留服务商或客户端生成的可用配置，通常比拼接陌生模板更安全。

资料来源

以下来源于 2026/8/19 复核。版本、支持平台和发布状态以后续官方页面为准。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题