Clash 节点延迟测试原理:测速毫秒数为何不等于实际网速

节点列表里的毫秒数，测的是一次请求

Clash 客户端里的“测速”，通常指让内核通过指定节点访问一个测试地址，记录这次探测耗时，再把结果显示为毫秒。它更接近一次小型 HTTP 请求的响应测试，而不是持续下载大文件的带宽测试。节点旁边出现 80 ms，只说明这次探测较快完成，不能换算成每秒能下载多少 MB。

客户端负责按钮、列表与结果展示，Clash 或 Clash Meta（现通常称为 mihomo）内核负责实际连接。不同客户端和内核版本的测试实现、计时边界与结果缓存可能不同，因此两个界面的数字不一定能直接比较。先确认测试地址和测试方式一致，再讨论哪一个节点更快，才有意义。

一次典型探测经过哪些环节

1. 用户点击节点的延迟测试按钮，或策略组按计划触发检查，内核收到测试任务。
2. 内核按指定代理节点建立出站连接；节点服务器域名可能需要先解析，代理协议也可能需要握手。
3. 流量经过代理服务器访问测试站点；使用 HTTPS 时，还涉及与目标站点的 TLS 协商。
4. 内核按实现要求判断响应是否有效，并向客户端返回耗时或失败状态。

上述环节不一定全部重新执行：DNS 缓存、连接复用、协议会话复用，都可能缩短后续探测的耗时。有些实现还会进行不止一次请求。正因如此，界面中的“延迟”不应被严格理解成单个网络包往返一次的时间，也不等同于系统 ping 命令的结果。

测试地址、超时与自动选择怎样影响结果

测试地址决定“测到哪里”

常见测试地址是返回少量内容或 HTTP 204 状态的页面，例如 https://www.gstatic.com/generate_204。响应体很小，可以减少下载数据本身对耗时的影响。但这个地址的结果，只能代表节点到该服务所在网络的访问表现，不代表它访问所有网站都同样快。

节点出口到测试服务可能有较好的互联路径，到视频站或工作平台却可能经过另一组路由。CDN 还可能根据出口位置、DNS 结果和负载分配不同边缘节点。把测试地址从 HTTPS 改成 HTTP，也会改变连接所需的步骤；这两种结果不宜混排后直接选最小值。

超时表示测试未按时完成，不等于节点永久失效

假设一次测试的超时设置是 5000 ms，内核在限定时间内没有完成有效探测，就可能返回失败。原因可能是代理连接失败、目标站点不可达、TLS 错误或当时网络拥塞，并不只有“节点离线”这一种。反过来，把超时改成 10000 ms 只是延长等待窗口，不会让线路本身提速。

界面显示的 Timeout、Error、空白或 0 ms，可能是不同客户端对失败和未测试状态的表达。遇到这些状态，应查看连接日志中的具体错误，不要把所有异常统一解释成丢包。

url-test 选低延迟节点，不负责测最大带宽

下面是 mihomo 风格的策略组示例。香港 01 与 日本 01 必须是当前配置已经定义的节点名；这段示例是配置片段，不是可以直接导入的完整订阅。

proxy-groups:
  - name: 自动低延迟
    type: url-test
    proxies:
      - 香港 01
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300：检查间隔以秒计，这里是 5 分钟；并不是每次打开网页都测一轮。
• tolerance: 50：切换容差以毫秒计，用于减少因微小差异造成的来回切换，不是带宽门槛。
• lazy: true：组未被使用时可跳过周期检查，因此列表里的结果可能不是刚刚测得的。

手动点击“全部测速”、策略组自动检查，以及代理集合的健康检查，可能各有测试入口和参数。只修改某个策略组的 url，不保证客户端手动测试也会随之更换地址。具体字段兼容性应以当前内核为准，相关概念可对照协议与配置参考。

低延迟节点为什么仍然下载慢、视频卡

小响应请求对吞吐量的要求很低。即使线路只能提供 5 Mbps 的持续带宽，几十到几百字节的响应仍可能很快返回。换成高码率视频或大型安装包，带宽限制才会明显暴露。节点延迟低而下载慢，两者并不矛盾。

