Mihomo节点无法使用怎么办？按症状排查与恢复

更新于 2026-11-05 · yunti.online

简答：先关闭TUN并只测试一个节点：如果节点列表为空，优先检查订阅；如果单个节点失败，检查节点参数或节点状态；如果全部节点超时，检查网络、时间、DNS和协议；如果节点显示可用但浏览器打不开，再检查代理端口、系统代理和DNS。不要一开始反复改配置，每次只改一个变量并保留备份。

定义：Mihomo节点无法使用，通常是订阅没有正确更新、节点参数失效、代理组未选中、内核或端口未启动，或者TUN、DNS与系统网络设置发生冲突。

先用这张表判断故障在哪一层

先不要直接重装或修改整份配置。打开 Mihomo 客户端的节点、代理组和日志页面，按下面的现象分流。不同客户端的菜单名称可能不同，请以当前版本界面为准。

现象	优先检查	下一步
节点列表为空	订阅链接、HTTP返回、配置是否加载成功	重新复制订阅链接并更新；确认更新后生成的是 Mihomo/Clash 格式配置
只有一个节点超时	该节点的服务器、端口、TLS或协议参数	换同一订阅中的另一个节点；单节点失败不代表整个客户端故障
全部节点超时	本地网络、系统时间、DNS、出口网卡和协议兼容性	先关闭TUN，改用Mixed或HTTP/SOCKS端口测试
节点测速失败但网页能打开	测速地址、代理组健康检查或防火墙	用浏览器和 curl 交叉验证，不要只看延迟数字
节点显示可用但浏览器打不开	系统代理、浏览器代理扩展、端口占用和DNS	确认浏览器使用的是 Mihomo 当前监听端口
打开TUN后全设备断网	虚拟网卡权限、auto-route、DNS劫持和其他VPN冲突	关闭TUN恢复网络，再检查权限和虚拟网卡

官方文档说明，Mihomo既可以通过 HTTP、SOCKS、Mixed 等代理端口接收流量，也可以通过 TUN 捕获系统流量；因此“节点可用”和“应用已经正确走代理”是两个不同问题。可参考 Inbound 配置文档。

第一步：确认订阅和节点确实被加载

备份当前配置。在客户端找到配置文件或配置管理页面，先复制一份 YAML 文件。不要把包含订阅链接、UUID、密码或密钥的内容发到公开群组。
重新检查订阅链接。确认没有漏复制字符、空格、换行或多余引号。若链接需要登录或有有效期，先在浏览器中打开，观察是否返回配置文本、错误页面或登录页面。
更新后确认配置已经被选中。有些客户端只是下载了新配置，但没有自动切换到该配置。更新完成后，重新进入代理页面确认节点数量发生变化。
检查节点类型和参数是否完整。官方节点配置要求包括名称、类型、服务器和端口等字段；如果是 Trojan、VLESS 等节点，还要核对 TLS、SNI、UUID、密码或传输层参数。可参考 Mihomo代理节点通用字段文档。

如果更新后仍然是空列表，优先处理订阅返回内容或服务端状态，不要先改DNS和TUN。若只有部分节点出现，说明订阅可能返回了筛选后的节点，或者客户端过滤规则隐藏了节点。

第二步：关闭TUN，用代理端口做最小验证

这是最快的分界方法。先关闭TUN，暂时关闭系统代理或自动接管选项，然后只启用 Mihomo 的 Mixed、HTTP 或 SOCKS 端口。Mihomo 的顶层配置支持 port、socks-port、mixed-port 等固定代理端口，具体端口以当前运行配置为准，参见官方 Inbound 文档。

