节点延迟数值如何测出:URL 测速原理与实际网速体验的差距

1. 面板上的毫秒数，不是下载速度

Clash 客户端代理页显示的 120 ms，通常来自内核经指定节点发起的一次 URL 探测。它回答的是“这条代理路径完成这次小请求需要多久”，不是“每秒能下载多少数据”。手动点击测速、订阅节点健康检查、url-test 自动选择，可能使用不同的测速地址和超时设置，比较前要先核对来源。

延迟的单位是毫秒，吞吐量常用 Mbps 或 MB/s。假设节点甲探测结果为 80 ms、下载速度为 2 MB/s，节点乙为 160 ms、下载速度为 15 MB/s：甲可能更适合频繁发起小请求，乙可能更适合大文件下载。这里的数字只是解释指标差异的示例，不是线路实测或性能承诺。

2. url-test 请求经过哪些阶段

以经代理访问 https://www.gstatic.com/generate_204 为例，逻辑路径是：客户端内核 → 代理服务器或代理链 → 测速站点 → 返回响应。这个地址通常返回 HTTP 204，没有用于测量持续吞吐量的大响应体，因此适合做轻量可达性探测。

1. 准备目标和连接信息。解析代理服务器地址，准备测速目标的域名或地址。解析发生在本机还是远端，取决于协议、DNS 配置及拨号路径。
2. 建立到代理的连接。根据节点协议，可能涉及 TCP 建连、TLS、WebSocket，或基于 UDP 的传输握手。不同协议的成本不完全相同。
3. 建立到目标的访问路径。代理出口连接测速站点。HTTPS 目标还涉及目标站点的 TLS 握手，这与代理协议自身使用的 TLS 不是同一层。
4. 发送请求并等待响应。目标站点处理请求，响应沿代理路径返回，内核记录本次探测结果。

不要把这四步直接当成所有版本固定使用的计时公式。原版 Clash、Clash Meta（现称 mihomo）以及不同版本，可能在请求方法、连接复用、重复探测和延迟记录方式上存在差异；DNS 缓存也会改变实际开销。需要解释某个精确数值时，应记录客户端与内核版本，再对照对应实现。

首次结果与再次结果为什么不同

第一次访问可能触发 DNS 查询和冷连接；随后测试可能受缓存、会话恢复、服务器负载变化影响。即使每次都新建连接，也不意味着所有状态都从零开始。第一次为 240 ms、随后为 130 ms，不能仅凭这两个数字判定节点“突然提速”。

3. 测速地址会改变节点排序

URL 测试测到的是“节点到这个目标”的路径。测速站点的 CDN、地域调度和运营商互联，都可能与实际使用的网站不同。某节点到测速地址很快，到代码仓库、视频 CDN 或办公服务却绕路，面板低延迟与网页卡顿就会同时出现。

更换测速地址时，要检查返回状态与当前内核的健康检查条件。需要登录、持续重定向或有访问挑战的页面，不适合作为稳定探针。如果配置了 expected-status，状态码不符合预期也可能被判定失败，不能把每一次失败都归因于线路断开。

4. 并发、拥塞与丢包为什么会放大差距

小请求无法测出持续带宽

一个几乎没有响应体的请求，很快就结束了。它不足以观察长时间下载中的拥塞窗口增长、带宽限制、持续丢包和共享出口负载。晚高峰时，线路仍可能在 100 ms 左右完成小请求，却无法稳定传输高清视频。

全部节点一起测试也会互相干扰

批量测试会在短时间内创建多条连接。节点可能共享同一个入口、同一条中转链路，甚至同一个出口。此时本机 Wi-Fi、路由器连接处理能力和运营商上行都可能成为干扰因素。后台正在上传大文件时，排队还可能显著增加延迟。

• 先暂停大文件上传、云盘同步和其他测速任务。
• 从批量结果选出 2～3 个候选节点，再分别复测。
• 每个候选节点至少观察 5 次，记录中位数、最高值及失败次数。
• 在常用时段复测。白天结果不能代替晚间高负载结果。

