使用 Clash Verge、Clash Verge Rev、Mihomo Party、OpenClash 或其他 Clash 客户端时，有些用户会遇到：
Test Failed
Delay Test Failed
URL Test Failed
Health Check Failed
节点测速失败
延迟测试失败
自动选择无法测速
所有节点显示Test Failed
这种问题看起来像“节点全部坏了”，但实际上不一定。
Clash里的节点测速，本质上通常是让代理节点去访问一个测试URL，然后根据响应时间计算延迟。
如果：
测试地址本身无法访问。
节点连接失败。
DNS异常。
测试超时。
URL-Test配置错误。
Proxy Provider健康检查异常。
客户端或内核状态异常。
都可能出现：
Test Failed。
所以看到Test Failed以后，不要马上判断机场节点全部失效。
最快排查顺序是：
先测试单个节点是否真的能上网。
再检查测速URL。
再看Clash日志。
然后判断是：
节点本身失败。
还是测速机制失败。
下面详细说明。
一、Clash Test Failed是什么意思？
Test Failed可以理解成：
Clash尝试通过某个代理节点完成一次延迟测试，但没有在规定条件内得到有效结果。
这个结果可能来自：
连接超时。
测试URL打不开。
DNS解析失败。
TLS连接失败。
节点本身不可用。
测速接口异常。
所以：
Test Failed
并不能直接等于：
节点已经失效。
二、节点显示Test Failed但实际能上网正常吗？
有可能。
这是最值得先判断的情况。
例如：
节点测速显示Test Failed。
但手动选择这个节点以后：
Google可以打开。
YouTube可以播放。
IP也成功切换。
这种情况下说明：
节点代理功能本身可能正常。
失败的是：
延迟测试。
测试URL。
或者测速请求。
所以不要看到测速失败就马上删除节点。
三、节点测速到底在测什么？
Clash的延迟测试并不是单纯Ping服务器。
很多情况下会通过代理节点请求一个：
HTTP或HTTPS测试地址。
例如常见的：
204测试页面。
如果请求成功，就根据耗时得到：
延迟。
如果请求失败或超时，就可能显示：
Test Failed。
所以Clash节点延迟和传统Ping不是完全一回事。
四、URL-Test是什么？
URL-Test通常用于：
自动选择节点。
Clash会定期测试多个节点访问指定URL的延迟。
然后根据结果：
选择延迟更低的节点。
典型配置中会看到：
type: url-test
url: 某个测试地址
interval: 测试间隔
如果测速URL失败，整个自动选择组可能都受到影响。
五、为什么所有节点突然一起Test Failed？
如果几十个节点同时：
Test Failed
不要先怀疑几十台服务器全部同时故障。
优先检查：
测试URL。
本地网络。
DNS。
Mihomo Core。
测速配置。
因为如果所有节点共用同一个测速URL，而这个URL当前无法访问，就可能导致：
所有节点一起Test Failed。
六、为什么只有一两个节点Test Failed？
如果：
其他节点都有延迟。
只有特定节点Test Failed。
更应该怀疑：
该节点服务器。
节点协议。
线路。
端口。
节点本身网络状态。
这种情况下测速URL大概率不是全局性问题。
七、第一步应该测试什么？
不要先修改设置。
先选择一个显示：
Test Failed
的节点。
然后尝试访问：
Google。
YouTube。
或者其他确定需要代理的网站。
如果能够正常打开：
说明节点不一定坏。
应该继续检查测速机制。
如果完全无法访问：
再进一步排查节点连接。
八、怎么判断Test Failed是测速问题还是节点问题？
可以用这个方法：
节点A显示Test Failed。
手动选择节点A。
打开海外网站。
如果能打开：
更像测速失败。
如果打不开：
更像节点本身连接失败。
这个判断非常重要。
九、为什么测速失败但Google可以打开？
可能是因为：
测试URL和Google不是同一个网站。
节点可能能访问Google。
但访问测速URL失败。
也可能测速URL：
被限制。
返回异常状态。
TLS握手异常。
响应太慢。
所以：
节点能上网
和：
测速一定成功
并不完全等价。
十、常见测速URL有哪些？
在Mihomo相关配置中，常见健康检查地址包括：
Google的generate_204。
Cloudflare相关测试地址。
具体地址通常由：
客户端。
订阅配置。
Proxy Provider。
决定。
普通用户不需要每天修改测速URL。
但出现大面积Test Failed时值得检查。
十一、generate_204是什么？
这是一个常见的HTTP连通性测试地址。
正常访问时会快速返回：
204状态。
因为页面几乎没有正文，所以常被用于：
网络检测。
延迟测试。
健康检查。
Clash/Mihomo相关配置中也经常用它作为测速URL。
十二、测速URL打不开会怎样？
如果当前网络或节点无法访问测速URL，就可能出现：
Test Failed。
例如配置测速URL为某个Google地址。
而当前测试请求无法正常完成。
那么即使部分节点实际还能访问其他网站，也可能测速失败。
十三、可以换测速URL吗？
可以，但不要盲目频繁更换。
如果确认：
节点本身正常。
只有当前测速URL失败。
可以换成稳定、轻量、适合健康检查的地址。
修改以后重新测试。
如果所有节点恢复延迟，就基本可以确认问题和测试URL有关。
十四、为什么不建议随便找一个网页当测速URL？
因为普通网页可能：
体积很大。
跳转很多。
启用防机器人验证。
根据地区返回不同内容。
加载速度不稳定。
这样会让测速结果失真。
测速URL最好具备：
响应快。
页面小。
稳定。
状态码明确。
这些特征。
十五、Proxy Provider健康检查是什么？
如果订阅通过：
proxy-providers
加载节点，配置中可能存在：
health-check
它会定期测试Provider中的节点。
例如可能包含：
enable
url
interval
timeout
lazy
expected-status
如果健康检查配置异常，就可能出现：
Provider节点延迟不更新。
Health Check Failed。
大量节点Test Failed。
十六、health-check的url有什么作用？
它决定：
Provider里的节点访问哪个地址来测试健康状态。
如果这个URL本身失败：
健康检查也会失败。
所以大面积测速错误时，要特别检查：
health-check.url。
十七、timeout是什么意思？
timeout表示：
允许一次测速等待多长时间。
如果节点在规定时间内没有完成测试：
就会判定失败。
例如网络高峰期延迟较大时，timeout设置过低，就可能出现：
实际节点还能用。
但测速总失败。
十八、timeout越大越好吗？
不是。
如果设置太大：
每次测速等待时间会很长。
自动选择更新变慢。
失效节点也会长时间占用测试。
所以应该使用合理值，而不是无限增加。
十九、interval是什么？
interval表示：
自动测速或健康检查的时间间隔。
例如：
每300秒测试一次。
间隔太短可能造成：
频繁测速。
额外请求。
节点压力增加。
间隔太长则可能：
节点变化后不能及时更新。
一般没有必要为了追求最低延迟设置成几秒一次。
二十、lazy是什么？
lazy可以理解成：
懒加载健康检查。
例如某个Proxy Provider长期没有被使用时，不一定持续高频测速。
这样可以减少不必要的健康检查。
如果配置了lazy，某些用户可能会觉得：
为什么节点延迟没有一直实时更新。
这不一定是故障。
二十一、expected-status是什么？
expected-status用于判断：
测速URL返回的HTTP状态是否符合预期。
例如测试URL正常应该返回：
204。
如果实际返回了：
403。
500。
其他状态。
健康检查可能被判定异常。
所以测速失败不一定代表TCP连接完全失败。
也可能只是响应状态不符合预期。
二十二、为什么换网络以后Test Failed消失？
如果：
校园Wi-Fi全部Test Failed。
切手机热点以后全部正常。
说明：
节点本身不一定有问题。
更应该怀疑：
当前本地网络。
DNS。
网络出口。
测速URL连通性。
这和节点服务器全部同时失效相比，更符合实际情况。
二十三、Wi-Fi能上网但Clash测速失败怎么办？
先确认：
普通网页能否打开。
Clash订阅能否更新。
海外网站能否通过节点访问。
然后再检查：
测速URL。
DNS。
节点日志。
不要只看：
Wi-Fi图标显示已连接。
因为基础网络正常不代表代理测速一定正常。
二十四、DNS会导致Test Failed吗？
会。
如果测速URL是域名：
Clash需要先解析对应地址。
如果出现：
no such host。
DNS lookup failed。
failed to resolve。
测速自然无法继续。
这种情况下重点检查：
DNS。
二十五、日志显示no such host怎么办？
这通常说明：
测速URL域名没有成功解析。
可以检查：
本地DNS。
Clash DNS配置。
网络是否可以正常解析其他域名。
不要一开始去更换节点协议。
二十六、日志显示i/o timeout怎么办？
i/o timeout更偏向：
请求已经发起。
但没有在规定时间内完成。
可能来自：
节点慢。
测试URL连接慢。
网络丢包。
线路异常。
timeout过短。
这时可以进行：
节点和网络交叉测试。
二十七、日志显示connection refused怎么办？
如果测试过程中出现：
connection refused
可能说明目标连接被明确拒绝。
需要继续判断：
是代理服务器拒绝。
还是测速目标连接异常。
如果节点连普通网站也失败，则更偏向节点问题。
二十八、为什么自动选择组一直显示Test Failed？
如果这是：
URL-Test代理组。
首先检查：
组里的节点是否有效。
再检查：
url字段。
如果所有节点共用一个错误的url，就可能整个自动选择组全部失败。
二十九、URL-Test和手动选择有什么区别？
手动选择：
由用户自己指定节点。
URL-Test：
由Clash根据测速结果自动选择节点。
所以如果URL-Test测速机制异常：
手动节点可能仍然可以正常使用。
三十、自动选择测速失败需要切手动吗？
可以作为临时排查。
例如：
自动选择显示Test Failed。
手动选择某个节点却可以正常上网。
说明：
代理节点并不是全部失效。
更应该继续检查：
URL-Test配置。
三十一、为什么自动选择总是选不到节点？
如果所有候选节点都：
Test Failed。
自动选择当然无法获得正常延迟结果。
所以需要先恢复：
健康检查。
而不是只调整自动选择组顺序。
三十二、tolerance是什么？
在URL-Test中，tolerance通常用于：
节点自动切换时的延迟容差。
例如两个节点延迟差距非常小，就没有必要不停来回切换。
它不是：
测速失败的主要修复参数。
所以Test Failed时不要先改tolerance。
三十三、把tolerance调大能解决Test Failed吗？
不能。
tolerance只影响：
多个已成功测速节点之间的切换判断。
如果节点本身连测试都失败：
调多少tolerance都没有用。
三十四、订阅更新成功为什么测速还是失败？
因为：
订阅更新
和：
节点健康检查
是两件事。
订阅更新成功只说明：
配置文件成功下载。
它不代表：
订阅里的每个节点都一定能连接。
也不代表：
测速URL一定可访问。
三十五、测速失败需要重新导入订阅吗？
通常不作为第一步。
如果：
节点配置正常显示。
订阅也能更新。
只是延迟检测失败。
优先检查：
网络。
测速URL。
节点实际连接。
日志。
不要先删除Profile重新导入。
三十六、升级Mihomo能解决吗？
有时可以，但不是所有Test Failed都和Core版本有关。
如果出现：
协议不支持。
配置字段错误。
Core异常。
升级可能有帮助。
如果只是：
测试URL无法访问。
升级内核不会解决。
所以要先根据日志判断。
三十七、为什么更新内核后测速恢复？
可能是旧Core存在：
兼容问题。
协议支持问题。
API测速问题。
或者客户端和Core版本不匹配。
如果更新以后恢复，说明问题可能确实和底层环境有关。
但不能把所有测速失败都归因于版本。
三十八、AnyTLS、VLESS、TUIC等新协议更容易Test Failed吗？
不是简单看协议名字。
如果当前Core已经正确支持对应协议：
测速逻辑仍然是：
节点建立连接。
访问测试地址。
不同协议节点都可能测速成功或失败。
真正需要检查：
节点是否能建立连接。
三十九、Unsupported Proxy Type和Test Failed有什么区别？
区别非常大。
Unsupported Proxy Type表示：
Core根本无法识别节点协议。
Test Failed通常表示：
节点已经被识别。
但延迟测试没有成功。
所以：
Unsupported属于配置解析阶段。
Test Failed属于测试或连接阶段。
四十、节点全部绿色但网页打不开怎么办？
这说明：
延迟测试成功
不代表：
所有实际网站都一定正常。
后续还要检查：
系统代理。
TUN。
规则模式。
DNS。
目标网站本身。
测速只能证明：
节点成功访问了测试URL。
四十一、测速100ms就代表速度一定快吗？
不代表。
延迟和带宽不是同一个概念。
一个节点可能：
延迟80ms。
下载很慢。
也可能：
延迟180ms。
实际视频速度很好。
延迟测试更适合反映：
响应速度。
而不是完整带宽能力。
四十二、延迟越低越好吗？
通常低延迟更适合：
交互操作。
网页打开。
聊天。
但节点选择还需要考虑：
丢包。
带宽。
稳定性。
服务器负载。
不能只按一个延迟数字选节点。
四十三、为什么同一个节点每次测速差很多？
可能来自：
本地Wi-Fi波动。
服务器负载。
网络高峰。
不同路由。
测试URL响应。
QUIC或TCP连接状态。
几十毫秒波动通常不一定异常。
四十四、频繁点测速会不会更准确？
不一定。
连续高频测试反而可能：
增加瞬时连接。
导致结果抖动。
没必要每秒反复测速。
正常测试几次，看整体趋势即可。
四十五、节点显示0ms正常吗？
通常需要结合客户端实际表现判断。
如果：
0ms。
空白。
Test Failed。
可能代表：
没有获得有效测速结果。
不能把0ms理解成：
延迟为零。
四十六、为什么部分节点一直不显示延迟？
可能原因包括：
节点没有参与当前测试。
健康检查未启用。
lazy状态。
Provider配置。
节点本身失败。
客户端UI没有刷新。
可以先手动触发一次测速。
四十七、重启Clash有用吗？
可以作为基础操作。
如果是：
测速API卡住。
Core状态异常。
界面数据没有刷新。
重启客户端可能恢复。
但如果真正原因是：
测试URL打不开。
节点服务器失效。
重启不会从根本上解决。
四十八、清除配置缓存有必要吗？
通常不是第一选择。
只有在：
Provider状态异常。
配置缓存损坏。
更新后旧数据不刷新。
才考虑进一步处理缓存。
不要因为一次Test Failed就把全部配置目录删除。
四十九、防火墙会影响测速吗？
有可能。
如果安全软件阻止：
mihomo.exe
访问网络。
可能出现：
节点测试失败。
连接失败。
但如果同一客户端已经能够正常代理网页：
防火墙通常就不是第一怀疑对象。
五十、为什么浏览器能上网但Clash测速接口失败？
可能是：
浏览器实际通过另一个节点或代理。
测速URL被限制。
Clash测速请求使用不同路径。
系统存在多个代理软件。
所以需要确认：
当前真正工作的到底是哪一个代理客户端。
五十一、同时开两个Clash会影响测速吗？
可能。
多个客户端同时运行可能导致：
端口冲突。
系统代理覆盖。
TUN冲突。
不同Core同时运行。
UI连接错Core。
所以排查Test Failed时最好只保留：
一个正在使用的Clash/Mihomo客户端。
五十二、为什么节点测速失败但Proxy Provider显示正常？
可能是：
不同测速入口使用了不同URL。
Proxy Provider自己的health-check正常。
客户端手动Test使用另一地址。
所以表现可能不一致。
需要看当前客户端实际调用什么测速方式。
五十三、为什么Provider健康检查失败但手动节点正常？
同样可能是：
health-check.url异常。
expected-status不匹配。
timeout设置太小。
Provider测试环境和手动测试方式不同。
所以要分开判断。
五十四、最推荐的排查顺序是什么？
第一步：
确认是一个节点还是所有节点Test Failed。
第二步：
手动选择失败节点，实际访问海外网站。
第三步：
如果能上网，优先检查测速URL。
第四步：
如果不能上网，查看节点连接日志。
第五步：
检查DNS是否出现解析错误。
第六步：
检查URL-Test或health-check的url。
第七步：
确认timeout是否过低。
第八步：
换手机热点做一次交叉测试。
第九步：
确认没有同时运行多个代理客户端。
第十步：
必要时更新Mihomo并重启。
五十五、哪些操作不建议一开始就做？
不建议：
删除全部订阅。
重装Windows。
关闭防火墙。
永久关闭IPv6。
随便修改节点端口。
随便更改协议。
开启所有TUN选项。
不停切换DNS。
先找出：
到底是节点失败。
还是测速失败。
五十六、常见问题
Clash Test Failed是什么意思？
表示一次节点延迟或健康检查没有成功完成，不一定代表节点彻底失效。
Test Failed但是Google能打开正常吗？
有可能，说明节点本身可能正常，只是测速URL或健康检查失败。
所有节点同时Test Failed怎么办？
优先检查测速URL、本地网络、DNS和健康检查配置。
只有一个节点Test Failed怎么办？
更应该怀疑该节点本身、服务器或线路。
URL-Test是什么？
URL-Test会通过指定测试URL比较多个节点延迟，用于自动选择节点。
health-check是什么？
Proxy Provider可以通过health-check定期检测节点可用性和延迟。
修改DNS一定有用吗？
只有日志显示域名解析失败时才值得重点检查DNS。
开TUN能解决Test Failed吗？
通常不能。TUN负责流量接管，不是测速修复工具。
测速失败需要重新导入订阅吗？
通常不需要，先检查节点真实连接和测试URL。
节点延迟低就一定快吗？
不一定，延迟和下载带宽、稳定性是不同指标。
五十七、总结
Clash出现：
Test Failed
Delay Test Failed
URL Test Failed
Health Check Failed
节点测速失败
时，不要第一时间判断：
机场节点全部坏了。
最重要的是先做一个简单判断：
显示Test Failed的节点实际能不能上网。
如果：
Test Failed
但Google、YouTube正常。
说明应该重点检查：
测速URL。
URL-Test。
Proxy Provider health-check。
timeout。
expected-status。
客户端测速机制。
如果：
Test Failed
并且节点实际也完全不能用。
再继续检查：
节点服务器。
DNS。
网络。
协议。
端口。
Mihomo Core。
另外，如果几十个节点突然同时Test Failed，更应该优先怀疑：
共同测试地址或本地网络。
而不是几十个服务器同时失效。
正确排查顺序可以概括成：
判断单个还是全部失败
→ 实际测试节点能否上网
→ 查看日志
→ 检查测速URL
→ 检查URL-Test和health-check
→ 检查DNS和网络
→ 换热点交叉测试
→ 最后再考虑Core或配置异常。
只要先把“节点连接失败”和“测速机制失败”这两类情况分开，大多数Clash Test Failed问题都会更容易定位。