ZeZe

Clash节点怎么测速?从延迟初筛到真实速度验证

更新于 2026-10-30 · allzezecloud.xyz

简答:Clash节点测速通常先测代理到测试地址的延迟,再用网页访问、文件下载或实际业务复测速度与稳定性。先确认订阅已更新、代理组已选中且客户端代理已生效,再在“代理/Proxies”页面执行单节点或批量延迟测试;低延迟只适合初筛,不能单独代表网速。

定义:Clash节点测速,是通过客户端经指定节点访问测试地址,记录延迟或连通结果,再结合真实访问、下载和业务表现判断节点是否适合使用。

先看这张表:不同测速结果分别代表什么

本文是第三方使用指南,不代表ZeZe或任何节点服务的官方页面。以下方法主要适用于使用Mihomo内核的桌面客户端,例如Clash Verge Rev;不同版本的菜单名称可能略有差异,移动端也可能把“代理”写成“Profiles”或“Proxy”。截至2026年10月30日,能否看到某个按钮应以当前客户端界面和配置为准。

Clash节点测速结果速查
结果或指标通常说明不能直接说明下一步
延迟数值,单位ms节点访问当前测试地址的响应耗时不能代表下载速度、视频质量或全天稳定性再做网页访问和下载复测
Timeout在设定时间内未完成测试,可能是节点、测试地址或本地配置问题不能直接证明节点永久不可用更换测试地址并检查代理组、端口和日志
延迟很低但使用卡顿测试地址响应快,但实际业务路径或持续传输表现不佳不能仅靠再次点击测速解决按具体网页、视频会议、下载场景复测
多个节点都失败可能是订阅、客户端代理、DNS、测试地址或网络环境共同影响不能直接归因于所有节点失效先用一个已知可用节点和另一个测试地址交叉验证

Mihomo文档将代理组的url定义为健康检查测试地址,interval是周期测试间隔,timeout以毫秒计,tolerance用于控制自动切换所需的延迟差值。可核对Mihomo代理组配置文档。

最短操作路径:先测延迟,再测真实速度

  1. 更新订阅并确认节点存在。打开客户端的配置、订阅或Profiles页面,执行一次更新;确认目标节点仍在代理组中。若节点列表为空,先处理订阅导入问题,不要直接判断为测速失败。
  2. 确认客户端已经接管代理。在Windows上检查系统代理或客户端的代理开关;如果使用TUN模式,确认TUN已启动且系统允许相关权限。移动端则检查VPN或本地代理开关是否处于连接状态。测速按钮能返回数值,只能证明测试请求完成,不能代替完整上网验证。
  3. 进入“代理/Proxies”页面。找到节点所在的代理组,先选中一个节点进行单节点延迟测试;如果界面提供组测速或批量测试,再测试当前组内节点。Clash Verge Rev的源码显示,延迟测试会经被测代理向测试地址发起HTTP请求,默认测试地址可能是Cloudflare的204地址,也可以使用配置的地址,具体行为以当前版本为准,可查看其延迟测试与网络请求说明。
  4. 记录结果而不是只看颜色。保留延迟数值、Timeout节点和测试时间。相同节点在不同时间、不同网络和不同测试地址下可能出现不同结果,因此不要用一次测试建立长期排名。
  5. 对前几名做真实复测。分别使用网页访问、短时间文件下载、视频会议或你的实际工作页面验证。真实复测要一次只换一个变量:先固定设备、网络和测试地址,再切换节点。

如果客户端提供自动测速代理组,可以使用type: url-test。Mihomo文档示例包含url、interval和可选的tolerance、lazy字段;其中lazy会影响未选中代理组是否执行测试。配置前先备份原配置,字段名称和支持情况以当前内核文档为准。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 节点A
      - 节点B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: true

上面只是字段示例,不代表所有客户端都允许直接粘贴到覆写配置中。若配置校验报错,应撤销这次修改,恢复备份,再按客户端提供的配置入口调整。

单节点、批量测速和自动选择有什么区别

三种测速方式对比
方式适合场景优点限制
单节点测速核对某个节点是否能连通变量少,便于排错不能说明整组节点表现
批量测速从几十个节点中做初筛效率较高,容易发现Timeout节点并发请求多,结果仍只反映测试地址的响应
url-test自动选择希望客户端按测试结果自动选择可按设定间隔周期检查切换阈值、测试地址和当前网络都会影响选择,不等于持续带宽测试

自动选择的核心是健康检查,而不是完整下载测速。Mihomo文档明确区分了测试地址、测试间隔、超时和切换容差;如果你要判断办公页面、会议或下载是否顺畅,仍应对候选节点进行真实业务验证。

为什么低延迟却仍然卡顿?按场景复测

延迟测试通常只完成一次面向测试地址的请求。它更适合做连通性初筛,不能覆盖持续传输、丢包、抖动、拥塞、规则命中和目标网站本身的差异。下面按使用场景选择验证方法:

  • 网页和跨境办公:打开实际需要使用的页面,连续操作数分钟,观察登录、加载、上传和保存是否正常。不要只打开一个空白页面就下结论。
  • 视频会议:使用实际会议平台进行短时测试,重点观察音视频是否中断、语音是否延迟以及共享屏幕是否稳定。单次延迟数值不能替代会议质量判断。
  • 视频或流媒体:固定清晰度和播放时长,观察是否频繁缓冲;同时确认规则确实让目标域名走了预期代理组。
  • 下载:使用来源可信、大小适中的文件做短时测试,记录开始速度和中途是否明显下降。大文件测速会消耗流量,不建议反复进行。
  • 游戏或实时交互:优先看实际延迟波动和是否出现短时中断,不要只按网页测速结果选择节点。

