Clash 节点延迟测试原理：测速数值与实际网速为何对不上

1. 节点延迟的毫秒数，不是下载速度

Clash 客户端里的“测速”，多数指向内核发起的 URL 延迟测试，而不是下载大文件测带宽。界面显示的 120 ms 是一次小型请求的耗时指标，不能换算成每秒能下载多少数据。它主要反映连接建立与请求响应的等待，并不测量持续传输能力。

把它简单叫作“握手耗时”便于理解，但技术上仍不够完整：具体内核实现、代理协议、是否复用连接以及 HTTP 或 HTTPS 测试地址，都会影响计时范围。这个数既不是纯 TCP 握手时间，也不是系统 ping 命令得到的 ICMP 往返时间。

例如，节点 A 的延迟为 80 ms，下载只有 2 MB/s；节点 B 的延迟为 160 ms，下载可达 15 MB/s。这组数字只是说明性示例，不是本站实测。A 可能更快完成短请求，B 却更适合传输大文件。两种结果并不矛盾，因为带宽、拥塞与单连接限制不是一次小请求能够覆盖的。

2. url-test 请求经过哪些环节

url-test 是策略组类型之一。内核通过组内候选节点访问指定 URL，取得测试结果，再按可用性、延迟及容差等条件选择节点。图形界面的“全部测速”也可能调用内核的延迟测试接口，但不一定使用策略组里相同的 URL、超时或触发方式。

一次典型的 HTTPS 探测

1. 确定测试目标：读取测试 URL，例如 https://www.gstatic.com/generate_204。这个路径通常返回 HTTP 204，没有需要下载的正文。
2. 建立代理通道：设备连接候选节点，并完成该代理协议需要的连接过程。节点地址解析、传输层与协议握手可能带来等待。
3. 访问测试站点：经代理出口连接目标；HTTPS 还涉及目标站点的 TLS 协商。目标域名由哪一侧解析，取决于协议与实际配置，不能统一认定由本机完成。
4. 获得响应并记录：内核按实现记录请求耗时，返回结果或错误。不同客户端可能把失败显示为“超时”、红色标记或不可用状态。

节点探测通常针对指定代理出站，不等于把测试 URL 当作浏览器访问再完整走一遍日常分流。实际应用可能被规则送往直连、另一个策略组或其他节点。因此，“测试很快、网页很慢”的第一步，是去连接面板确认网页实际用了哪条出站，而不是立刻更换测试地址。

3. 测试 URL、超时和测试间隔怎么设置

下面是适用于支持这些字段的 mihomo 内核的配置片段。mihomo 是 Clash Meta 后续使用的项目名称；旧版 Clash 或某些客户端的图形设置不一定支持全部字段。先确认客户端显示的内核类型，再对照对应内核文档，不要把片段当作完整订阅文件直接覆盖。

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

这里的 香港-01、日本-01 必须与现有 proxies 中的名称完全一致。使用代理集合时，也可以按内核支持的方式用 use 引用集合；不要在尚未定义节点的文件中单独粘贴这一段并期待它能联网。

• url：优先选响应小、路径稳定、能代表日常访问方向的地址。HTTP 与 HTTPS 涉及的握手不同，切换协议后不宜直接拿旧数值排名。
• interval: 300：自动检查间隔为 300 秒，即 5 分钟。它不是连接超时，也不是每隔 300 毫秒测试。
• timeout: 5000：单次测试的超时上限为 5000 毫秒。上限太短会把暂时拥塞误判成不可用，调长也不能修好失效节点。
• tolerance: 50：切换容差为 50 毫秒。它用于减少延迟小幅变化造成的频繁切换，不是带宽阈值，也不会把显示延迟减去 50。
• lazy: true：启用惰性检查，组未被使用时可能跳过周期测试。不要据此推断每个节点都严格按墙上时钟每 5 分钟更新。

不要只为了得到更小的数字而换地址

测试站点所在区域、CDN 调度和出口互联都会改变结果。若换成一个距离出口极近的地址，数字可能下降，但常用网站的路径并没有改善。比较节点时，应保持 URL、网络环境与测试方式一致；排查特定网站时，再增加该网站的小型可访问资源作为辅助观察。

也不建议把数百个节点的间隔统一压到 10 秒。频繁探测会增加连接数、流量与设备负担，还可能触发远端限流。日常可先用 300 秒观察，出现故障时手动复测几轮，比持续高频刷新更容易看清问题。

