Mihomo连接失败怎么排查？完整排查步骤

更新于 2026-10-18 · leiting.autos

简答：Mihomo连接失败，建议先关闭TUN并测试普通代理端口，再查看debug日志定位问题；如果日志出现dns resolve failed，优先检查DNS配置，如果出现network is unreachable或TUN启动后断网，则检查auto-route、auto-detect-interface、strict-route、dns-hijack和系统防火墙。

定义：Mihomo连接失败，通常是内核未正常启动、代理节点不可用、域名解析失败、规则选错出口，或TUN模式路由与系统网络冲突导致的连接异常。

一、先判断是哪一层出了问题

不要一开始就修改大量参数。Mihomo的连接过程可以拆成五层：配置文件能否加载、内核是否启动、域名能否解析、代理节点能否建立连接，以及应用流量是否被正确送入代理。先按这个顺序排查，通常比反复更换节点更容易找到原因。可以在客户端的日志页面将log-level临时设置为debug；官方文档说明，debug会尽可能输出运行中的信息，适合定位连接失败原因。查看 Mihomo 全局配置中的日志级别说明

二、按顺序排查配置和节点

1. 先验证配置是否能单独启动。在客户端中重新载入配置，查看是否出现字段错误、解析错误或端口占用。不要同时修改DNS、规则和TUN设置；每次只改一项，并在修改前保留原配置备份。
2. 确认代理组不是“未选择”或误选直连。在代理组页面选择一个明确的节点或策略组，再访问一个平时能打开的测试站点。若代理组中全部节点都失败，问题更可能在节点参数、本地网络或订阅内容，而不是规则。
3. 先关闭TUN测试普通代理。如果客户端提供HTTP、SOCKS或混合端口，先让浏览器或测试应用使用该端口。普通代理能连接而TUN不能连接，说明节点本身未必有问题，应把重点放在路由、DNS劫持和权限上。
4. 检查节点地址和协议参数。确认服务器域名或IP、端口、密码、加密方式、UUID、传输层和TLS相关字段与服务端提供的信息一致。任何无法从配置或服务提供方核实的字段，都不要自行猜测。

如果只有某个节点失败、其他节点正常，可以先记录该节点的错误日志，再换一个已知可用节点进行对照。不要把单个节点失败直接判断为Mihomo内核故障；节点状态和服务端配置需要以实际提供方信息为准。

三、DNS解析失败时怎么处理

当日志包含dns resolve failed、域名无法解析或连接长时间停留在解析阶段时，优先检查DNS。Mihomo官方文档说明，dns.enable: false时会使用系统DNS；启用内置DNS后，则需要检查nameserver等字段是否填写正确。查看 Mihomo DNS 配置文档

1. 打开当前配置，确认dns:下的enable、nameserver和default-nameserver没有拼写错误。
2. 如果使用加密DNS，先确认地址格式、端口和证书校验设置正确；不要一次配置过多DNS服务器，否则不容易判断到底是哪一个失败。
3. 如果节点地址使用域名，确保用于解析节点域名的DNS本身可用。官方文档指出，当DNS请求需要遵循路由规则并通过代理时，可能还需要配置proxy-server-nameserver，以避免“解析节点域名需要代理、代理又需要先解析节点域名”的循环。
4. 如果只是某些国内域名或局域网域名失败，检查nameserver-policy、规则集和fake-ip-filter，不要直接把所有域名都改成同一种解析方式。
5. 修改后重载配置并清理DNS缓存，再观察日志是否从“解析失败”变为“已匹配规则并连接”。

DNS能解析不代表节点一定可用。解析成功后仍然超时，应继续检查节点连接、规则出口和本地防火墙。

四、开启TUN后连接失败或断网

TUN模式会在网络层接管流量，因此需要额外检查路由和系统权限。官方文档将auto-route定义为自动设置全局路由，将流量导入TUN接口；auto-detect-interface用于自动选择出口网卡，多网卡设备建议明确指定出口接口。查看 Mihomo TUN 配置文档