丢包则会让问题更隐蔽。单次探测碰巧成功，数字可能很好看；连续传输时，TCP 重传和拥塞控制却会压低有效速率。使用 QUIC 的业务还涉及 UDP 路径，而一次基于 TCP 的 HTTPS 探测不能证明节点支持 UDP，也不能反映它的 UDP 质量。

一套可重复的节点测试步骤

第一步：确认业务流量真的经过被测节点

先在客户端选择要测试的节点，再到“连接”或“Connections”页面查看目标域名的记录，核对命中的规则与代理链。页面名称随客户端不同而变化，但检查对象相同：实际连接最终用了哪个出口。测试期间不要同时使用自动切换组，否则长文件下载和下一次网页请求可能已经走了不同节点。

系统代理只影响遵循该设置的应用。命令行、游戏和某些下载工具未必读取它；TUN 模式可以扩大接管范围，但仍要核对路由、排除项和实际连接记录。开启 TUN 本身不是加速操作，也不会把一条低带宽线路变成高带宽线路。

第二步：固定条件，连续测而不是只看一次

1. 关闭其他大流量任务，保持同一网络、同一测试地址和同一超时设置。
2. 每个节点测试 10 次，间隔约 5 秒，记下成功耗时及失败次数。
3. 用中位数比较典型等待时间，同时记录最大值，避免一次很低的结果掩盖波动。
4. 在实际常用时段重复一次，例如晚间 20:00—22:00，观察繁忙时段的变化。

如果 10 次请求中有 2 次失败，准确表述是“本轮应用层探测失败率为 20%”，不能直接写成“网络丢包率 20%”。一次请求可能包含多个数据包，也可能因 DNS、TLS 或目标服务问题失败。即使连续 10 次成功，样本也不足以证明长时间连接稳定。

第三步：用实际业务补充带宽与稳定性测试

选择自己有权访问、大小已知的文件或同一段视频，固定来源后对比节点。下载先观察约 10 秒的建立和爬升过程，再观察 30—60 秒的持续速率；视频则关注缓冲次数、缓冲时长和播放器提供的连接速率信息。两种测法都比只看节点列表更接近日常体验。

单位也要对齐：8 Mbps 在十进制换算下约为 1 MB/s，80 Mbps 约为 10 MB/s，实际有效速率还会受到协议开销影响。若工具显示的是 MiB/s，它采用二进制单位，数值又略有不同。持续带宽测试会消耗订阅流量，移动网络下尤其要控制测试次数。

用 curl 拆开连接时间与首字节时间

想进一步判断时间花在哪里，可以让 curl 明确使用本地 HTTP 代理，再输出各阶段时间。下面假设客户端的 HTTP 或混合监听端口为 7890；这只是常见配置，并非所有客户端的默认值，运行前请到客户端端口设置中确认。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 \
  --max-time 15 \
  --output /dev/null \
  --silent --show-error \
  --write-out 'connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

这段命令适用于 macOS、Linux 等常见 shell。Windows PowerShell 可调用 curl.exe，把命令合成一行，并把 --output /dev/null 改为 --output NUL。显式填写代理后，不必猜测命令行是否读取了系统代理；但依然要先确认客户端当前选择的出口。

• time_connect：在这个本地 HTTP 代理场景中，主要反映到 127.0.0.1:7890 的连接，不能当成到远端节点的延迟。
• time_appconnect：HTTPS 的 TLS 握手完成时间；经 HTTP 代理时，其前面还包含代理隧道建立等过程。
• time_starttransfer：收到响应首字节的累计时间，包含前面的连接过程和目标服务等待。
• time_total：本次请求的总耗时。测试页面几乎没有响应体，因此它不能体现大文件吞吐。

这些时间都是从请求开始计起的累计值，不应直接相加。它们也不保证和客户端内核的测速数值相同，因为测试实现与连接复用方式可能不同。这条命令更适合对照排障：同一节点、同一目标、同一参数重复运行，看看变慢主要出现在连接阶段还是首字节之前。

常见问题：超时、丢包与自动选择

选择节点时，把延迟作为第一轮筛选，再用持续吞吐、失败频率和目标应用表现作确认。发现异常后，一次只改变一个条件：先固定出口，再固定测试目标，最后比较网络或时段。这样得到的结论，比不断点击“全部测速”更容易复现，也更有助于定位问题。