Mihomo 连接失败怎么排查？

更新于 2026-10-30 · uziport.shop

简答：Mihomo 连接失败不要先反复更换节点，先关闭 TUN 和系统代理残留，用明确的 HTTP 或 SOCKS 端口测试；再根据日志中的 connection refused、timeout、no such host、unknown field 或 permission denied，分别检查配置、端口、节点、DNS 和权限。本文截至 2026-10-30，按最短路径带你定位问题，并说明什么时候应回滚到最小配置。

定义：Mihomo 连接失败，是指 Mihomo 内核、代理入口、节点出站、DNS 解析、规则匹配或 TUN 路由中的一个或多个环节没有正常完成连接。

先试这一步：关闭 TUN，确认普通代理是否能用

如果你现在表现为“所有网页都打不开”或“开启 TUN 后断网”，先不要修改大量 DNS 参数。关闭 TUN，暂时关闭系统代理残留，再在浏览器或系统网络设置中手动使用 Mihomo 的 HTTP 或 SOCKS 端口。端口以当前配置文件为准，不要直接照抄其他文章的端口号。

Mihomo 的入站可以是代理端口、TUN 或 listeners；TUN 负责接管系统流量，是否能正常接收流量还取决于监听地址、系统路由和防火墙。可先参考 Mihomo 入站配置文档确认自己测试的是哪一种入口。

前置检查：记录版本、保存配置并保护敏感信息

1. 记录操作系统、客户端名称、Mihomo 内核版本、问题发生时间和完整错误关键词。版本号可以在客户端的内核或关于页面查看；不同客户端菜单名称可能不同。
2. 先复制一份当前配置文件，后续修改 DNS、TUN 或规则前保留原文件，避免无法判断是哪项改动导致问题。
3. 不要公开订阅地址、API secret、UUID、密码、完整节点链接和带认证信息的日志。提交日志前，至少隐藏域名中的账号信息、token、密码和订阅参数。
4. 如果刚升级内核后出现 unknown field、invalid domain 或配置无法加载，先对照当前版本的配置文档，不要把旧版本字段直接拼接到新配置中。官方 FAQ 说明，发行文件名还会区分系统、架构和部分兼容标签，升级或更换二进制时应确认下载的是匹配当前系统的文件。

可从 Mihomo 官方 FAQ核对系统、架构和发行文件说明；版本变化则以 Mihomo 官方 Releases页面为准。

按日志关键词排查：先定位失败发生在哪一层

看到 unknown field、YAML、invalid domain

这类信息通常说明配置没有通过解析，节点是否可用还没有进入测试阶段。先恢复最近一次能加载的配置，再逐段加入新增字段。重点检查缩进、冒号、列表短横线、引号和字段拼写。不要把其他内核或旧教程中的字段直接复制到 Mihomo。

看到 connection refused

它表示目标地址主动拒绝连接，可能是本机端口被其他程序占用、Controller 地址或代理端口填错，也可能是远端服务没有监听。先检查客户端显示的监听端口，再关闭其他代理工具，确认同一端口没有被重复使用。Windows 可在命令提示符执行 netstat -ano | findstr :端口号，macOS 或 Linux 可执行 lsof -nP -iTCP:端口号 -sTCP:LISTEN；将“端口号”替换为实际数字。

看到 timeout

先区分单个节点超时还是全部节点超时。只有一个节点失败时，检查该节点的地址、端口、TLS、SNI 和传输参数；全部节点失败时，优先检查订阅是否更新成功、本地网络是否能解析节点域名、系统时间是否准确，以及防火墙或其他代理软件是否拦截连接。单次超时只能说明这次连接未完成，不能据此断定节点永久失效。

看到 no such host、resolve failed 或 DNS 相关错误

这表示域名解析链路需要检查。先在关闭 TUN 的情况下，用系统工具测试节点域名是否能解析；再查看 Mihomo DNS 日志，确认请求是否进入配置的 nameserver、proxy-server-nameserver 或 nameserver-policy。官方 DNS 文档列出了这些字段及 fake-ip 相关配置，可对照 Mihomo DNS 配置文档逐项核验。

看到 permission denied 或 TUN 启动失败