1. 确认TUN权限。Windows通常需要允许内核通过防火墙并授予管理员权限；macOS和Linux也要确认客户端或内核有创建TUN接口的权限。
2. 先使用保守配置。排查期间可暂时保持auto-route: true、auto-detect-interface: true，不要同时加入复杂的自定义路由、网卡排除和UID规则。
3. 检查DNS劫持。常见写法包括dns-hijack匹配UDP或TCP的53端口。官方文档特别提示，macOS和Windows无法自动劫持发往局域网的DNS请求；Android启用私人DNS时，也可能无法自动劫持DNS。遇到这类情况，应先关闭私人DNS或改用普通代理进行对照测试。
4. 谨慎启用strict-route。strict-route可以强化路由并减少DNS泄漏，但官方文档也提示它可能使VirtualBox等应用在特定场景下异常。若开启后突然无法访问局域网、虚拟机或内网设备，可暂时关闭它进行对比。
5. 检查防火墙和网卡。如果日志出现network is unreachable，查看系统路由表、TUN接口和防火墙规则；Linux环境还要确认防火墙是否允许TUN接口出站流量。

如果开启TUN后整台设备断网，先关闭TUN或退出客户端恢复普通网络，再修改配置。不要在网络已经中断时继续同时更换DNS、规则和节点，否则很难判断真正原因。

五、规则匹配导致“看起来像连接失败”

有时节点本身可用，但请求被规则送到了错误的出口。例如日志显示请求命中DIRECT，而该域名实际需要代理；或者请求命中代理组，但当前代理组没有选中可用节点。排查时打开连接记录，重点看目标域名、命中的规则和最终出口。

1. 临时将运行模式切换为global或选择一个明确的代理组进行对照。
2. 如果全局模式可以连接、规则模式不行，说明问题集中在规则顺序、规则集更新或代理组名称。
3. 检查规则中引用的代理组名称是否与proxy-groups中的名称完全一致，包括大小写和空格。
4. 测试完成后恢复规则模式，不建议长期使用全局模式替代规则配置。

如果仅一个应用失败，确认该应用是否遵循系统代理；不遵循系统代理的应用通常需要TUN接管，或在应用自身设置代理。TUN顶层配置适合自动路由、DNS劫持和按应用路由，官方文档也建议普通用户优先使用顶层TUN配置，而不是高级的TUN监听器配置。查看 Mihomo 入站配置说明

六、建议采用的最短排查流程

1. 记录客户端、系统、Mihomo内核和当前配置的基本信息。
2. 将日志临时调为debug，复现一次，不要连续点击重试。
3. 关闭TUN，只测试普通代理端口。
4. 确认代理组已选中节点，并检查节点域名能否解析。
5. 根据日志区分DNS失败、节点超时、规则误匹配或路由不可达。
6. 只修改一个字段，重载配置后再次复现。
7. 普通代理正常后，再开启TUN；先使用自动出口网卡和简单路由。
8. 最后再恢复自定义DNS、规则集、严格路由和应用排除项。

提交问题或寻求协助时，建议提供脱敏后的错误日志、系统类型、客户端版本、内核版本、是否开启TUN以及复现步骤；订阅地址、密码、UUID和完整节点参数不要公开。

常见问题

Mihomo显示连接失败，应该先换节点吗？

不建议直接先换节点。先关闭TUN、确认代理组已选择节点，再查看debug日志。如果多个节点都无法连接，应优先检查DNS、本地网络、配置格式和规则；只有单个节点失败时，才重点核对该节点的地址、端口和协议参数。

Mihomo开启TUN后无法上网怎么办？

先关闭TUN或退出客户端恢复网络，然后检查auto-route、auto-detect-interface、dns-hijack、strict-route、系统权限和防火墙。多网卡设备要特别检查出口网卡是否选错；Android还要确认私人DNS是否阻止DNS劫持。

出现dns resolve failed代表节点失效吗？

不一定。dns resolve failed首先表示域名解析阶段出现问题，可能与内置DNS、系统DNS、DNS路由或节点域名解析有关。应先检查dns.enable、nameserver、default-nameserver和proxy-server-nameserver，再判断节点是否真的不可用。

为什么只有一个应用连接失败？

该应用可能不遵循系统代理，或者被规则送到了错误出口。先查看连接记录中的命中规则和最终出口；如果普通代理对其他应用正常，可使用TUN接管，或在该应用内部配置兼容的代理方式。

修改Mihomo配置后仍然连接失败怎么办？

每次只修改一个配置项并重载配置，保留修改前的备份。若仍无法判断，记录完整错误行、系统类型、是否启用TUN、代理组选择和复现步骤，但不要公开订阅地址、密码或UUID。

相关阅读

• 先了解如何核验客户端与下载来源
• 查看最新客户端与网络排查文章
• 返回雷霆使用指南首页

参考资料

1. Mihomo 全局配置：日志级别与外部控制
2. Mihomo DNS 配置文档
3. Mihomo TUN 配置文档
4. Mihomo 入站配置说明