原理进阶 预计阅读 12 分钟

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

解释客户端延迟测试测的是什么、测试地址与超时设置如何影响数值，以及握手延迟、带宽与线路拥塞之间的区别，帮助读者正确看待测速结果。

一、URL Test 测的是请求耗时，不是下载带宽

Clash Nyanpasu 等客户端里，节点旁显示的毫秒数通常来自内核的 URL Test：通过指定代理访问一个测试地址，记录这次探测完成所需的时间。它不是对节点服务器执行一次普通 ICMP Ping，也不是下载大文件后计算吞吐量。判断“这个节点快不快”之前，先确认界面显示的是哪一种测试结果。

以常见的 HTTPS 轻量探测为例，请求可能涉及代理连接建立、代理协议握手、目标站点连接、TLS 握手和 HTTP 响应。域名解析发生在哪一端、连接能否复用，以及内核版本和延迟统计设置，都会影响最终数值。因此不能把界面上的 180 ms 简单理解为“本机到节点服务器的往返延迟”。

先看单位：ms 表示时间，MB/s 或 Mbps 表示传输速率。短请求只传输少量数据，无法据此推导线路可以持续承载多少流量。

三种“测速”回答不同问题

测试类型主要观察对象不能直接证明什么
ICMP Ping目标主机的 ICMP 响应时间与丢包代理协议可用、目标网站能访问
URL Test经代理完成指定 URL 探测的耗时持续带宽、视频播放稳定性
持续下载特定文件、时段和连接数下的吞吐量所有网站、所有协议都有相同速度

即使服务器禁止 ICMP，它也可能正常提供代理服务；反过来，服务器可以 Ping 通，代理端口却可能不可用。排查 Clash 节点时，用 URL Test 判断代理路径，比只看 Ping 更贴近实际访问，但仍然需要业务测试补充。

二、低延迟却下载慢：握手、带宽与拥塞的区别

延迟可以理解为一次交互等待多久，带宽则描述单位时间内能传输多少数据。一个小型探测响应可能只有响应头，即使出口带宽不高，也能很快返回；下载数百 MB 的文件时，线路限速、共享出口负载和目标服务器限速才会充分显现。

用一组示意数据看差异

下面的数据用于说明判断方法，不是对任何服务的实测承诺。假设同一设备、同一测试地址、同一时段得到这些结果：

观察项目节点 A节点 B
五次 URL Test 中位数85 ms165 ms
单连接下载稳定速率1.2 MB/s9.0 MB/s
五次测试的最大值900 ms190 ms

如果任务是下载大文件，节点 B 更值得尝试；如果是少量短请求，节点 A 在低负载时可能响应更快，但它的最大耗时提示稳定性还需观察。1.2 MB/s 约等于 9.6 Mbps，9.0 MB/s 约等于 72 Mbps，比较前还要统一字节与比特单位。

  • 网页首次打开：受 DNS、连接握手、首字节和多个资源请求影响，延迟较重要。
  • 大文件下载：持续吞吐量、丢包后的重传和服务器限制更重要。
  • 视频播放：需要足够且稳定的吞吐量；短时峰值高，不代表缓冲能一直跟上。
  • 实时交互：除了平均延迟，还要看抖动、丢包及实际使用的 UDP 路径。

晚高峰拥塞常同时拉高延迟并降低吞吐量，但也可能只在持续传输时暴露。一次空闲状态下的 80 ms 探测，不能代表接下来十分钟的线路负载。

三、测试地址和超时为什么会改变排名

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

URL Test 不是只到代理入口就结束，它还涉及代理出口到测试目标的路径。更换测试域名，可能改变 CDN 落点、解析结果、TLS 行为以及出口路由。某节点到测试站点很近，并不代表它到代码托管站、流媒体或办公系统也近。

常见的轻量测试地址返回 HTTP 204，目的是减少响应内容对结果的干扰。例如 https://www.gstatic.com/generate_204 可作为一种探测选择，但不能保证它在所有出口和网络环境下都可用。不要把需要登录、存在验证码或频繁跳转的页面作为通用探测目标。

  • 横向比较节点时，保持 URL、协议和超时一致。
  • 排查具体网站时，另测该网站的实际请求，不用通用探测值替代。
  • 批量测试同时失败时，先核实测试站点本身是否可达。
  • 不要通过改成更容易响应的地址，把真实业务失败掩盖成“节点正常”。

超时是等待上限，不是节点的延迟值

假设两次测试的等待上限分别为 3000 ms 和 10000 ms，一个需要 4200 ms 才完成探测的节点，前者会失败，后者可能返回有效结果。延长等待只是让结果有机会返回，并没有让线路变快。客户端显示“超时”也不等于节点已经永久失效，它只说明本次探测没有在限定条件内成功完成。

失败还可能来自域名解析、TLS、连接拒绝或测试目标限制，需要结合内核日志区分。不同客户端的手动测试、策略组健康检查以及 provider 健康检查，可能使用不同参数；不要假定修改一个界面选项就会影响全部探测。

四、mihomo 的 url-test 策略组如何配置

url-test 策略组会根据探测结果自动选择候选代理，适合把“优先低延迟”交给内核处理。下面是配置片段，假设完整配置的 proxies 中已经存在名为“香港入口 A”和“日本入口 B”的两个代理。请先备份配置，再通过客户端支持的配置编辑或覆写方式合并，不能把片段当作完整订阅直接导入。

