Clash 延迟测试原理

延迟数字衡量的是一次请求

Clash 客户端里常见的“测速”按钮，通常测试的是经某个代理访问指定 URL 所需的时间，而不是下载一段大文件计算带宽。界面显示的 80 ms、160 ms，是这条测试路径的耗时结果；它不能直接换算成每秒能下载多少 MB，也不能代表所有网站的响应时间。

客户端可能同时提供 TCP 连接测试、HTTP 延迟测试或单独的下载测速功能。本文讨论配置中的 url-test 与基于 HTTP 请求的节点延迟测试。不同客户端和内核版本的计时边界、连接复用方式可能不同，比较之前应先确认测试类型一致。

url-test 请求经过哪些环节

以常见的 HTTPS 测试地址 https://www.gstatic.com/generate_204 为例，内核会通过被测试的代理发起 HTTP 请求。该地址通常返回 HTTP 204，没有需要持续下载的正文，适合做轻量可达性与响应时间检查。它不是带宽测试文件，也不保证在任何网络环境下都可用。

1. 准备连接目标。客户端需要知道代理服务器地址；如果服务器使用域名，建立连接前可能涉及 DNS 解析。测试目标域名由本地还是远端解析，则取决于代理协议与内核 DNS 配置。
2. 连接代理入口。本地网络到代理服务器之间需要建立传输连接。TCP 型协议可能涉及 TCP 握手，部分协议还需要 TLS 握手或认证；基于其他传输的协议不能机械地按相同流程计算。
3. 建立目标访问通道。代理出口继续连接测试站点。入口很近，并不意味着代理出口到目标站点也很近；跨区域绕行或出口拥塞仍会增加等待。
4. 发送请求并等待响应。测试在内核定义的计时边界内完成，随后把耗时交给客户端展示。证书验证失败、连接被重置或等待超过限制，都可能表现为失败，而不是一个有效的毫秒数。

因此，HTTP 延迟既不是单纯的“本机到服务器 ping”，也不应被解释成所有握手耗时的固定总和。DNS 缓存、TLS 会话恢复、底层连接复用和内核实现都会影响结果。第一次测出 230 ms，接着变成 120 ms，并不足以证明线路刚刚获得了带宽提升。

为什么 ping 的数字更低

命令行 ping 通常发送 ICMP 回显请求，测量到指定主机的往返时间。它没有完成上述 HTTP 请求，也通常不会经由系统 HTTP 代理。服务器还可能限制 ICMP，却允许代理服务正常工作。因此，ping 不通不能直接判定节点不可用，ping 低也不能保证 HTTPS 页面打开快。

测试地址决定了比较对象

节点测试访问的是测试地址，浏览器访问的却可能是视频站、代码仓库或会议服务器。这些目标的 CDN 分布、回源位置、运营商互联情况都不同。某条线路连接测试站只需 60 ms，访问工作所需站点却要绕行；另一条线路测试为 110 ms，却可能有更好的实际业务路径。

• 横向比较要使用同一个地址。把节点 A 的测试目标设为一个站点、节点 B 设为另一个站点，得到的数值不能公平排序。
• 地址异常要单独判断。测试域名解析失败、证书时间校验失败或服务端限流，都可能导致多个节点同时超时。此时应先换一个稳定的小响应 HTTPS 地址复测。
• 状态码需要结合配置。部分内核或客户端允许设置预期响应状态。收到重定向、验证页面或非预期状态时，“有响应”与“测试成功”可能不是同一件事。
• 业务验证不可省略。选定候选节点后，再打开实际要用的网站，检查登录、图片、视频片段和长连接，而不只是停留在客户端列表。

低延迟为什么仍然下载慢

轻量请求主要暴露建立连接与等待响应的成本，持续下载则更依赖可用带宽、拥塞控制、链路丢包和服务端供给能力。一个小响应可以很快返回，但同一条链路连续传输 500 MB 时，可能很快触及出口限速。

用一组示例区分延迟与吞吐

假设节点 A 的 HTTP 延迟为 65 ms，持续下载速度为 2 MB/s；节点 B 的 HTTP 延迟为 140 ms，持续下载速度为 15 MB/s。这是一组解释指标差异的示例，不是线路实测排名。对短小网页请求，A 可能更快开始响应；对大文件或高码率视频，B 更可能提供足够吞吐。若站点还有限速，两者也可能都受制于源站。

