Clash订阅导入后节点测速失败怎么办？按症状排查

更新于 2026-10-31 · flyingbird.buzz

简答：先不要急着删除订阅：Clash节点测速失败，不一定代表节点全部失效。先用另一个测速地址或手动访问网页验证，再按“单个节点、部分节点、全部节点”分类排查订阅、配置、客户端和本地网络。

定义：本文所说的“节点测速失败”，是指订阅已导入、节点能在列表中显示，但延迟测试出现 Timeout、Error、空白或长时间无结果。

先做这一步：判断是测速失败，还是节点真的不能用

最快的判断方法是：先选一个节点，启用当前配置并打开系统代理，再访问一个你平时能正常打开的网页；随后更换测速地址重新测试。如果网页可以访问而延迟仍显示失败，优先怀疑测速地址、测试超时或客户端显示问题，而不是直接判断节点失效。

现象	优先判断	先做什么
只有一个节点 Timeout	单节点线路或节点参数异常	换同组其他节点对比
同地区或同类型节点都失败	节点组、测试地址或线路共同问题	换测试地址并切换其他分组
全部节点都失败	订阅、客户端、系统代理或本地网络	检查订阅更新、配置启用和本机网络
测速失败但网页能打开	测速请求与实际访问路径不同	以实际访问结果和日志交叉验证
节点列表为空	不是测速问题，而是订阅或格式问题	转到订阅更新失败分支

Mihomo文档说明，延迟测试本质上是通过指定测试地址和超时时间返回延迟结果；因此测试地址、超时设置和节点本身都会影响显示结果。可参考Mihomo API 中的代理延迟测试说明。

按最短流程排查：订阅、配置、测试地址、本地网络

确认订阅仍然有效。重新复制订阅地址，检查是否少了字符、前后多了空格，且不要把网页登录地址当成订阅地址。更新后确认节点数量确实发生变化或保持正常。
确认当前配置已经启用。导入订阅后，部分客户端仍可能停留在旧配置、旧代理组或直连模式。选择刚更新的配置文件，并在代理页面确认当前策略组不是“直连”或空组。
单独测试一个节点。不要一开始批量测试全部节点。先选一个节点，再测试同组的第二个节点；如果只有一个失败，问题范围通常比“全部失败”更小。
更换测速地址。测速地址不可访问、响应状态不符合预期或超时过短，都可能让界面显示失败。Mihomo文档给出的健康检查示例包括Cloudflare和Google的204地址，但实际使用时应以当前客户端和网络能够访问的测试地址为准。相关字段包括测试地址、间隔、超时和预期状态，可查看Mihomo代理提供者健康检查配置。
切换模式做对照。在规则、全局和直连之间分别测试一次。若直连网页正常、代理模式失败，重点查看节点、代理组和系统代理；若三种模式都异常，先检查本地网络。
完全退出客户端后重启。不是只关闭窗口，而是退出托盘进程，再重新打开并更新订阅。若仍异常，可新建一个空配置进行对照，不要立即覆盖原配置。

通用菜单名称可能因Windows、macOS、Linux、Android或具体客户端版本不同而变化；上面的流程适用于使用Clash或Mihomo内核的常见客户端，按钮名称以当前版本为准。

Windows、macOS、Android分别检查什么

平台	重点检查	失败后的回退
Windows	系统代理开关、其他代理软件、TUN权限、Windows防火墙提示	先关闭其他代理程序，只保留一个客户端测试；必要时重启客户端
macOS	系统网络代理、权限提示、网络服务顺序、其他VPN或代理扩展	切换到另一网络服务或手机热点，再测试同一节点
Android	VPN权限、始终开启VPN、省电限制、其他VPN应用、Wi-Fi与移动数据差异	允许客户端后台运行，关闭重复VPN连接后重测
Linux	系统代理环境变量、TUN权限、路由和端口占用	先用HTTP或SOCKS本地端口做单应用测试，再恢复全局设置

如果使用的是代理组自动测速，注意“组的测速结果”不一定等同于每个节点的直接测试结果。Mihomo文档指出，代理组的健康检查会依据组内配置的代理、测试地址、超时和预期状态判断结果；部分来自代理提供者的节点还受组配置方式影响，可查看Mihomo代理组配置说明。

根据日志报错分流处理

timeout：先把它视为“在规定时间内没有得到测试结果”，不要直接等同于节点永久失效。增加测试超时或更换测试地址，再比较同一节点是否仍失败。
connection refused：常见排查方向是节点端口、协议参数或本地连接被拒绝。换另一个节点验证，避免只反复测试同一节点。
TLS handshake failed：检查系统日期和时间、节点域名解析、客户端内核兼容性，以及是否启用了会修改证书或流量的本地软件。
EOF：表示连接在完成请求前结束。可先重新更新订阅、重启客户端，再用同一网络测试其他节点。
测速API返回错误或结果为空：先更换测速地址并查看客户端日志。如果网页访问正常而仅界面测速失败，应把它归为测速链路问题继续验证。公开的Clash Verge Rev项目问题中也记录过“测速显示Timeout但节点实际可用”的报告，因此不能仅凭测速数字下结论，详见Clash Verge Rev项目问题记录。

仍然失败时的复测清单与安全提醒

在当前Wi-Fi和手机热点各测试一次。
在另一台设备导入同一订阅，比较是否只有一台设备异常。
记录失败节点数量、测试地址、客户端名称、模式和日志关键词。
不要把完整订阅链接、节点密码或配置文件公开到论坛、截图或工单中。
不要把订阅链接提交给不明转换站；如果必须转换，先确认数据会被如何保存和处理。

如果换网络后恢复，优先检查本地DNS、代理冲突或网络出口；如果所有网络和设备都失败，再回到订阅状态、格式和节点服务侧核验。不要用单次测速结果判断长期延迟、稳定性或可用性。

常见问题

Clash节点测速失败是不是订阅失效了？

不一定。先确认节点列表仍存在，再用当前配置访问实际网页，并更换测速地址。如果只有测速失败而网页可用，优先排查测速地址、超时和客户端显示；如果节点为空或更新报错，才重点检查订阅链接、格式、有效期和流量状态。

为什么节点能用，但测速一直显示Timeout？

延迟测试是对指定测试地址发起请求，测试地址不可达、响应状态不匹配、超时时间过短或客户端测速接口异常，都可能造成Timeout。可更换测试地址、适当增加超时，并用实际网页访问结果交叉验证。

所有节点都测速失败，应该先重装客户端吗？

不建议先重装。先确认当前配置已启用，更新订阅，切换规则和全局模式，关闭其他代理或VPN，再用手机热点测试。只有在新配置和不同网络下仍能复现，才考虑清理客户端状态或重新安装。

测速失败和节点列表为空是同一个问题吗？

不是。测速失败表示节点已经显示但测试没有结果；节点列表为空通常涉及订阅更新、订阅格式、配置解析或过滤规则，应先处理订阅和配置，不要把它当作线路延迟问题。

Windows和Android的排查顺序一样吗？

核心顺序相同，都是先确认订阅和配置，再区分节点与本地网络；但Windows要重点检查系统代理、TUN和防火墙，Android要重点检查VPN权限、省电限制和其他VPN应用。