Clash 测速数值与实际体验不一致的原因:url-test 延迟测试原理解析

Clash 延迟数值：测的是一次请求，不是下载速度

节点旁的“80 ms”通常来自一次经由该代理发出的 HTTP 或 HTTPS 探测。ms 是毫秒，描述这次探测花了多久；MB/s 是每秒传输多少兆字节，描述持续传输能力。两者相关，但不能互相换算。看到 80 ms，不能据此推断下载能达到 8 MB/s。

Clash 配置中的 url-test 是自动选择代理组的一种类型。它让候选代理访问指定测试地址，根据探测结果选择代理。客户端界面上的“测速”按钮也可能调用内核的延迟接口，但按钮使用的地址、超时设置，不一定与配置里的自动选择组相同。

下面涉及 Clash Meta 的地方，也适用于其后续使用的 mihomo 名称。不同客户端封装的界面不同，内核版本和测试参数也可能不同。横向比较前，先统一测试地址、网络环境和测试时段。

url-test 的请求经过哪些环节

它不是系统命令里的 ping

系统里的 ping 通常发送 ICMP 回显报文。Clash 的 URL 探测则通过代理访问一个 Web 地址。代理服务端可能不响应 ICMP，但仍能转发网页请求；反过来，服务器 ping 值很低，也不代表代理出口访问目标网站很快。

一次新的 HTTPS 探测，可能涉及本地到代理入口的连接、代理协议握手、出口到测试站点的连接，以及 TLS 握手。TLS 是 HTTPS 用来建立加密通信的协议。DNS 解析、连接复用和协议实现也会影响结果，不能简单把显示值理解成“电脑到节点服务器的往返延迟”。

1. 连接代理入口：家庭宽带、Wi-Fi 干扰、运营商路由和入口拥塞，都会影响这一段。
2. 完成代理连接：协议、传输层及已有连接是否可复用，会改变建立连接的开销。
3. 访问测试地址：代理出口到测试站点的路由、站点响应速度，以及域名解析结果，都可能参与最终表现。
4. 返回探测结果：内核记录一次请求的耗时。具体计时边界随实现变化，不宜把数值拆成固定的几个握手次数。

为什么常用返回 204 的地址

HTTP 状态码 204 表示请求成功，但没有响应正文。这样的探测传输量很小，适合频繁检查代理是否可用。代价也很明确：几乎没有大文件传输，测不出线路持续跑满后的吞吐能力，更测不出长视频播放十分钟后的稳定性。

第一次测试与后续测试还可能受到 DNS 缓存、连接复用和服务器缓存状态影响。不要只保留一次最低值；连续测几次，再看波动和失败次数，更接近实际使用条件。

延迟低却卡顿：五个常见原因

1. 小请求快，持续带宽不足

一条线路可以在 60 ms 左右完成小请求，却只有 2 Mbps 的可用吞吐。按十进制粗略计算，下载 3 MB 数据就需要约 12 秒，还没计入额外开销。另一条线路延迟 160 ms，却能持续传输 50 Mbps，大图片和视频通常反而更顺畅。

这里的 Mbps 是兆比特每秒，MB/s 是兆字节每秒，二者相差约 8 倍。例如 40 Mbps 理论上约等于 5 MB/s。比较客户端、浏览器和测速网站的读数时，先看单位。

2. 测试地址快，目标网站的路由不同

测试站点可能由 CDN 提供服务。CDN 是内容分发网络，会把请求交给某个边缘节点。代理访问这个边缘节点很快，不代表访问另一个地区的视频站、代码仓库或游戏服务同样快。

因此，“节点 A 测试 70 ms、节点 B 测试 130 ms”只说明它们在当时访问该测试地址的表现。若主要用途是下载代码，就应补测实际仓库；若主要看视频，就查看目标平台的缓冲速度、分辨率与丢帧情况。

3. 偶发丢包和晚高峰拥塞

单次探测恰好避开拥塞，会留下一个很好看的数字。但长连接遇到丢包后，可能重传、降速，甚至重新建立连接。若连续五次结果是 65、68、72、980 ms 和超时，问题不是“平均延迟略高”，而是稳定性不足。

晚上 20:00 的线路负载，也可能与上午 10:00 完全不同。尽量在实际使用时段比较，不要用清晨的一次结果替代晚高峰体验。

4. 实际流量没有经过被测试的节点

