网络延迟、丢包、带宽与实际速度的关系

“节点延迟才几十毫秒，为什么视频还在缓冲？”“白天很快，一到晚上就卡？”这类问题的答案，很少落在某一个数字上，而是延迟、抖动、丢包与带宽几项指标共同作用的结果。客户端列表里那个醒目的延迟数字，只是其中一个切面。

本文先讲清每个指标衡量的是什么，再说明它们如何组合成你感受到的“实际速度”，最后给出可操作的自测方法，并分析晚高峰变慢的成因。

先分清五个概念

延迟：距离、排队与绕路

延迟通常指往返时间（RTT），由几部分构成：

• 传播时延：信号在光纤中的传播速度约为真空光速的三分之二，即每毫秒大约 200 公里。距离是硬约束，任何线路都无法让跨洋连接的延迟低于这个物理下限。
• 排队时延：数据在路由器缓冲区里等待转发的时间。网络越拥堵，排队越久，这是晚高峰延迟上升的主要原因之一。
• 处理与发送时延：设备处理数据、把数据推上链路的时间，一般占比较小。
• 路由绕路：数据并不总是走地理上最短的路径。部分线路访问邻近地区时，可能绕经更远的网络交换点，实际延迟远高于按距离推算的数值。

在代理场景中，路径被拆成了多段：设备 → 入口或中转 → 落地服务器 → 目标网站，每一段都贡献延迟。更关键的是，建立一条新连接时，TCP 与 TLS 握手需要在这条长路径上往返多次，所以高 RTT 节点最明显的症状是“点开链接要等一下”，而不一定是“下载慢”。各层握手的先后顺序，可以参考 TCP、UDP、TLS、DNS 与代理连接的关系。

抖动：稳定比平均值更重要

抖动描述延迟的起伏。两个平均延迟相同的节点，一个始终平稳，一个时高时低，前者的体验要好得多。网页浏览对抖动不敏感，但游戏、语音和视频会议需要数据按时到达，抖动大时会出现画面卡顿、声音断续或角色“瞬移”。应用一般会用缓冲来吸收抖动，代价是额外增加的延迟。

丢包：TCP 速度的隐形上限

丢包对速度的影响经常被低估。TCP 的设计目标是可靠传输，Reno、CUBIC 等经典的拥塞控制算法把丢包视为网络拥塞的信号：一旦发现丢包，就重传数据并主动降低发送速率，之后再逐步试探着加速。

网络研究中有一个描述这一行为的经典近似公式（由 Mathis 等人提出），用来估算单条 TCP 连接在稳定丢包条件下能达到的吞吐量：

吞吐量 ≈ (MSS / RTT) × (C / √p)

MSS：单个报文段可携带的最大数据量
RTT：往返时间
p  ：丢包率
C  ：与确认方式等因素相关的常数

不必代入具体数字，只看公式的结构就能得到两个结论：

1. 吞吐量与 RTT 成反比：丢包率相同时，距离越远、延迟越高，单条连接能跑到的速度越低。
2. 吞吐量与丢包率的平方根成反比：丢包率稍有上升，速度上限就会明显下降，而且这与带宽无关——带宽再大，单条 TCP 连接也可能被丢包限制在很低的速度。

这个公式是简化模型，只适用于传统的基于丢包的拥塞控制。BBR 等算法通过估计瓶颈带宽和最小 RTT 来控制发送速率，对随机丢包没那么敏感；多线程下载则用多条连接并行来突破单连接的上限。这也解释了为什么同一个节点“测速软件很快、浏览器单线程下载很慢”。

基于 UDP 的 Hysteria2 在高丢包线路上表现突出，原因在于它可以按用户设定的速率发送，不因丢包大幅退让。不过这种方式依赖用户正确填写带宽，也更容易受到运营商对 UDP 流量限速策略的影响，并非在所有网络中都更快。

带宽：上限，而不是承诺

带宽是链路的最大承载能力。代理连接的实际速度取决于整条路径上最窄的那一段：