proxy-groups:
  - name: 自动延迟
    type: url-test
    proxies:
      - 香港入口 A
      - 日本入口 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  • interval: 300：检查间隔为 300 秒，不是 300 毫秒。
  • tolerance: 50：切换容差为 50 毫秒，用于减少小幅延迟差造成的频繁切换；它不是超时参数。
  • lazy: true：未使用该组时可避免持续执行周期性测试，不应因此期待后台始终保留最新探测值。
  • proxies：引用已经定义的代理或策略名称，拼写必须与配置一致。

该组只有被规则或上层策略组选中时，才会参与对应连接的出口选择。创建了组却没有引用它，浏览器流量不会自动改走这个组。对于已经建立的下载或长连接，策略变化通常也不会把现有连接无缝迁移到另一个节点，需要新建连接后再观察。

自动选择不等于带宽排名：url-test 依据探测延迟选路，不会自动下载大文件测出各节点的持续带宽。下载任务可以用手动选择组固定节点，再单独比较吞吐量。

如果候选节点来自 proxy-providers，还要检查 provider 的 health-check 配置。它和策略组的探测有各自的职责与参数。订阅更新可能覆盖直接编辑的内容，持久调整应使用当前客户端支持的覆写机制，并在加载后检查实际生效的配置。

五、统一条件：一次可复现的节点对比流程

  1. 固定网络环境。同一台设备、同一 Wi-Fi 或网线测试；暂停系统更新、网盘同步和其他大下载，避免本地带宽被占用。
  2. 确认业务走向。在连接列表中检查目标域名命中了哪条规则、最终选择了哪个代理。规则模式下，测试网站可能直连，而延迟探测仍通过候选节点进行，两者不能直接比较。
  3. 固定候选节点。暂时使用手动选择，避免自动组在测试过程中切换。每次切换后新建业务连接，必要时停止旧下载再重新开始。
  4. 重复轻量探测。每个节点做 5 次，间隔约 5 秒，记录成功次数、中位数和最大值。不要只保留最低的一次。
  5. 补充业务测试。同一下载地址分别进行约 30 秒的单连接传输，观察稳定阶段；多连接结果另外记录，不与单连接混算。
  6. 跨时段复查。在白天和晚高峰各测一轮。如果只有晚高峰明显下降，优先考虑负载和路由拥塞，而不是反复重装客户端。

用 curl 检查指定本地 HTTP 代理

以下命令假设配置的 mixed-port 为 7890，且允许本机访问、没有额外代理认证。若端口不同，应以当前生效配置为准。Windows PowerShell 可使用 curl.exe，避免旧环境中的同名命令别名影响参数解析。

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

上面的输出文件写法适用于 macOS 和 Linux；Windows 使用时把 /dev/null 改成 NUL。--connect-timeout 5 设置连接阶段的等待限制，--max-time 10 限制整个请求最多 10 秒，输出时间单位为秒。这个命令测到的是 curl 经本地代理的请求表现，不保证与内核 URL Test 的毫秒数完全相同。

测试结果必须和连接列表一起读：本地 HTTP 代理收到请求后，内核仍会按当前模式和规则选择出口。仅仅写了 --proxy，并不能证明一定使用了准备比较的远端节点。

六、常见异常：从超时到视频卡顿

所有节点突然超时

先确认当前网络能正常访问基础服务，再检查订阅中的服务器地址是否解析成功、测试目标是否可达，以及日志是否出现连接拒绝或 TLS 错误。可以用另一个稳定的轻量 HTTPS 地址做交叉验证。一次批量失败不足以判断所有节点同时失效，也不适合立刻删除全部配置。

显示 60 ms，打开网页却要几秒

首先看网页是否实际走了这个节点，再看浏览器是否复用了旧连接。网页可能加载数十个第三方资源，某个域名的解析或请求阻塞就能拖慢整页。浏览器开发者工具的网络面板可区分等待首字节与内容下载，帮助判断是握手慢、服务器响应慢还是传输慢。

测速正常，视频仍持续缓冲

用视频服务自身的连接速度、缓冲长度等统计观察，不要只看 Clash 延迟。媒体 CDN 与探测站点走的路径可能不同，出口也可能受特定服务限制。若 HTTP 探测成功但实际业务使用 UDP 或 QUIC，还要分别确认该路径是否受支持；一个 HTTPS 探测无法验证全部协议。

开启 TUN 后数值或业务表现变化

TUN 改变的是流量接管方式，并不会直接增加线路带宽。切换前后应检查 DNS 接管、路由和其他代理软件是否冲突。内核自身的节点探测与应用经 TUN 进入内核的业务流量，并不一定经过完全相同的本地路径，因此要以实际连接记录解释差异。

七、节点选择：先可用，再稳定，最后看任务

日常选节点可以按三个层次判断：先确认目标业务能访问，再比较重复探测的成功率和波动，最后根据网页、下载或视频需求补测。一个 150 ms 且稳定的节点，往往比偶尔 50 ms、经常超时的节点更适合持续使用。

  • 网页与办公：关注连续多次的请求耗时和业务成功率。
  • 下载与更新：关注同源、同连接数下的持续速率。
  • 视频与会议：关注缓冲、抖动、丢包及对应协议的实际表现。

把 URL Test 当作“指定目标下的轻量可用性与延迟探测”，就不容易被单个数字误导。修改测试地址、超时或策略组之前，先保留原始条件和对比记录；每次只改变一项，才能判断改善来自配置调整，还是恰好遇到了线路负载变化。

Clash 客户端下载