先关闭 TUN 确认普通代理入口是否正常，再检查客户端是否获得系统要求的网络权限、防火墙是否允许核心程序、VPN 或虚拟网卡是否冲突。Mihomo 官方 TUN 文档说明，auto-route负责自动设置路由，strict-route会加强路由约束并影响 DNS 泄漏防护，但在特定场景也可能影响虚拟机等软件；因此不要一开始同时打开多个实验选项。

订阅导入失败：检查返回内容和 User-Agent

订阅更新失败不一定代表链接失效。服务端可能根据请求的 User-Agent 返回不同内容：浏览器打开时可能得到登录页、Base64 文本或错误页，而 Mihomo 客户端使用特定 User-Agent 时可能返回 YAML 或 JSON。判断格式时，应以客户端实际请求得到的内容为准，不要只看浏览器页面。

1. 先在 Mihomo 客户端中执行更新或导入，打开配置预览，确认返回内容是否能被解析，检查配置中是否出现 proxies、proxy-groups、rules 等配置结构。
2. 如果客户端有订阅信息卡，查看更新结果、HTTP 状态和返回大小；不要把“下载成功”误认为“配置可用”，还要确认内核能加载。
3. 需要在本机查看前几行时，可在终端使用 curl -L --compressed -A 'clash.meta' '你的订阅地址' | head -n 5。请将“你的订阅地址”替换为真实地址；命令可能把订阅地址留在 shell 历史中，检查完成后应清除该条历史，并避免把终端输出发到公开平台。
4. 如果浏览器返回 HTML、登录页或 401/403，而客户端返回 YAML 或 JSON，优先检查客户端请求头、订阅授权和服务端格式要求，不要直接修改 YAML 来“修复”一个实际的鉴权问题。

如果订阅能下载但导入后无法启动，把问题拆成两段：先确认下载内容格式，再确认配置字段是否能被当前 Mihomo 内核解析。两段不要混在一起排查。

DNS、规则和代理组：网页打不开时这样对比

1. 把模式暂时切到全局，并手动选择一个节点。若全局模式可用、规则模式不可用，问题可能在规则匹配、代理组选择或最终规则，而不一定是节点问题。
2. 如果明确选择节点仍打不开，先测试节点域名解析，再查看连接日志是否真正发起了出站连接。没有连接记录时，可能是系统流量没有进入 Mihomo，或请求被其他软件接管。
3. 检查 DNS 监听地址和端口是否被其他程序占用。配置了 fake-ip 时，局域网域名、本地域名和部分应用可能需要加入合适的 fake-ip-filter；不要为了排障把所有域名永久加入排除列表。
4. 对比关闭 DNS 增强模式、关闭 TUN 和开启 TUN 三种状态，每次只改一个变量。若只有开启 TUN 时失败，优先回看 dns-hijack、auto-route、auto-detect-interface 和防火墙。

官方 TUN 文档说明，dns-hijack用于把匹配到的 DNS 请求导入内部 DNS 模块；Windows 上 strict-route还涉及阻止常规多网卡 DNS 解析造成的泄漏。不同系统的行为存在差异，因此应以当前平台和客户端实际日志为准，而不是照搬另一系统的配置。

恢复最小配置：判断是节点问题还是规则问题

当完整配置包含大量规则、订阅转换和 TUN 参数，最有效的回滚方式是暂时保留一个代理入口、一个节点、一个代理组和最少规则。先让内核正常启动，再依次加入 DNS、规则集、自动选择组和 TUN。每加入一层就重新测试一次。

1. 备份完整配置，另存为可恢复文件。
2. 新建最小配置，只保留当前客户端所需的代理端口、一个已知节点、一个手动选择组和简单规则。
3. 关闭 TUN，确认普通 HTTP 或 SOCKS 入口能连接。
4. 切换全局模式，确认节点出站正常。
5. 恢复规则模式，确认规则没有把目标域名错误地分配到 DIRECT。
6. 最后开启 DNS 和 TUN，每次只启用一个功能，并记录开启后出现的第一条错误。

