Clash 延迟测试数值怎么看:url-test 测速原理与实际体验的差距

延迟数字：一次探测耗时，不是下载速度

客户端显示的 80 ms、230 ms，通常来自内核经指定节点向测试地址发起的一次 HTTP 或 HTTPS 探测。它回答的是“这次请求多久得到符合测试条件的响应”，而不是“这条线路每秒能传多少数据”。界面按钮即使叫“测速”，也不一定进行大文件下载。

先区分三个指标：延迟看一次交互的等待时间，吞吐量看持续传输能力，稳定性看多次请求之间的波动与失败情况。低延迟适合频繁的小请求，但无法单独证明视频加载、大文件下载或长连接质量更好。

url-test 原理：经候选节点访问测试地址

url-test 是策略组类型。内核对组内候选出站进行 URL 探测，再依据可用性、延迟及切换容差选择出站。客户端上的手动延迟按钮与策略组的定时探测可能使用不同地址、超时设置或调用方式，不能仅凭界面数字判断自动选择是否异常。

一条探测链路包含什么

1. 解析与连接准备：节点服务器域名需要解析；目标域名由本地还是远端解析，取决于协议、DNS 配置与具体实现。
2. 建立代理通道：连接到节点，完成该协议所需的握手，再由节点访问测试目标。存在中转时，还会经过中转链路。
3. 请求测试资源：HTTPS 地址通常还涉及 TLS 握手，然后发送 HTTP 请求并等待响应。
4. 记录结果：探测成功后得到耗时；连接失败、超时或响应不满足测试条件时，可能显示失败、不可用或超时。

这里描述的是请求经过的环节，不代表每一种内核都把每个环节完整计入同一个数字。DNS 缓存、连接复用、协议实现和计时起止点都会影响结果。因此，Clash、Clash Meta（mihomo）以及不同客户端界面的数值，应在相同测试条件下比较，不宜直接横向拼接。

这也不是传统的 ICMP ping。服务器禁用 ICMP，不等于 HTTP 探测无法成功；能 ping 通服务器，也不等于代理认证、协议握手与目标站访问都正常。

探测不会替代真实业务规则

策略组测试会按候选出站执行探测，不是先把测试 URL 当普通浏览请求交给整份 rules 再判断节点。实际浏览器连接则仍受运行模式、规则命中及策略组选择影响。测试的是节点 A，而网页最终命中 DIRECT 或另一个组时，两者体验当然可能不同。

低延迟仍卡顿：四类链路差异

小响应快，持续传输慢

常见的 generate_204 地址返回很小的响应，适合轻量可用性探测。它几乎不考验持续吞吐量。节点带宽拥挤、单连接限速或出口负载偏高时，小请求仍可能很快，大文件却传不动。

例如，下面是一组用于解释指标的假设记录，并非本站实测：A 节点探测为 65 ms，下载为 1.2 MB/s；B 节点探测为 140 ms，下载为 8 MB/s。A 的短请求响应更快，但下载同一文件时，B 完成得可能更早。

测试站点近，业务站点远

测试地址经常由 CDN 提供服务。不同出口地区可能命中不同机房，探测优秀只代表到该目标的路径表现。访问另一个地区的代码仓库、视频服务或企业后台时，出口之后的路由、互联质量和服务器负载都可能变化。

一次数字低，连续请求不稳定

如果同一节点连续出现 70、75、620、超时、82 ms，只看最后一次 82 ms 会漏掉明显波动。丢包可能触发重传，尤其影响 TLS 建连、网页资源并发加载与长时间传输。这里的“超时”是应用层探测失败，不应直接当作 ICMP 丢包率。

业务使用 UDP 或不同连接方式

HTTP 探测成功不能证明 UDP 转发可用。语音、游戏或使用 QUIC 的业务还受到协议 UDP 支持、服务端设置、客户端接管方式与防火墙影响。启用 TUN 也不会凭空增加节点带宽；它主要改变流量如何进入客户端，不能保证所有业务都与 HTTP 探测走相同路径。

配置 url-test：先固定地址与测试周期

以下是面向 mihomo 的策略组片段，不是可直接独立运行的完整配置。现有 proxies 中需要已经定义名为“香港-A”和“香港-B”的节点；合并时使用自己的真实节点名称。不要在文件末尾再添加第二个同名顶层 proxy-groups 字段。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 香港-A
      - 香港-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

