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

延迟数字测的是请求耗时，不是下载速度

在 Clash for Windows 的 Proxies 页面点测试按钮，节点旁通常会出现以毫秒为单位的数值。这个数字适合回答“通过这条代理访问测试地址，要等多久”，不能直接回答“下载文件每秒能跑多少”。面板上的 80 ms 和下载器里的 8 MB/s，是两个不同维度。

Clash 常见的延迟测试属于经代理发出的 HTTP 请求测试，不等同于命令行里的 ICMP ping。它会让指定代理承载到测试 URL 的请求，再记录耗时。内核版本、协议、连接复用和测试实现不同，计时涉及的具体阶段也可能不同，不能把所有客户端的数字都当作完全一致的测量口径。

例如，一条线路首个小请求很快，却在大文件传输时被限速；另一条线路跨洲往返较慢，但持续带宽充足。前者可能显示更低的延迟，后者下载反而更快。这并不矛盾。

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

从本机内核到测试站点

典型路径是“本机 Clash 内核 → 代理服务器或代理链 → 测试站点 → 返回本机”。测试需要建立或利用代理传输，再访问指定 URL。使用 HTTPS 地址时，还会涉及到目标站点的 TLS 过程；域名解析发生在哪里，则取决于代理协议、DNS 设置以及具体连接路径。

1. 选择被测代理：核心针对节点发起测试；如果测试对象是策略组，还要看该组如何选择实际出口。
2. 建立连接并发送请求：本机网络、代理握手、出口到目标站点的路径都可能影响耗时。
3. 判断请求结果：成功后返回延迟；失败、状态不符合要求或超过等待期限时，界面可能显示超时或错误。

测试地址常使用返回 HTTP 204 的轻量接口。204 表示没有响应正文，适合减少大文件传输对测量的干扰。它的特点也决定了测试局限：几乎不传正文，就很难反映持续带宽。不要把这种测试解释成“已经测过下载速度”。

测试按钮与自动选择组不是同一个入口

面板点一次测速，通常是由客户端调用核心的延迟接口；配置中的 type: url-test 则定义一个按测试结果自动选择代理的策略组。两者可能使用不同的测试 URL、超时参数和触发时机。改了策略组里的 url，不代表面板测试按钮一定跟着改变。

url-test 配置：地址、间隔与切换容差

下面是一个用于解释字段的策略组片段，写法面向 mihomo。它不是完整订阅；proxies 中的节点名称必须已经存在于当前配置中。旧版 Clash 核心与不同分支的支持字段有差别，复制前应查对应核心的配置说明。

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

• url：测试目标。示例使用轻量 HTTPS 接口，目标站点可用性与可达路径会影响结果，不保证任何网络下都可用。
• interval: 300：周期测试间隔为 300 秒，不是每个请求允许等待 300 秒，也不代表节点卡住后立刻切换。
• tolerance: 50：切换容差为 50 毫秒，用于减少小幅延迟差异引发的频繁切换；它不是带宽门槛。
• lazy: true：按组是否处于使用状态等条件决定是否执行周期检查，具体行为以核心实现为准。因此，不使用时面板里的历史数值可能没有刷新。

自动选择组主要根据延迟与可用性做判断，不会因为某条线路下载更快就自动给它更高排名。选择结果也不意味着已经建立的连接全部迁移到新节点；长连接往往会继续沿用原连接，刷新网页或新建连接才更容易看到切换效果。

超时阈值与测试间隔要分开看

以兼容的核心控制 API 为例，单节点延迟接口可使用如下请求形式。这里的 timeout=5000 表示等待上限为 5000 毫秒，和策略组的周期参数不是一回事。端口 9090 只是示例控制端口，不是代理端口。

GET /proxies/香港入口/delay?url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204&timeout=5000

实际调用时，节点名需要进行 URL 编码，还要按本机配置带上控制接口认证。排查通常用客户端界面就够了，不必为了测速把控制端口开放到局域网。若需要查看配置字段，可对照配置参考，不要把控制端口、HTTP 代理端口与 SOCKS 端口混用。

低延迟仍然卡顿的五类原因

1. 测试站点近，实际服务的路径不同

同一出口访问轻量测试接口，可能命中附近 CDN；访问视频、代码仓库或文件站时，却被分配到另一地区。小请求顺利，并不保证实际服务走相同线路。跨地区访问还可能遇到不同的回程、互联拥塞或服务端限制。

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

连接握手只需要少量数据，线路即使限速也可能迅速完成。开始下载后，带宽限制、共享出口拥塞和服务器负载才会明显。需要比较吞吐量时，要使用同一来源、相近时间和相同下载方式，不能拿两个不同文件站的速度直接判断节点优劣。

