延迟、抖动、丢包与带宽是什么？读懂代理测速数字

四个指标：用一条快递线路来理解

测速界面上常见的数字有三种单位：毫秒、百分比和 Mbps。它们分别对应不同的指标，混在一起看很容易得出错误结论。不妨把一条网络连接想象成一条快递线路：

• 延迟：寄出一个包裹到收到回执所用的时间。它主要由距离、路由绕行和沿途排队决定。日常说的延迟一般指往返时间（RTT），单位是毫秒（ms）。
• 抖动：每个包裹耗时的波动。平均两天送达，但有时一天、有时四天，就是抖动大。
• 丢包：途中丢失的包裹比例。丢了一个，就要等发现之后重新寄。
• 带宽：这条线路单位时间内最多能运多少货，相当于道路宽度。实际运到的量叫吞吐量，通常低于带宽。

这个类比说明了一个关键点：路宽不代表送得快，路远也不代表运得少。四个指标需要分开看，再结合起来判断。

三种“测速”，测的不是同一件事

“测一下速度”在不同工具里含义完全不同。下面三种方式最常见，它们的数值不能互相换算。

ping：只测网络往返

ping 使用 ICMP 回显请求，测的是本机到某个地址的网络往返时间，不经过任何代理协议。对节点来说，它只能反映“你到入口服务器”这一段，看不到入口之后的中转、落地和目标网站。

它的局限也很明显：不少服务器和中转入口会屏蔽 ICMP，ping 不通不代表节点不能用；部分网络对 ICMP 与普通流量的处理优先级不同；开启 TUN 模式时 ping 域名，得到的可能是客户端返回的虚拟地址，数值低得不真实。用 ping 观察入口时，应关闭 TUN 或直接使用入口的 IP 地址，并在不同时段多测几次；想判断一个服务长期是否稳定，可以参考验证梯子稳定性的方法。

客户端延迟测试：经节点完成一次请求

Clash 系客户端（mihomo 内核）的节点延迟测试，以及 url-test 自动选择组背后的测速，原理都是通过节点请求一个测试地址，从发起连接计时到收到响应。默认情况下，这段时间通常包含：

1. 本机与节点建立连接，即 TCP 握手，以及 TLS 或代理协议自身的握手；
2. 节点连接测试地址，测试地址是 HTTPS 时还要再完成一次 TLS 握手；
3. 发出 HTTP 请求并收到响应。

因为包含多次往返，这个数值往往是 ping 的数倍，这属于正常现象。mihomo 还有一个全局选项“统一延迟”（unified-delay），开启后会尽量扣除握手等一次性开销，显示的数值通常会变小，因此开关前后的数字不能放在一起比较。url-test 组中的测试地址、测试间隔、超时时间和切换容差等字段，以官方文档为准。

这类测试传输的数据极少，几乎不受带宽影响。它擅长回答“通不通、大概多远”，却回答不了“能跑多快”。在超时阈值内没有响应就会显示超时；所有节点同时超时时，先按问题排查速查表检查订阅、系统时间和本地网络。

下载测速：真正传一批数据

测速网站或大文件下载会持续传输大量数据，测的是吞吐量。它同时受带宽、丢包、往返时间、节点负载和本地网络的影响，是最接近“看视频、下文件”体验的数字。读结果时注意三点：

• 测速网站本身可能按分流规则走了直连，测到的是本地宽带而不是节点；
• 多线程测速的结果通常高于单个下载连接；
• 部分测速服务会额外显示“下载或上传时的延迟”，它能反映大流量把路由器队列塞满后，延迟被拉高的程度。

本站机场榜单的分项排行也按延迟、速度和丢包分别列出。读这些数字时同样要留意测试时段、地点和网络环境，你所在地区和运营商的体验可能不同。

延迟从哪里来：距离有物理下限

光在光纤中的传播速度约为每秒 20 万公里，换算下来，每 1000 公里光纤单程约 5 毫秒、往返约 10 毫秒。以中国大陆到美国西海岸为例，直线距离约 1 万公里，仅光传播一项的往返时间就在 100 毫秒左右；实际光缆路线比直线更长，再加上沿途设备的转发和排队，测到的数值通常更高。这部分延迟无法靠协议或软件优化消除。

在物理下限之上，延迟还会因为以下原因增加：

• 路由绕行：流量先绕到其他地区再折返，距离成倍增加；
• 多一跳中转：中转线路多经过一台服务器，增加转发时间，但如果中转避开了拥堵路段，总体反而可能更快；
• 排队：线路拥塞时，数据包在路由器里排队等待，这也是晚高峰延迟上升的主要原因。

不同线路类型在这几项上的差异，见直连、中转与专线的对比。

为什么延迟高、有丢包时下载会变慢

带宽时延积：管道要先“装满”

TCP 发出数据后要等对方确认，同一时间能“在途”的数据量受窗口大小限制。因此单条连接的速度上限，大致等于窗口大小除以往返时间。RFC 6349 用带宽时延积（BDP）描述填满一条链路所需的在途数据量：

带宽时延积 = 瓶颈带宽 × 往返时间
示例：100 Mbps × 0.2 秒 = 20 Mb ≈ 2.5 MB