在客户端代理组中手动选择一个节点，不要先使用自动选择。
确认运行模式不是 direct。官方定义中，rule 是规则匹配，global 是全局代理，direct 是全局直连；使用 global 时还需要在 GLOBAL 代理组中选择代理或策略。参考 Mihomo全局配置文档。
在浏览器中手动设置 HTTP 或 SOCKS5 代理，地址填 127.0.0.1，端口填客户端当前显示的端口。不要照抄示例端口。
Windows 可运行 netstat -ano | findstr :7890，其中 7890 只是假设值，请替换为实际端口。看到 LISTENING 才表示有程序监听；没有结果时，回到客户端检查内核是否启动。
macOS 或 Linux 可运行 lsof -nP -iTCP:7890 -sTCP:LISTEN。若没有输出，检查端口配置；若被其他进程占用，改用一个未占用端口后重启客户端。

如果关闭TUN后浏览器可以访问，节点和内核大概率已经工作，故障范围缩小到TUN、系统路由、DNS或其他网络接管软件。如果关闭TUN后仍然无法访问，继续检查节点、日志和本地网络。

第三步：按日志关键词处理单节点与全部节点超时

打开客户端日志页面，将日志级别临时调整为 info 或 debug，复现一次失败请求后再查看。官方 API 文档说明，Mihomo 可以通过日志接口读取实时日志，并区分 info、warning、error、debug 等级；不同客户端未必直接提供相同菜单，因此入口名称可能不同，参见 Mihomo API 文档。

日志或现象	常见边界	处理顺序
`timeout`、dial timeout	节点服务器不可达、端口被拦截、网络或协议不匹配	换另一个节点；再换网络；最后核对服务器、端口和协议参数
`connection refused`	目标端口没有服务，或节点端口填写错误	核对节点端口，不能靠改本地DNS解决
`TLS handshake`、证书错误	系统时间、SNI、证书域名或TLS参数不匹配	先校准系统时间，再核对SNI和证书域名
`no such host`、DNS失败	节点域名解析失败或当前DNS不可用	临时关闭TUN测试；检查DNS和IPv6，再清理DNS缓存
`rule match DIRECT`	请求被规则判定为直连	检查目标域名对应的规则和当前代理组，不要默认所有请求都会走代理
`address already in use`	代理端口被其他程序占用	检查监听进程，修改端口后重启，并同步更新浏览器或系统代理

测试时尽量只改变一项：先换节点，再换网络，再处理DNS或TUN。这样才能知道真正起作用的修复步骤。

第四步：节点可用但网页打不开，检查代理、DNS与IPv6

确认代理组选择。在规则模式下，某个网站可能按照规则走直连；在全局模式下，也必须确认 GLOBAL 代理组已经选择了实际节点。不要把“节点测速成功”当成“所有应用都已接管”。
确认浏览器没有冲突。暂时关闭浏览器代理扩展、其他代理软件和系统级网络加速工具，只保留一个代理入口。
确认端口一致。如果 Mihomo 显示 Mixed 端口是一个数字，但浏览器仍填写旧端口，表现通常是连接失败或直接无网络。
检查DNS模式。Mihomo 文档将 DNS、fake-ip 和 TUN 的 DNS 劫持分别列为配置项；fake-ip、redir-host、dns-hijack 的行为可能受客户端版本和配置影响，不要把某一份示例配置当成所有版本的默认值。可参考 DNS配置文档和 TUN配置文档。
临时测试IPv4。如果节点域名或出口网络的IPv6路径异常，可在客户端或节点配置中暂时选择 IPv4 优先进行对比。测试成功后再决定是否长期调整，不要在没有记录的情况下永久关闭IPv6。

Windows 可先执行 ipconfig /flushdns，然后关闭并重新打开浏览器；macOS 可执行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。若清缓存后无变化，下一步应回到 Mihomo 日志和节点参数，而不是继续重复清缓存。

第五步：TUN无法启动或启动后断网的恢复顺序

TUN适合捕获系统流量、自动路由和DNS劫持，但它比普通代理端口更依赖系统权限、虚拟网卡和路由设置。官方文档指出，TUN配置涉及自动路由、DNS劫持等能力，部分行为还与操作系统有关，参见 TUN官方配置说明。

