2026 年 9 月 14 日发布的 Mihomo v1.19.31，修复了 tsnet 模式下、上游 DNS 是 tailnet 节点时，Split DNS 的 UDP 查询静默失败问题。如果你使用 Mihomo 内置 Tailscale 出站，遇到特定内部域名解析超时，这项更新值得核对。官方 v1.19.31 发布说明明确列出了触发条件，但没有给出完整的受影响旧版本范围。
针对 Mihomo Tailscale DNS 解析失败，合理顺序是先确认查询确实经过这条路径，再备份配置、通过官方渠道更新内核，并以相同域名复测。本文的升级与排查建议适用于自己管理或获准访问的网络；仅使用独立 Tailscale 客户端，或普通公网 DNS 查询失败，不能据此判定命中同一缺陷。
先判断：你的故障是否符合这次修复
- 实际运行的是 Mihomo，且相关访问使用内置的 Tailscale 出站。
- 查询走 tsnet 的分域 DNS 路径，上游 DNS 服务由 tailnet 中的节点提供。
- 失败涉及 UDP DNS 查询，而不只是网页打开慢、证书报错或服务端拒绝连接。
- 升级前后保留同一测试对象和配置，避免同时更换上游而无法判断原因。
这些条件来自发布说明对修复范围的描述，不是自动诊断规则。尤其是“内部域名打不开”只能作为线索：它可能发生在解析、路由、服务监听或访问授权的不同环节。官方没有宣称所有 DNS 超时都由这项缺陷造成，也没有宣布所有旧版均受影响。
编辑建议：如果前三项都符合，优先安排一次可回退的内核升级验证；如果连使用哪一个解析器都不清楚，先确认路径。此前版本的其他变更可以参考站内的Mihomo v1.19.30 更新核验指南，不要将不同版本的修复条件混在一起。
分域 DNS、MagicDNS 与代理规则不是同一层
Tailscale 官方把只负责特定域名查询的解析服务器称为 restricted nameserver，这就是 Split DNS。例如，管理员可以让一个内部域名后缀交给内部解析器处理。MagicDNS 则为 tailnet 设备提供名称；官方说明它不能任意添加自定义记录。两者功能不同，不能因为设备名称能解析，就推断所有业务域名也能解析。参见Tailscale 的 DNS 与分域解析文档。
Mihomo 官方文档还说明，Tailscale 在这里是一个可选出站，只有被规则、策略组等方式选中的流量才会使用它。因此，配置里出现 type: tailscale，并不等于当前测试已经进入该出站。核验时应查看实际连接与规则命中情况，而不能只看配置文件中有没有这一段。依据是Mihomo Tailscale 出站说明。
这也是为什么不建议一开始就把内部域名改交给公共解析器：你会改变原本想验证的解析路径。需要补齐基础概念时，可先阅读远程办公 VPN 的 Split DNS 与内网访问边界；涉及其他客户端的 DNS 方案时，再参考Fake DNS、远程 DNS 与 DoH 的区别。
升级前记录什么，升级后验证什么
第一步：保留能够比较的故障记录
以下是编辑建议的核验清单，并非官方提供的自动修复流程。记录当前内核版本、操作系统、客户端名称、失败域名的完整名称、查询时间，以及预期使用的内部 DNS。选择管理员确认存在的记录作为测试对象，另选一个正常域名作对照。对外反馈时隐去账号、登录密钥和敏感业务域名。
把“没有收到回答”“收到域名不存在的回答”“收到地址但业务连接失败”分别记录。它们需要不同的后续检查，不应统一写成“DNS 坏了”。如果管理员能够查看内部 DNS 日志，可同步核对同一时间是否收到查询、是否生成响应；这些记录有助于缩小范围，但单独一条日志不足以证明内核缺陷。
第二步：确认真正替换了运行中的内核
保留现有配置及可用的回退版本，再从Mihomo v1.19.31 官方发布页选择适合系统与处理器的构建。使用图形客户端时，应遵循该客户端的内核更新方式；这里核验的是 Mihomo 修复，不能由界面软件的版本号推断内核已更新，也不能推断所有客户端都已提供这一个版本。
完成更新并重新启动相关服务后，查看当前运行实例报告的内核版本。不要只根据下载文件名或更新按钮的完成提示下结论。如果客户端尚未支持相应内核，先保留现状与故障记录，等待其正式更新路径，不要随意替换来源不明的二进制文件。
第三步：沿原路径复测，再检查业务连接
保持域名、上游和规则一致，重新发起原来失败的查询，并记录响应、时间和命中路径。若改为直接向上游发送测试查询，应注明这是“上游对照”，它不能单独验证 tsnet 内部转发是否恢复。测试工具与浏览器是否走同一路径也需要单独确认，不同平台不能只凭一条命令的结果互相替代。
确认解析结果符合管理员预期后，再访问原业务服务。解析恢复只说明这一阶段取得进展；若地址已经返回而服务仍无法访问，就继续检查业务端口、路由与授权。建议验收记录同时包含内核版本、解析结果、实际使用的出站以及业务访问结果，便于之后回溯。
更新后仍失败，按条件继续缩小范围
先确认不是初始化阶段。Mihomo 官方文档说明，出站在首次匹配连接时才开始连接，第一次访问 Tailscale 节点可能超时；应等待加载并重试，避免把首次连接现象直接认定为持续故障。同一文档还指出 udp 默认值为 false。如业务需要 UDP，应核对实际配置，但不能据此推断开启这个选项就能替代 tsnet DNS 缺陷的修复。参见Tailscale 出站的初始化和 UDP 选项。
如果配置使用了出口节点，还要核对 DNS 策略。Tailscale 官方文档描述了出口节点会影响所用解析器，以及 nameserver 的 Use with exit node 选项。这里应把它作为检查线索：该文档描述的是 Tailscale 行为，不能未经核验就承诺每个 Mihomo 客户端界面有相同开关。应结合自己的部署与实际查询记录判断。
仍无法定位时，向维护者提供最小化、脱敏的复现信息：运行版本、是否内置 Tailscale 出站、是否使用出口节点、上游是否为 tailnet 节点，以及升级前后同一查询的差异。不要用“换了节点就好了”代替路径说明，也不要为排错扩大原有访问权限。
常见问题
只安装独立 Tailscale 客户端，需要升级 Mihomo 吗？
不能仅根据这项修复决定。v1.19.31 的条目限定了 tsnet 分域 UDP 查询和 tailnet 上游条件。若没有使用 Mihomo 的相关路径，应先查独立客户端及其 DNS 设置，而不是把 Mihomo 的修复说明套到另一个运行实例。
MagicDNS 能用，内部业务域名仍失败，矛盾吗？
不矛盾。设备命名与自定义域名的分域解析承担不同任务。根据 Tailscale 官方文档，MagicDNS 不支持随意添加记录；应检查业务域名实际由哪个 nameserver 负责，而不只测试设备名称。
更新图形客户端后，是否就能确认问题已修复？
不能。先确认实际运行内核包含该修复，再沿原故障路径复测。官方发布页证明 v1.19.31 列入了修复，但不能证明某个第三方客户端已经集成，也不能证明你的本地故障只有这一个原因。
这次修复是否意味着此前内部 DNS 查询泄露了？
不能这样推断。官方条目描述的是特定路径的查询失败，没有据此报告 DNS 泄露。超时、错误回答与泄露是不同问题；若怀疑查询走了非预期解析器，应另行核对实际流向，不应把超时本身当作泄露证据。
官方来源与核验入口
- MetaCubeX / Mihomo：v1.19.31，发布日期 2026-09-14；查看版本变更、修复条件与官方构建。
- MetaCubeX：Tailscale，页面标注日期 2026-05-22，核验日期 2026-09-19；查看 Mihomo Tailscale 出站配置与初始化说明。
- Tailscale：DNS in Tailscale，核验日期 2026-09-19（本次未确认页面更新日期）；查看分域解析、MagicDNS 与出口节点 DNS 规则。
关于作者