3. 单次延迟低，但波动很大

一次 65 ms 不能说明线路稳定。连续请求若出现 70、75、820 ms，并夹杂失败，网页会表现为偶尔突然停住。TCP 重传会拉长等待时间，而持续数据流对丢包与抖动也很敏感。观察一组记录，比反复寻找最低数字更有用。

4. 实际应用没有走被测节点

在 Clash for Windows 中，先看 General → System Proxy 是否开启，再到 Proxies → Rule 确认规则模式和目标策略组。遵循 Windows 系统代理的程序通常会使用该入口，但自带网络栈的程序可能忽略系统代理。

打开 Connections，按目标域名查连接，核对命中的规则与代理链。手动测的是“日本入口”，实际连接却命中 DIRECT，两者当然对不上。自动选择组、手动选择组和规则分流还可能层层嵌套，不能只看一个卡片上的名称。

5. UDP、DNS 或应用机制与测试不同

一次 HTTPS 测试不能证明 UDP 转发可用。游戏、语音和采用 QUIC 的应用可能需要另一条协议路径。浏览器缓存、连接复用、DNS 缓存及网站自身响应也会改变体感。TUN 可以接管更多不遵循系统代理的连接，但不会凭空增加出口带宽，也不保证所有流量都走代理；最终仍取决于路由、规则和排除设置。

节点显示 timeout：按范围定位

timeout 只说明这次测试没有在指定条件与时间内成功，不能直接推出“节点永久失效”。先看问题影响一个节点、一个测试地址，还是整个网络。

1. 全部节点同时失败：先确认本机网络正常、核心正在运行，检查测试 URL 能否通过已知可用的路径访问，再看日志里有没有 DNS 或连接错误。
2. 只有一个节点失败：检查订阅是否更新、节点认证信息是否失效，以及该协议是否被当前核心支持。更新订阅后重新选择一次实际节点。
3. 换一个测试地址就成功：更可能是原测试目标、证书、解析或路径问题。比较时让所有节点使用同一个新地址，避免口径不一致。
4. 等待上限太短：若入口允许调整，可将 3000 毫秒临时改为 5000 毫秒再试。延长等待只能帮助识别慢响应，不会修复拥塞或让线路变快。
5. 测速成功但网页失败：立即转查目标站点、规则命中和应用路径，不要一直重复点击同一个测速按钮。

更贴近实际体验的节点比较方法

准备两到三个候选节点即可。暂停系统更新和大文件同步，尽量保持同一种联网方式；如果使用 Wi-Fi，测试期间不要换位置。记录客户端、核心、测试 URL 和时间段，才能知道前后比较是否有效。

1. 固定代理路径：暂时在手动选择组中指定一个节点，确认目标应用的连接确实经过它，避免自动切换干扰。
2. 重复轻量测试：同一地址测 5 至 10 次，间隔几秒，记录中位数、最高值与失败次数，不只看最低值。
3. 打开实际网站：访问每天使用的两三个服务，观察首次打开与刷新是否稳定。浏览器开发者工具的“网络”面板可辅助查看请求耗时，但缓存与服务器处理时间也在其中。
4. 单独测试持续传输：选择允许下载的固定文件源，连续观察 30 至 60 秒。注意流量消耗，保持相同的并发连接数，并说明记录单位是 MB/s 还是 Mbps。
5. 回到使用时段复测：工作日白天与晚间拥塞情况可能不同，保留两个时间段的记录比单次排名更可靠。

下面只是用于说明判断方法的假设记录，并非本站实测。两条线路都成功完成 10 次轻量请求，但选择可能因任务而异：

聊天、远程交互和网页操作通常更关心响应与稳定性；下载更看重持续吞吐量；视频则还受码率、自适应缓冲和 CDN 分配影响。单位也别看错：理论上 8 Mbps 约等于 1 MB/s，实际有效速度还会扣除协议开销。

旧版 Clash for Windows 的使用边界

Clash for Windows 已停止维护。保留旧环境时，可以沿着 General、Proxies、Connections、Logs 这几个入口检查运行状态、规则命中和错误信息，但不要默认旧核心支持新订阅中的所有协议或 mihomo 字段。界面能导入订阅，不等于每个节点都能正常工作。

新安装可先在客户端对比中核对 Clash Verge Rev、FlClash 等仍在维护项目的当前状态、平台覆盖和核心支持。更换客户端后，要重新确认系统代理、监听端口与测试地址，不能拿旧客户端遗留的历史数字直接比较。

最终判断顺序：先确认连接走对节点，再核对测试口径，然后看多次请求的稳定程度，最后用实际任务验证带宽与体验。url-test 适合筛选可用出口；它提供的是一项测量结果，而不是整条线路的综合评分。