如果最小配置可以工作，而完整配置失败，说明故障更可能位于规则、DNS、TUN 或某个新增字段；如果最小配置也失败，则继续检查节点、订阅、系统网络和防火墙。这个结论只是缩小范围，不等于已经证明某一项必然故障。

验证完成后的回滚与安全清单

• 关闭 TUN 后，普通代理端口是否能访问测试页面。
• 明确选择单个节点后，是否仍出现 timeout。
• 全局模式和规则模式的结果是否不同。
• 节点域名是否能在当前网络下解析。
• 订阅返回内容是否为客户端可识别的配置，而不是登录页或错误页。
• 是否存在多个代理客户端同时占用端口、修改系统代理或创建虚拟网卡。
• 重新开启 TUN 前，是否已经保存能正常联网的配置。
• 反馈问题时是否隐藏订阅地址、API secret、UUID、密码和完整节点配置。

如果修改后无法联网，先关闭 TUN、关闭系统代理，再恢复备份配置；不要在多个配置文件之间来回覆盖。完成定位后，只保留已验证的改动，并记录客户端、系统、内核版本和复现步骤。

本文是第三方使用指南，不代表任何客户端或服务品牌的官方页面；菜单名称和可用字段可能随客户端及 Mihomo 内核版本变化，具体以当前客户端和 Mihomo 官方文档为准。

常见问题

Mihomo 显示节点可用，但浏览器还是打不开，先查什么？

先确认系统代理是否真正指向 Mihomo 的当前端口，再切换到全局模式并手动选择一个节点。如果全局模式可用而规则模式不可用，优先检查规则和代理组；如果两者都不可用，再看 DNS、出站日志和系统代理冲突。

浏览器打开订阅地址是网页，Mihomo 还能导入吗？

不能仅凭浏览器结果判断。订阅服务可能按 User-Agent 返回不同格式。应在客户端查看配置预览，或用与客户端接近的 User-Agent 查看前几行；如果客户端实际收到 HTML、登录页或鉴权错误，就需要检查订阅授权和服务端返回格式。

开启 TUN 后断网，应该直接改 MTU 吗？

不建议先改 MTU。官方文档说明 MTU 会影响极端条件下的传输速率，普通用户通常可以保持默认值。更合理的顺序是先关闭 TUN验证普通代理，再检查权限、防火墙、auto-route、strict-route、dns-hijack 和 auto-detect-interface，最后才针对特定复现现象测试 MTU。

所有节点都超时，是否能直接判断订阅失效？

不能。全部超时还可能与本地 DNS、出口网络、系统时间、防火墙、代理冲突或配置解析有关。先确认订阅是否能更新、节点域名是否能解析、日志是否实际发起出站连接，再判断订阅授权或节点端是否需要进一步核验。

常见问题

Mihomo 显示节点可用，但浏览器还是打不开，先查什么？

先确认系统代理指向当前 Mihomo 端口，再切到全局模式并手动选择一个节点。全局可用而规则模式不可用时，优先检查规则和代理组。

浏览器打开订阅地址是网页，Mihomo 还能导入吗？

不能仅凭浏览器结果判断。服务端可能根据 User-Agent 返回不同内容，应在客户端查看配置预览，或用客户端接近的 User-Agent查看前几行。

开启 TUN 后断网，应该直接改 MTU 吗？

不建议先改 MTU。应先关闭 TUN确认普通代理，再检查权限、防火墙、auto-route、strict-route、dns-hijack和出口网卡识别。

所有节点都超时，是否能直接判断订阅失效？

不能。还可能是 DNS、出口网络、系统时间、防火墙或代理冲突。先检查订阅更新、节点域名解析和实际出站日志。

相关阅读

• 继续查看 Mihomo DNS、Fake-IP 与 TUN 设置
• 如果问题发生在桌面客户端导入阶段，可查看订阅导入排查
• 如果你使用的是 sing-box，可参考格式与订阅返回内容排查
• iPhone 用户可查看按症状排查连接问题的方法

参考资料

1. Mihomo 官方文档：入站配置
2. Mihomo 官方文档：DNS 配置
3. MetaCubeX 官方文档：TUN 配置
4. Mihomo 官方 FAQ：系统与发行文件说明
5. Mihomo 官方 Releases