例如，五次结果为 90、92、95、98、800 ms，中位数是 95 ms，但一次明显尖峰仍值得关注。若五次中有两次失败，不能只拿剩余三次的最低值比较。网页交互和实时通信往往更容易受到抖动、丢包影响，而不是只受平均延迟影响。

5. url-test 自动选择不等于最快下载

url-test 是按探测结果自动选择出站的代理组类型。它不自动下载大文件来比较带宽，也不理解当前任务是视频、会议还是软件更新。select 用于手动选择，fallback 侧重按顺序寻找可用出站，不能把这些策略组的名称都当成“网速优化”。

检查现有 url-test 组时，可先看下面这些字段。示例仅展示字段含义，不是完整订阅，不能直接替换整个配置文件；可用字段以实际内核版本为准。

type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: true

• interval: 300：定时检查间隔为 300 秒，不代表每个页面请求都重新测速。
• tolerance: 50：以毫秒为单位设置切换容差，减少因小幅差异反复切换；它不是超时上限，也不会提高带宽。
• lazy: true：可在组未被使用时跳过定时检查，具体活跃状态判定以当前内核实现为准。因此面板结果可能不是刚测出的。

订阅中的 proxy-providers 还可能有自己的 health-check。代理集合健康检查与代理组测试不是简单的一对一关系，客户端手动测试又可能使用另一套参数。排查时要同时核对探测 URL、结果时间与配置来源，避免把旧结果当成当前状态。订阅更新可能覆盖本地改动，长期调整应使用客户端支持的覆写机制。

6. 用实际请求验证节点，而不是只看面板

先把出站模式设为规则模式，在代理页固定候选节点，再用连接记录确认目标请求命中了哪个规则、哪个代理组和哪个最终出站。系统代理只影响遵循它的应用；终端工具可能未读取系统代理。TUN 模式扩大了流量接管范围，但不会自动提高线路带宽。

通过混合端口做一次可重复测试

下面命令适用于 macOS 终端，假设客户端实际的混合端口为 7890。请先在客户端设置页确认端口；若端口不同，应改成实际值。-x 显式指定本机 HTTP 代理，不依赖终端是否遵循系统代理；--noproxy "" 避免已有的代理绕过列表让目标意外直连。

curl --noproxy "" -x http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -sS -o /dev/null \
  -w 'status=%{http_code}\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

time_connect 在这里主要反映到本机代理的 TCP 建连；time_appconnect 是完成相关安全握手时的累计时间；time_starttransfer 是收到首字节时的累计时间。它们不是互不重叠的分段，也不能直接对应面板的内核探测值。这个测试用于固定条件复查请求，不用于证明两个实现应当显示同一数字。

再测真实业务与持续吞吐

1. 打开实际使用的站点，连续访问数个页面，观察首屏、登录与资源加载是否正常。
2. 从有访问权限且允许测试的固定来源下载同一文件，保持并发数一致，观察 30～60 秒的稳定速度。
3. 记录时间、网络环境、节点、失败次数与稳定速度。换节点后重复，不同时运行多个下载测试。

注意单位换算：8 Mbps 约等于 1 MB/s，实际应用吞吐还会受到协议开销影响。测速网站展示的 Mbps 与浏览器下载窗口的 MB/s，不能直接按数值大小比较。

7. 延迟很低却打不开，按这个顺序检查

1. 确认结果是否新鲜。手动复测单个节点，记录测试地址与时间。先排除缓存结果和未运行的定时检查。
2. 确认请求是否经过该节点。查看连接页的命中规则及最终出站。某些域名可能匹配 DIRECT，或者进入另一个代理组。
3. 确认流量入口。检查系统代理是否开启、应用是否使用独立代理；使用 TUN 模式时，再检查权限、路由和其他 VPN 的影响。
4. 检查目标与 DNS。探针可达不代表业务域名可达。核对日志中的解析失败、连接超时及 TLS 错误，不要一遇到故障就同时改动全部 DNS 设置。
5. 区分 TCP 与 UDP。HTTPS 小请求成功不能证明 UDP 转发可用。游戏、语音和 QUIC 需要另外验证协议支持与实际路径。