• type: url-test：根据 URL 探测结果选择候选出站，不是带宽测速组。
• url：本组的探测目标。上例是常见的轻量 HTTPS 测试端点，实际可达性仍需在当前网络验证。
• interval: 300：定时探测周期为 300 秒，也就是 5 分钟，不是 300 毫秒。
• tolerance: 80：切换容差为 80 毫秒，用于减少因小幅延迟差异而发生的切换。
• lazy: true：按 mihomo 的懒惰探测机制，未使用的组可能不持续执行周期测试；观察时不要假定它一直在后台刷新。

订阅供应商可能还通过 proxy-providers 的 health-check 配置健康检查。提供者的检查周期、策略组的 interval、客户端界面的手动测试，是不同配置入口；只改其中一个，不代表所有显示和测试行为都会同步改变。

tolerance 怎么设：减少小差异切换

tolerance 不是“允许的最高延迟”，也不是“低于这个值就算通过”。它控制当前选择与更快候选之间的切换容差。理解为：候选节点只快一点时，优先保留当前可用节点；快到超过设定差距时，才有理由切换。

以常见的 mihomo 选择逻辑举例：当前节点为 150 ms，候选为 110 ms，差距只有 40 ms。设置 tolerance: 80 时，通常不会仅因这点优势切换；候选变为 60 ms，差距达到 90 ms，才超过这项容差。具体选择仍受当前节点可用性、有效测试结果及内核实现影响。

调整顺序比单个数值重要

1. 先固定测试地址和网络环境，确认节点没有频繁探测失败。
2. 可从 50 到 100 毫秒的容差范围开始观察；这只是配置起点，不是适用于全部线路的标准。
3. 若候选延迟接近却经常来回切换，适度增加容差；若明显更快的节点长期没有被选中，再核对差值与当前有效结果。
4. 若当前节点已经不可用，重点排查健康检查与失败识别，不要把容差当成保留故障节点的规则。

切换策略通常影响后续新建连接，既有 TCP 连接不会因此无缝迁移到另一节点。一次切换后，旧下载仍慢、新网页却变快，并不矛盾。也不建议把 interval 改成 1 秒反复测试：探测本身会产生连接与流量，过密检查可能增加负载，却无法消除真实线路波动。

测试地址怎么选：轻量、稳定、用途一致

测试地址应长期可访问，响应体尽量小，不要求登录，不依赖短期签名，也尽量避免多次跳转。用完整视频页面、大文件或带验证码的网页做健康检查，容易把页面行为误判成网络故障。

https://www.gstatic.com/generate_204 可作为起始测试地址，但不是适合所有网络的唯一答案。若它在某条出口上异常，应核对日志、目标可达性和返回状态，再换另一个稳定的小响应端点复核。单个地址失败，不足以宣布所有业务都不可用。

HTTP 与 HTTPS 的测试值也不应混在一起排名。HTTPS 通常多了 TLS 相关开销；把地址改为 HTTP 后数字下降，不等于节点线路得到改善。需要贴近特定业务时，可以额外验证业务站点的首次响应，但不要把带登录态的业务页面直接用作全组常驻健康检查。

实际体验对照：按同一条路径复测

排查“延迟低但网页慢”，先确保探测结果与真实请求指向同一个出站，再讨论 DNS、吞吐量和目标服务。客户端菜单名称会变化，下列步骤以功能入口为准，不依赖某一个版本的界面布局。

1. 确认运行模式：需要按规则分流时检查 mode: rule，并确认当前启用的是刚修改的配置，而非另一份 Profile。
2. 确认连接归属：打开客户端的连接列表，访问目标站，查看对应连接的命中规则、策略组及实际出站。必要时结合日志排查。
3. 临时固定节点：通过可手动选择的策略组固定 A 节点，避免比较过程中自动切换；测试结束后再恢复原策略。
4. 记录连续样本：同一网络下对同一地址测试 10 次，记录中位数、最大值和失败次数。失败单独统计，不要按 0 ms 纳入平均值。
5. 补充业务测试：在同一站点下载同一文件 30 秒，记录稳定阶段速度；视频业务则观察缓冲、拖动后恢复和持续播放情况。
6. 单独检查接管：若只在 TUN 下异常，检查 DNS、路由与 UDP 支持；若系统代理下业务未进入连接列表，先确认应用是否遵循系统代理。

本机代理入口也要核实。例如配置使用 mixed-port: 7890 时，测试工具应连接当前客户端实际监听的 127.0.0.1:7890；不要把其他客户端留下的 7897 或 1080 当成通用端口。端口是否可用，以生效配置和监听状态为准。

完成对照后，按故障类型处理：探测稳定但大文件慢，优先看吞吐与拥塞；只有个别站点慢，优先看目标路径与规则；出现周期性失败，检查网络波动和节点状态。延迟数字适合筛选候选，真实业务测试负责做最后决定。

常见问题：超时、手动测试与自动选择