• 你家宽带或手机网络的带宽，以及家中 Wi-Fi 的实际速率；
• 入口或中转服务器的端口带宽，以及与其他用户的共享程度；
• 跨境段（公网国际出口或专线）的可用带宽；
• 落地服务器到目标网站的带宽，以及目标服务器自身的限速。

节点标注的“千兆端口”一般指服务器端口规格，而端口是多人共享的。用户越多、使用时段越集中，每个人分到的速度就越少。

为什么客户端的“延迟测试”不等于速度

客户端列表里的延迟数字，测的是“完成一次很小的请求要多久”，而不是“能传多快”。常见的测试方式有三种：

1. URL 测试：通过节点请求一个返回空内容的测试地址（常见的是各类 generate_204 页面），计时包含与节点建立连接、协议握手以及一次 HTTP 往返。mihomo 系客户端默认采用这种方式。
2. TCP 连接测试：只测量本机到节点入口端口的 TCP 握手时间，反映的是入口段，不经过落地服务器。
3. ICMP ping：直接 ping 节点地址，同样只覆盖入口段，而且部分服务器会屏蔽 ICMP 或降低其优先级。

不同客户端、不同测试地址得到的数字不能直接横向比较。更重要的是，这些测试只发送极少量数据，几乎反映不出丢包和带宽的影响。

如果遇到的是全部节点都测不出延迟，问题通常不在线路质量，可以先按 节点全部超时的排查步骤 检查订阅、系统时间与客户端版本。

怎样自测：ping、mtr 与测速

自测的目的是分清问题出在哪一段。下面的命令仅为示例，请把 example.com 换成实际要测试的地址：

# 连续发送 50 个探测包，观察延迟波动与丢包率
# （Linux / macOS；Windows 使用 ping -n 50 example.com）
ping -c 50 example.com

# 逐跳显示延迟与丢包，发送 100 轮后输出报告（需自行安装 mtr）
mtr -rwc 100 example.com

# Windows 自带的路由追踪
tracert example.com

解读结果时注意以下几点：

• 中间某一跳显示丢包，但后续各跳和终点正常，多半是该路由器对 ICMP 回复做了限速，并不代表真实丢包。真正需要关注的，是从某一跳开始一直延续到终点的丢包。
• ping 和 mtr 默认不经过代理，测的是本机到目标的直接路径，适合检查本地网络和节点入口。开启 TUN 模式时，部分客户端会对 ICMP 做特殊处理（例如 Fake-IP 模式下 ping 域名，可能立即收到虚拟地址的回应），结果并不反映真实路径，测试前最好先确认当前模式。
• 测速网站的结果受测速服务器位置影响。通过代理测速时，测的是“本机 → 节点 → 测速服务器”的整条路径，建议多选几个服务器、多测几次。

一个实用的测试流程：

1. 切换到直连模式，测一次本地宽带的速度与延迟，作为基准；
2. 连接要评估的节点，分别在白天和晚高峰各测几次，记录延迟、丢包率和下载速度；
3. 对比同一服务中不同线路类型的节点，以及单线程与多线程下载的差异；
4. 连续观察几天再下结论，不要只凭一次结果判断。

常用的在线测速、IP 与路由检测服务，整理在 网络检测工具 页面。

晚高峰为什么会变慢

晚间是家庭用户集中上网的时段，跨境链路的压力也最大。变慢通常来自以下几个方面：

• 公网国际出口拥塞：直连线路和部分中转线路的跨境段经过公网出口，出口带宽被大量用户共享，晚间排队延迟上升、丢包增加，按照上面的公式，TCP 速度会随之下降。
• 节点超售：服务商通常按“用户不会同时满速使用”的假设分配带宽，高峰期大家同时在线，每个人分到的速度下降。
• 落地与目标端负载：热门地区的服务器、热门网站的 CDN 在晚间同样繁忙。

应对思路包括：在试用期内重点测试晚高峰表现；对稳定性要求高时，考虑跨境段不经过公网出口的专线，几种线路的区别见 直连、中转和专线的线路类型详解；大文件下载尽量避开高峰时段；准备一个不同线路的备用节点。系统评估一个服务稳定性的方法，可以参考 稳定机场的评估方法。