先关闭TUN。如果网络恢复，先保持关闭状态，用Mixed或HTTP/SOCKS端口验证节点。
退出其他接管网络的软件。包括其他VPN、虚拟网卡工具、容器网络和安全软件的代理模块。只保留一个TUN或透明代理入口。
重新启动客户端并检查权限。Windows 关注管理员权限、虚拟网卡和防火墙提示；macOS 关注系统网络扩展或VPN配置授权；Android 关注系统VPN授权是否被撤销。菜单名称会随客户端版本不同而变化。
逐项恢复TUN设置。先开启TUN本身，再测试；然后再恢复自动路由、DNS劫持、严格路由或自动检测出口网卡。一次只开启一个选项。
最后才处理系统网络栈。Windows 不要一开始就执行重置命令。若关闭TUN、退出客户端、移除冲突软件后仍无法联网，再考虑系统网络修复，并记录原有代理和DNS设置，避免恢复后无法复原。

恢复操作完成后，按“关闭TUN→退出客户端→确认系统代理关闭→重新启动客户端→先测代理端口→最后开启TUN”的顺序验证。只要某一步再次断网，就回退这一步，不要继续叠加改动。

Windows、macOS和Android的差异化检查

Windows：先检查系统代理地址和端口是否指向当前 Mihomo 监听端口，再用 netstat -ano 判断端口占用。若TUN启动失败，重点看管理员权限、虚拟网卡、其他VPN和防火墙提示。
macOS：检查系统设置中的网络代理和VPN/过滤器配置，确认没有残留的手动代理。使用 lsof 检查端口时，端口号必须替换成客户端实际值。
Android：确认系统VPN授权只给当前客户端，关闭其他VPN应用；若应用内有“系统代理”“VPN模式”或“路由模式”，先使用默认模式测试，再逐项恢复自定义DNS和分流设置。
所有平台：不要公开订阅链接、节点密码、UUID、私钥或完整配置。若问题只发生在一个网络，优先对比手机热点与当前Wi-Fi；若换网络后恢复，继续检查本地路由器、DNS、防火墙或网络出口。

什么时候应该更新内核或客户端

如果配置在另一个客户端可以使用，而当前 Mihomo 客户端持续报格式错误、协议不支持或TUN异常，可以核对客户端所使用的 Mihomo 内核版本。但不要仅根据第三方文章声称的“最新版”升级。官方 GitHub Release 页面会列出版本标签、发布日期和对应文件，升级前应以当前页面为准，并保留旧版本和配置备份：Mihomo官方Release页面。

升级后先做最小验证：导入备份配置、关闭TUN、手动选一个节点、用代理端口打开一个普通网页；确认成功后再恢复规则、DNS和TUN。若升级后只有原配置失败，优先检查配置字段兼容性，不要立即判断节点已经失效。

常见问题

Mihomo节点列表为空，但订阅更新显示成功怎么办？

先确认更新后的配置是否真正被选中，再检查客户端是否过滤了节点、订阅是否返回登录页或错误页，以及订阅格式是否适配当前客户端。不要先改TUN和DNS。

Mihomo所有节点都超时，是节点全部失效了吗？

不能直接判断。先关闭TUN，用Mixed或HTTP/SOCKS端口测试；再换手机热点或其他网络，并检查系统时间、DNS、IPv6和日志。如果换网络后恢复，问题更可能在本地网络或出口。

Mihomo节点测速失败，但浏览器可以打开网页，算节点不能用吗？

不一定。测速依赖健康检查地址、代理组设置和超时参数，测速失败不等于所有业务请求都失败。应使用浏览器和 curl 等实际请求交叉验证，并查看日志。

打开TUN后电脑没有网络，应该先重置网络吗？

不建议一开始重置。先关闭TUN、退出客户端、关闭系统代理并停止其他VPN；确认普通网络恢复后，再检查虚拟网卡、权限、自动路由和DNS劫持，最后才考虑系统网络修复。

Mihomo应该使用全局模式还是规则模式？

排障时可以短暂使用全局模式验证代理链路，但必须在 GLOBAL 代理组中选择实际节点；规则模式下则要检查目标请求是否被规则判定为直连。测试完成后按实际需求恢复模式。