规则模式按规则和策略组决定出口。你测试了“自动选择”组，但目标域名可能命中另一个组，甚至命中 DIRECT，也就是直连。系统代理只影响遵循系统代理设置的应用；TUN 模式通过虚拟网络接口接管流量，但实际覆盖范围仍取决于路由和排除设置。

打开客户端的“连接”页，找到目标域名，检查命中规则、策略链和最终节点。这个步骤比反复点击测速更能解释“换节点了却没变化”。若列表没有请求记录，再检查应用是否走代理以及连接记录的筛选条件。

5. 页面慢在 DNS、应用或设备上

网页不只请求一个域名，还可能加载图片、脚本和登录接口。某个域名解析慢、扩展程序干扰、设备 CPU 占用过高，都会让页面卡顿。一次短小的 URL 探测不能覆盖这些问题。视频若已经缓冲充足却持续掉帧，也应检查硬件解码和设备负载，而不是只换节点。

url-test 配置：地址、间隔与容差分别控制什么

以下是 mihomo 代理组配置示例，假设配置中已经定义了名为“香港01”和“日本01”的代理。合并到现有 YAML 时，应保留原有节点定义和其他策略组，并让规则实际引用这个组。YAML 用缩进表达层级，不要用 Tab 代替空格。

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

tolerance: 50 不是给测试结果加减 50 ms，也不是保证低于 50 ms。它影响自动选择的切换判断。具体行为还与当前代理状态、是否探测成功及内核实现有关，不能只用两个静态读数预测每一次切换。

订阅更新可能覆盖直接编辑的代理组。需要长期调整时，优先使用客户端提供的覆写或合并配置功能，并检查最终生效配置。相关入口名称随客户端版本变化，不要只看编辑器里保存的内容。

用十分钟建立一组可比较的测试结果

不用一次测试全部节点。先选 2 至 3 个地区合适的候选节点，再按同一流程比较。下面的数值是用于解释判断方式的示例，并非本站实测报告。

1. 固定环境：使用同一台设备和同一网络，暂停大文件同步。先记录当前是系统代理还是 TUN，以及实际使用的策略组。
2. 确认出口：在“连接”页打开目标请求，确认最终节点。手动选择节点时，必须操作目标规则实际命中的策略组。
3. 重复探测：使用同一测试地址，每个节点测试 5 次，间隔约 5 至 10 秒。记下中位数、最高值和超时次数，不只记最低值。
4. 补测吞吐：用相同来源的较大文件下载 30 至 60 秒，观察稳定阶段的速度。确认文件不是直接从浏览器缓存读取，并留意订阅流量消耗。
5. 验证业务：打开实际使用的网站，或播放相同清晰度的视频 3 分钟。最后在常用时段再复测一次。

语音、远程操作等交互场景更在意延迟和抖动；视频与大文件更依赖持续吞吐；游戏还要单独验证 UDP 路径。HTTP 探测成功不能证明 UDP 可用，更不能代替游戏内延迟测试。

异常读数与自动选择：按现象排查

显示 timeout、负值或空白

这些通常表示探测失败、未取得有效结果或结果尚未刷新，具体显示由客户端决定。它不一定意味着节点完全不可用，也可能是测试地址不可达、超时阈值过短，或者代理协议配置不匹配。先手动打开一个实际目标，再查看客户端日志中的连接错误。分享日志前，遮住订阅链接、令牌和节点认证信息。

显示 0 ms，是否表示速度极快

不能这样判断。0 可能来自取整、界面初始值或某次异常结果，要结合客户端实现确认。重新测试，并查看实际请求的出口和耗时。跨地区代理出现长期固定的 0 ms，尤其值得检查测试是否真正执行。

自动选择总是选到“数字最低但不好用”的节点

url-test 主要按探测延迟工作，不会自动理解视频缓冲、带宽上限、服务地区限制或流量倍率。先缩小候选范围，只保留已经通过业务测试的节点，再交给自动选择。需要固定出口地区的服务，也应单独设置策略组，而不是让所有地区混在同一个自动组中。

改成全局模式会更快吗

全局模式改变的是流量选择策略，不会直接增加线路带宽。临时切换可以辅助判断分流规则是否影响结果，但测试后应恢复原来的规则模式，并在“连接”页核对出口。系统代理与 TUN 也不是单纯的“快慢开关”，应按应用是否需要接管来选择。