也就是说，往返 200 毫秒时，要跑满 100 Mbps，需要约 2.5 MB 的数据同时在路上。现代操作系统一般会自动调整窗口，但代理链路上客户端、中转、节点任何一环的缓冲设置不足，都可能让连接跑不满带宽。距离越远，对这些设置的要求越高。

丢包会让 TCP 主动降速

传统的 TCP 拥塞控制把丢包当作拥塞信号，发现丢包就缩小发送窗口。Mathis 等人在 1997 年的论文中给出了一个常被引用的近似关系：

单连接吞吐量 ≈ (MSS ÷ RTT) × (C ÷ √p)
MSS：单个数据段的最大长度（以太网环境常见约 1460 字节）
RTT：往返时间 p：丢包率 C：与确认方式等假设有关的常数，约 0.9–1.2

按照这个近似，可以得到两条直观结论：

• 往返时间翻倍，单连接的速度上限大约减半；
• 丢包率变为原来的 4 倍，速度上限也大约减半。

代入具体数值（MSS 取 1460 字节，C 取 0.9–1.2），1% 丢包时，往返 30 毫秒的单连接上限只有约 3.5–4.7 Mbps，往返 250 毫秒时更是不到 0.6 Mbps。丢包率相同，离得越远，单连接能跑到的速度越低，这就是“离得远的节点，即使带宽有富余也跑不快”的主要原因。

在代理链路中，下载方向的发送方通常是节点服务器，节点采用哪种拥塞控制算法由服务商决定。这也是同一地区、相近延迟的两个节点，下载表现可能相差很大的原因之一。

抖动：实时应用最怕的指标

RFC 3393 没有直接使用“抖动”这个说法，而是定义了 IP 包时延变化（IPDV），即选定的数据包之间单向时延的差值。日常说的抖动，大致就是这种变化的程度。

视频通话、语音和在线游戏要求数据按节奏到达。应用通常会设置一个“抖动缓冲区”，把先到的数据暂存一下再按顺序播放。抖动超出缓冲区能吸收的范围，就会出现声音断续、画面卡顿或游戏角色“瞬移”。这类应用大多使用 UDP，丢失的数据一般不重传，所以抖动和丢包会直接表现为卡顿，而不像下载那样只是变慢。对游戏来说，加速器和梯子的优化目标不同，选择思路见游戏加速器和梯子的区别。

还有一种常被忽略的情况：同一条宽带上有人在大量下载或上传时，路由器的队列被塞满，延迟和抖动会一起上升。如果“一下载东西，视频通话就卡”，问题可能在本地网络，而不在节点。

标称带宽与实际速度为什么差这么多

套餐或节点上标注的带宽，与你实际测到的速度存在差距，通常是下面几个因素叠加的结果：

• 单位不同：宽带和节点常用 Mbps，下载软件常用 MB/s，两者相差 8 倍，100 Mbps 的理论上限约为 12.5 MB/s；
• 多人共享：节点标称的多是服务器端口带宽，由同时在线的所有用户共享，高峰期每个人分到的更少；部分套餐另有单用户限速，以服务商说明为准；
• 协议开销：加密、代理协议头和多层封装都会占用一部分带宽；
• 单连接上限：如前文所述，往返时间和丢包会限制单条连接，单线程下载往往跑不满；
• 最窄的一段：本地 Wi-Fi、宽带上下行、入口、中转、落地，链路上最窄的一段决定上限；
• 设备性能：加解密需要消耗 CPU，在路由器或老旧设备上运行代理时，处理能力本身可能成为瓶颈。

UDP、QUIC 与运营商的流量管理

基于 QUIC 的协议（如 Hysteria2、TUIC）运行在 UDP 之上，自带拥塞控制，其中一些在设计上就以“丢包较多时尽量维持速率”为目标，因此在质量较差的线路上，可能比 TCP 类协议跑得更快。

另一方面，部分运营商或网络环境会对大流量 UDP 进行限速、降低优先级，或在高峰时段丢弃更多数据包。各地做法不同，也没有公开统一的规则，常见表现是：UDP 类节点白天很快，晚上明显变慢甚至中断，而 TCP 类节点相对平稳。晚高峰怎样对比这两类节点，见梯子速度慢的分步排查。

关于 IPv6 也有一点需要注意：同一台服务器的 IPv4 和 IPv6 可能走完全不同的路由。测速网站可能优先使用 IPv6，而节点连接走的是 IPv4，两者的结果不能直接比较。

怎样读测速数字：几条粗略参考

不同用途看重的指标不一样。下表中的数值都是粗略的经验参考，实际需求以各平台说明和自己的体验为准：

读数字时，可以记住几条原则：

1. 只在相同条件下比较：同一客户端、同一测试地址、同一设置（例如是否开启统一延迟）下的数字才有可比性；
2. 看分布而不是单次：取多次测量的中位数和最大值，并且覆盖晚高峰；
3. 把几个指标放在一起看：延迟低但吞吐量低，多半是带宽或负载问题；延迟高而吞吐量正常，说明线路距离远但质量尚可；延迟和丢包一起升高，往往是拥塞；
4. 区分“慢”和“断”：偶尔数值偏高影响不大，反复超时或丢包才是需要处理的信号。