“延迟低所以一定快”忽略了传输规模。“下载快所以一定适合会议”则忽略了稳定性、上行能力和实时业务路径。应先确定用途，再选择指标，而不是把所有表现合并成一个排行榜。

抖动与丢包怎样影响体验

一次最低延迟容易掩盖波动。例如连续五次结果为 78、82、80、460、85 ms，中间的 460 ms 已经值得关注。它可能来自无线网络竞争、排队、重传或测试站点短暂变慢；仅凭这五次 HTTP 请求，不能断言底层网络丢包率是多少。

对于需要可靠传输的连接，数据丢失可能触发重传并影响拥塞窗口，使长时间下载明显变慢。实时音视频则可能表现为声音断续、画面冻结或缓冲增加。不同应用对恢复与缓冲的处理不同，所以同一节点可能适合看有缓冲的视频，却不适合实时会议。

• 用连续 5 至 10 次测试观察中位数、最大值和失败次数，不只记住最低值。
• 若 10 次 HTTP 测试失败 2 次，可以记作“本轮请求失败 2/10”，不要写成“链路丢包率 20%”。
• 分别在空闲和晚间常用时段测试；若只在晚间变差，进一步比较本地宽带与代理出口的负载。
• 测试时暂停云盘同步、大文件下载与其他测速任务，避免自己的流量制造排队。

url-test 自动选择并不等于带宽优选

在 Clash 与 Clash Meta（现常称 mihomo）配置中，url-test 代理组会依据指定 URL 的延迟测试结果选择成员。它不会因为名称里有“测速”，就自动下载大文件并比较带宽。若目标是手动固定某条线路，应使用手动选择组；若使用自动测试组，就要接受它主要依据延迟做决策。

下面是代理组片段示例，假定当前配置中已经存在名为“香港 A”和“日本 B”的代理。实际使用时，应把成员名改为现有配置里的准确名称，并合并到已有的 proxy-groups 列表，不能把整个配置文件替换成这一段。

proxy-groups:
  - name: 延迟优选
    type: url-test
    proxies:
      - 香港 A
      - 日本 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• interval: 300 表示配置的测试间隔为 300 秒。实际调度还可能受到内核惰性测试等机制影响，不应把它理解成任何时候都精确执行的定时器。
• tolerance: 50 以毫秒为单位，为自动选择提供切换容差，减少几毫秒差异带来的频繁切换。具体行为以所用内核版本为准。
• 配置组存在还不够，业务规则必须引用这个组，或者上层手动选择组必须选中它，实际连接才会使用其选择结果。

自动组重新选中成员，通常不意味着所有已建立连接立即迁移。旧连接可能继续使用原出口，新连接才走新的选择。排查时应在客户端“连接”页面查看目标域名、规则命中与代理链，而不是只看组名旁边的当前节点。

按相同条件验证真实速度

多数客户端可在“代理”页面选择节点并执行延迟测试，再在“连接”或“日志”页面确认请求路径；这些是常见入口名称，并非所有客户端都使用完全相同的菜单。系统代理模式与 TUN 模式的流量接管范围也不同，测试时应保持模式一致。

1. 先固定网络。使用同一台设备、同一条宽带和相同 Wi-Fi 频段；有条件时用网线复测。不要把手机蜂窝网络结果与电脑 Wi-Fi 结果直接比较。
2. 确认业务确实走代理。在“连接”页面查找测试站点，核对出口不是 DIRECT，并确认实际节点。内核内置延迟探测通常会指定待测代理，它成功不代表浏览器流量已经被正确接管。
3. 记录轻量请求。用相同 URL 连续测试 5 至 10 次，记录典型耗时、明显峰值与失败次数。不要同时对大量节点密集测试。
4. 再测持续吞吐。选一个有足够带宽的固定来源，单独下载约 30 秒，观察稳定阶段速度。比较时保持文件、来源与并发数相同，并注意套餐流量消耗。
5. 最后测试真实任务。视频观察缓冲和播放稳定性，会议检查上行与声音连续性，代码仓库则分别测试页面打开和文件下载。一次验证只改一个变量。

选择节点时，先用延迟测试筛掉当前不可达或明显异常的候选，再看波动、持续吞吐和实际应用表现。对网页浏览，响应时间很重要；对大文件，带宽更关键；对实时通信，稳定性和上行同样重要。把这些指标分开记录，才能解释为什么客户端数字很好看，实际体验却没有同步改善。