如果所有候选节点都“低延迟但卡顿”,先暂停自动切换,固定一个节点测试;如果固定节点正常而自动组异常,再检查url、interval、tolerance和规则命中情况。

测速失败、全部Timeout或测速后无法上网怎么办

  1. 只有一个节点Timeout:切换到同组其他节点测试,再用同一个测试地址复测。若只有该节点失败,先把它标记为待核验,不要把结果扩大到整份订阅。
  2. 所有节点Timeout:先检查客户端是否已启动、代理组是否选中、系统代理或TUN是否生效,再查看客户端日志。随后更换一个可访问的测试地址;测试地址本身不可达时,所有节点可能都会显示失败。
  3. 测速有结果但浏览器打不开:检查浏览器是否绕过系统代理、规则模式是否把目标域名分到DIRECT,以及本地端口是否被其他程序占用。可先关闭TUN,仅用普通系统代理做基础连通性验证,完成后再恢复原设置。
  4. 测速后网络异常:撤销最近改动,关闭客户端代理或TUN,恢复系统原有代理和DNS设置,再重新启动客户端。确认基础网络恢复后,一次只启用一个进阶选项。
  5. 结果反复变化:固定测试时间、设备、网络和测试地址,连续进行少量复测,记录中位表现和失败次数。不要把一次最低延迟当成稳定结果。

Clash Verge Rev项目说明,用户主动测试代理或代理组时会经该代理向测试地址发送HTTP请求;因此测试地址、当前代理和本地网络都会参与结果。涉及订阅、节点凭据或配置文件时,避免把完整链接和日志公开。

最后怎么选节点:用“初筛+实测+备用”

一个可执行的选择流程是:先批量延迟测试,排除明显Timeout;再从结果靠前的节点中挑选两到三个;分别进行你的真实业务复测;最后保留一个主用节点和一个备用节点。主用与备用最好不要只看名称或地区,而要看同一设备、同一网络、同一业务下的实际表现。

  • 网页办公:优先选择页面加载稳定、登录和保存正常的节点。
  • 视频会议:优先选择连续通话中波动少、音视频不中断的节点。
  • 视频播放:优先选择缓冲少、清晰度维持稳定的节点。
  • 下载任务:优先选择速度不容易中途下降的节点,同时控制测试流量。
  • 需要自动切换:再考虑url-test的间隔、超时和容差,不要把自动选择当成完整测速器。

如果你正在为跨境办公或多设备连接选择线路,建议先按本文流程完成节点初筛,再单独记录DNS、MTU、TUN和规则变化,避免多个设置同时修改后无法判断原因。

常见问题

Clash节点测速测的是延迟还是网速?

客户端内置的节点测速通常主要测试经该节点访问测试地址时的响应延迟或连通结果,不等于完整下载速度。要判断网速,需要结合网页访问、短时下载或实际业务复测。

延迟多少才算适合使用?

没有脱离场景和测试地址的统一合格线。网页、会议、视频和下载关注点不同;应在相同设备和网络下比较多个节点,并结合实际业务表现,而不是只按一个ms数值决定。

为什么节点测速全部显示Timeout?

可能是客户端代理未生效、测试地址不可达、节点本身暂时失败、端口或DNS配置异常,也可能是网络环境拦截了测试请求。先检查代理开关和日志,再换测试地址并用单节点复测。

测速URL可以随便填写吗?

不建议随意填写。测试地址需要能稳定返回,且应符合客户端支持的URL格式;地址不可达、响应过慢或被当前网络阻断,都会让结果失真。修改前先备份配置。

测速后需要一直开启url-test吗?

不需要。url-test适合需要周期性健康检查和自动选择的场景;如果你正在排查问题,先固定一个节点更容易判断。问题定位完成后,再根据客户端和内核文档配置自动选择。

常见问题

Clash节点测速测的是延迟还是网速?

内置测速通常主要反映访问测试地址的延迟或连通结果,不等于完整下载速度。真实网速需要通过网页、下载或实际业务复测。

为什么Clash节点测速全部Timeout?

先检查订阅、代理组、系统代理或TUN是否生效,再查看日志并更换测试地址。只有在多个地址和多个节点都失败时,才进一步排查本地网络或配置。

低延迟节点为什么实际仍然卡顿?

低延迟只说明测试请求响应较快,不能覆盖持续传输、丢包、抖动、规则命中和目标业务差异。应固定节点做实际场景复测。

url-test能不能直接测出最快节点?

url-test主要依据健康检查结果进行自动选择,受测试地址、间隔、超时和容差影响。它适合自动初筛,不等于完整带宽测速。

相关阅读

参考资料

  1. Mihomo 文档:proxy-groups 配置与健康检查字段
  2. Mihomo 文档:url-test 代理组
  3. Clash Verge Rev:延迟测试与网络请求说明
  4. Clash Verge Rev:延迟测试实现