Mihomo DNS 解析失败怎么排查？从日志到 TUN 的分层步骤

更新于 2026-11-11 · cloudfisher.site

简答：Mihomo DNS 解析失败时，先看日志中失败的具体域名，再判断它是订阅地址、节点 server 还是目标网站；随后暂时关闭 TUN 和复杂 DNS 规则，用一个节点、一个测试域名做最小化复测。Windows 可用 nslookup，macOS/Linux 可用 dig，但命令行成功不等于 Mihomo 内部路径一定正常，最终要结合 Mihomo 日志和代理复测结果判断。

定义：Mihomo DNS 解析失败，是指 Mihomo 在为订阅地址、代理节点或目标域名获取 IP 时没有得到可用结果，原因可能位于本机 DNS、Mihomo DNS 配置、节点域名解析、TUN 接管或应用自身的 DNS 路径。

先试这一步：确认到底是谁解析失败

先不要改一堆 DNS，也不要立即更换节点。打开 Mihomo 的运行日志，记录报错附近出现的完整域名和错误关键词；域名不要直接发布到公共检测站，订阅地址、UUID、令牌和个人路径也应打码。

日志中看到的对象	优先判断	第一步动作	成功判据
订阅 URL 或配置下载域名	订阅地址、本机网络或系统 DNS	先在浏览器或命令行测试该域名，再检查订阅链接是否仍有效	订阅地址能解析并返回预期内容，且 Mihomo 能重新获取配置
代理节点的 server 域名	节点域名解析路径或 DNS 环路	优先检查 `proxy-server-nameserver`，再测试同一域名	节点域名可解析，Mihomo 能进入连接或握手阶段
目标网站域名	`nameserver`、策略分流、Fake-IP 或目标站本身	关闭复杂规则后用一个测试域名复测	日志不再出现解析失败，浏览器可打开测试页面
只有浏览器失败	浏览器独立 Secure DNS 或缓存	临时检查浏览器的安全 DNS 设置	关闭或改回自动后，浏览器与其他应用表现一致

“dns resolve failed”“no such host”“couldn't find ip”只能作为定位线索，不能单独证明是哪一个配置字段出错；应把失败域名、发生时间、当前是否启用 TUN 和复测结果一起记录。

本文是中立使用指南，站点不是 CloudFisher 渔云官方页面；涉及该服务的订阅或节点信息，应以其当前页面为准，本文不对其状态、价格或可用性作判断。

按四层检查 Mihomo DNS 配置

截至 2026-11-11，Mihomo 文档将这些字段分工得比较清楚：default-nameserver 用于解析 DNS 服务器自身的域名；nameserver 是普通域名的主要解析服务器；proxy-server-nameserver 专门用于解析代理节点的域名；direct-nameserver 用于直连出口的域名解析。不要把四者当成同一个“DNS 地址”字段。详见 Mihomo DNS 配置文档。

先看 DNS 是否启用：如果 dns.enable 为 false，Mihomo 会使用系统 DNS。若你原本依赖 Mihomo 内置 DNS，关闭它可能改变实际解析路径。
再看普通域名：检查 nameserver 是否为空、格式是否正确，以及 DoH、DoT 或 UDP 地址是否能被当前网络访问。Mihomo 支持 UDP、TCP、DoT、DoH 和 DoQ 等类型，具体写法以官方 DNS 类型文档为准。
单独看节点域名：如果 IP 形式的节点可以连接，而 server 写域名的节点失败，优先检查 proxy-server-nameserver。当 DNS 请求又依赖需要先解析的代理节点时，可能形成依赖环；官方文档也明确说明，启用按规则解析时需要配置该字段。
最后看规则联动：如果启用了 respect-rules，DNS 连接会遵守路由规则，此时缺少代理节点专用解析路径可能造成失败。先临时恢复简单配置，验证后再逐项加回。

建议每次只改一个字段。修改前复制原配置，修改后重载 Mihomo；如果日志更差或所有域名都无法解析，立即恢复备份，而不是继续叠加 DNS 地址。

最小化复测：关闭 TUN，保留一个节点和一个域名

当你无法判断问题来自 DNS 还是 TUN 接管时，使用最小化复测。先保存原配置，再暂时关闭 TUN，只保留一个确认存在的节点和一个测试域名。这样做的目的不是永久关闭 TUN，而是把“应用代理路径”和“系统流量接管路径”分开。

记录当前配置中是否启用了 tun.enable、auto-route、strict-route、dns-mode 或 dns-hijack。
关闭 TUN 后，仅通过 Mihomo 的普通代理端口访问测试域名。
如果普通代理可用而开启 TUN 后失败，重点检查 TUN 的路由、防火墙、DNS 接管和其他 VPN 是否冲突。
如果关闭 TUN 仍失败，回到 DNS 字段和节点域名解析，不要继续修改 MTU；MTU 主要影响传输，不是 DNS 解析失败的第一检查项。

Mihomo 官方 TUN 文档说明，dns-mode 可为 disabled、native 或 hijack；Windows 上 strict-route 还会影响 DNS 泄漏防护，Android 开启私人 DNS 时，DNS 请求可能无法被自动劫持。相关字段应结合系统环境逐项验证，参见 Mihomo TUN 配置文档。