4. 延迟很低但网页、视频仍然慢的原因

小请求成功，不代表高峰带宽充足

204 请求只需要交换少量数据。即使出口带宽已经拥塞，它仍可能很快完成；视频分片和大型文件却要持续占用链路。服务端限速、共享出口负载、跨网互联以及本地 Wi-Fi 丢包，都可能让实际吞吐量下降。

真实网站与探测站点走的后半程不同

从设备到代理节点的路径只是前半段。节点到测试站点、节点到视频网站，可能经过完全不同的线路。某个测试地址快，无法推导出另一家 CDN 也快；目标站点的区域策略、负载或对出口 IP 的限制，还可能直接影响可用性。

浏览器没有使用测试对应的节点

• 规则模式下，域名可能命中 DIRECT，或者进入另一个策略组。打开连接记录，核对目标域名、命中规则和最终代理链。
• 系统代理通常只影响遵循该设置的应用。游戏、自带网络栈的应用与部分命令行程序可能不使用它。
• TUN 通过虚拟网卡接管相应流量，但接管范围仍受路由、排除项和 DNS 配置影响。开启 TUN 不会自动提高节点带宽。
• 浏览器复用的长连接未必随着策略切换立即重建。测试切换效果时，可重新打开目标应用，必要时只关闭相关连接，注意避免中断正在进行的下载。

还有一种常见误会是单位比较：8 Mbps 理论上约等于 1 MB/s，实际还需扣除协议开销。运营商标称带宽、测速网站显示单位与下载器单位不一致时，先完成单位换算，再讨论速度是否异常。

5. 用延迟、带宽、稳定性三步挑选节点

选择节点时，先排除不可用，再看稳定性，最后按用途比较吞吐量。不要只依赖列表排序，也不要一边自动切换，一边试图比较固定节点的速度，否则测到的对象可能已经变了。

1. 固定条件：在同一台设备、同一个网络下测试，暂停后台下载。暂时通过手动选择组锁定一个候选节点，确认实际业务连接也走它。
2. 观察多轮延迟：以约 10 秒间隔手动测 5 次，记录结果与失败次数。这里是短时排查，不是建议长期设置 10 秒自动探测。
3. 测试持续传输：对同一个可信下载源测试 30～60 秒，记录稳定后的速度，而不是只看最初一秒的峰值。测速会消耗流量，计费网络需先确认额度。
4. 核对实际用途：视频看缓冲与拖动恢复，远程终端看输入响应，会议看掉线与音频连续性。URL 测试不能代替 UDP 业务测试。

表格是记录方法的演示数据，并非具体服务商的实测。A 的延迟中位数是 83 ms，B 是 153 ms；C 在 5 次中失败 1 次，样本失败率为 20%。样本很少，不能据此估计长期故障率，但已经足以提示：需要继续观察，而不是因为 C 最低一次只有 70 ms 就优先选择它。

6. 超时、结果不一致与自动切换的排查顺序

全部节点都超时

先确认本机基础网络能用，订阅节点仍在有效期内，系统日期和时间准确。随后查看内核日志：timeout 表示在上限内未完成，connection refused 通常指连接被拒绝，证书相关错误则需进一步检查时间、目标证书与网络干预。不要把所有失败都归结为“节点慢”。

再换一个已知可访问的小型测试地址做对照。只有原测试 URL 失败时，应检查目标服务或出口到该目标的路径；多个地址都失败时，再检查节点参数、本地网络与防火墙。不要为消除证书报错而直接关闭证书验证，那会掩盖真正原因。

界面测速与自动选择组的结果不一样

核对两边使用的 URL、超时和更新时间。界面的手动测速、url-test 策略组，以及 proxy-providers 下的 health-check 是不同的配置入口，不能假定修改其中一处会同步全部入口。订阅更新还可能覆盖本地编辑，持久调整应放在客户端支持的覆写或合并配置中。

最快节点没有立即被选中

先确认当前业务确实使用 url-test 组，而不是手动选择组或 fallback 组。fallback 主要按顺序挑选可用候选，并非单纯追逐最低延迟。对 url-test，还需考虑容差、测试刷新时机、惰性检查及既有连接；几毫秒差距通常不值得反复切换。