成功判据：关闭 TUN 后普通代理能打开测试域名，且日志中的 DNS 失败消失；回滚方法：恢复原配置、重新启用 TUN，再一次只恢复一个字段，确认是哪项改变了结果。

Windows、macOS 和 Linux 怎么测试

命令行测试用于判断操作系统当前解析器是否能返回结果，不代表 Mihomo 内部一定使用同一个 DNS 出口。因此，命令成功但 Mihomo 仍失败时，应继续看 Mihomo 的解析路径。

Windows：打开命令提示符，执行 nslookup example.com；需要指定 DNS 时执行 nslookup example.com 1.1.1.1；检查 IPv6 记录可执行 nslookup -type=AAAA example.com。微软文档说明，省略第二个参数时会使用系统默认 DNS，具体命令格式见 nslookup 官方文档。
macOS/Linux：如果系统安装了 dig，可执行 dig example.com A 和 dig example.com AAAA；需要指定服务器时可执行 dig @1.1.1.1 example.com。BIND 官方手册将 dig、host 和 nslookup列为手动查询 DNS 的命令行工具，参见 BIND 9 管理员手册。

判断时至少做两组对照：系统默认 DNS 与指定 DNS、A 记录与 AAAA 记录。如果只有 AAAA 失败，可暂时检查 Mihomo 的 ipv6 设置和网络是否真正支持 IPv6；不要据此直接断定节点或服务失效。

Fake-IP、浏览器 Secure DNS 和私人 DNS 的排查

Mihomo 的 enhanced-mode 支持 fake-ip 和 redir-host。Fake-IP 相关问题通常表现为部分局域网域名、内网服务或特定应用异常，而不是所有域名同时失败。先检查 fake-ip-filter 是否包含局域网后缀、主机名或应用必须直连的域名；修改前保留原列表，避免误删规则。

如果只有 Chrome 失败，检查 Chrome 的“设置→隐私和安全→安全→使用安全 DNS”。Google 文档说明，Chrome 的安全 DNS 可使用自动模式或自定义提供商；自定义提供商发生错误时，可以检查提供商设置或临时关闭该功能进行对照，参见 Chrome 安全 DNS 帮助。

Android 上还要检查系统“私人 DNS”、其他 VPN、广告拦截器和安全软件。Mihomo 文档明确指出，Android 启用 Private DNS 时，DNS 请求可能无法被 TUN 自动劫持。处理顺序应是：先关闭浏览器独立 DNS或恢复自动，再对照系统私人 DNS，最后才改 Mihomo 的 Fake-IP 或 TUN 字段。

复测、保留日志与回滚清单

完成一次修改后，不要只看浏览器能否打开首页。按以下顺序复测：

重载配置后，确认 Mihomo 内核正常启动，没有新的配置解析错误。
测试一个普通域名、一个实际要访问的域名，以及一个使用域名形式 server 的节点。
分别在关闭 TUN 和开启 TUN 的状态下测试，记录差异。
若启用 Fake-IP，测试一个局域网域名和一个公网域名，确认是否只是过滤列表问题。
保存失败时间、域名类型、是否使用 TUN、关键错误行和修改前后差异；隐藏订阅 URL、UUID、节点地址和令牌。

如果恢复原配置后问题仍在，优先检查系统网络、其他 VPN 或防火墙是否改变了 DNS 路径；如果只有一个域名失败，则不能仅凭这一现象认定 Mihomo 的 DNS 模块整体故障。

常见问题

Mihomo 出现 dns resolve failed，是不是一定要换节点？

不一定。先确认失败域名属于订阅、节点 server 还是目标网站。若只有节点域名失败，应先检查 proxy-server-nameserver；若所有域名都失败，应检查 DNS 上游、TUN 和系统网络。只有在解析已经成功、但后续连接或握手仍失败时，才有必要单独评估节点连接问题。

nameserver 和 proxy-server-nameserver 有什么区别？

nameserver 主要处理普通目标域名；proxy-server-nameserver 专门处理代理节点 server 使用域名时的解析。两者都可能使用 DNS，但故障对象不同。IP 节点正常、域名节点失败时，应优先看 proxy-server-nameserver，而不是只替换 nameserver。

Windows 的 nslookup 能成功，为什么 Mihomo 仍然解析失败？

nslookup 默认测试的是 Windows 当前系统 DNS，Mihomo 可能使用自己的 nameserver、nameserver-policy、代理节点专用解析或 TUN 劫持路径。命令行成功只能证明系统路径有结果，不能证明 Mihomo 内部路径相同，因此还要结合 Mihomo 日志、关闭 TUN 的对照结果和实际代理复测。

开启 TUN 后 DNS 失败，应该先改 dns-hijack 还是 strict-route？

先做对照：关闭 TUN测试普通代理是否恢复，再根据系统判断。Windows 要重点检查 strict-route、防火墙和 DNS 接管；Android 还要检查 Private DNS；macOS 和 Windows 对局域网 DNS 请求也存在自动劫持限制。不要同时修改多个字段，先保留原配置以便回滚。

Fake-IP 和 DNS 解析失败有什么关系？

Fake-IP 是 Mihomo 的增强 DNS 模式之一。它可能影响局域网域名、内网服务和特定应用的访问，但不应直接把所有连接失败都归因于 Fake-IP。先用一个公网域名和一个局域网域名做对照，再检查 fake-ip-filter；确认问题范围后再决定是否临时改用 redir-host 进行验证。