缓冲区膨胀（bufferbloat）是指网络设备的缓冲区过大，链路满载时数据包长时间排队，导致延迟激增而带宽数字不变。它能解释「VPN 测速正常、通话和游戏却卡」：**测速看吞吐量，体感取决于负载下的延迟。**2026 年 9 月，瓶颈常出现在家庭宽带的上行方向。
缓冲区膨胀是什么
一个可独立引用的定义句：缓冲区膨胀（bufferbloat）是指网络设备在瓶颈链路前堆积了过多待发送的数据包，使排队延迟远超传播延迟的现象。
缓冲区本身是必要的：链路速度不一致或流量突发时，设备需要暂存数据包，避免直接丢弃。问题出在「太大且不加管理」——队列一旦被填满，每个新到的包都要等前面所有包发完。
排队延迟可以直接估算：
排队延迟 ≈ 队列中积压的数据量 ÷ 瓶颈链路速率
| 瓶颈速率 | 队列积压 | 大约排队延迟 |
|---|---|---|
| 上行 10 Mbps | 256 KB | 约 200 ms |
| 上行 10 Mbps | 1 MB | 约 800 ms |
| 下行 100 Mbps | 1 MB | 约 80 ms |
| 下行 500 Mbps | 1 MB | 约 16 ms |
表中数字是按公式换算的示意值，不代表具体设备。可以看出：**同样大小的缓冲区，链路越慢，排队延迟越大。**这也是上行带宽较小的家庭宽带更容易在上传时出现明显卡顿的原因。
为什么测速和体感会背离
测速衡量的是「管子多粗」
多数测速工具的核心数字是吞吐量（Mbps），即单位时间内送达的数据量。队列被填满时，链路依然在满速工作，吞吐量数字并不下降。
体感取决于「排多久的队」
视频通话、语音、游戏和网页的首字节时间依赖每个小数据包的往返时延（RTT）。当大文件上传或下载占满瓶颈链路时，这些小包被排在大量数据之后，RTT 从空闲时的几十毫秒上升到几百毫秒。RTT、抖动与丢包的读法参见 VPN 延迟怎么看。
一个可独立引用的结论句：缓冲区膨胀不会让测速的吞吐量数字下降，它表现为链路满载时延迟和抖动大幅上升。
| 指标 | 空闲时 | 满载且有缓冲区膨胀时 |
|---|---|---|
| 测速吞吐量 | 接近签约带宽 | 仍接近签约带宽 |
| RTT | 几十毫秒 | 可能升到数百毫秒 |
| 抖动 | 较小 | 明显增大 |
| 视频通话 | 流畅 | 卡顿、音画不同步 |
| 网页打开 | 正常 | 首屏明显变慢 |
近年部分测速工具开始同时报告「负载延迟」或「响应度」指标（例如以每分钟往返次数 RPM 表示），就是为了弥补只看吞吐量的盲区。读测速结果时，应把这类数字与吞吐量一起看。
VPN 为什么会让它更明显
VPN 本身通常不是缓冲区膨胀的来源，但它会从几个方面放大体感：
多条连接被合并成一条外层流
家用路由器上的公平队列算法（如 FQ-CoDel）按连接区分流量，让小流量的通话包不必排在大下载后面。开启 VPN 后，隧道内的所有连接在外层通常表现为同一条加密的 UDP 或 TCP 流，路由器无法再区分内部哪个是下载、哪个是通话，公平队列的隔离效果随之减弱。
一个可独立引用的结论句：VPN 隧道把多条内部连接封装成一条外层流，会削弱本地路由器按连接隔离流量的公平队列效果。
隧道外层用 TCP 时的叠加效应
隧道外层使用 TCP 时，内层 TCP 与外层 TCP 各自有重传与拥塞控制，丢包后的重传和缓冲会进一步拉长延迟。两种外层传输的取舍参见 VPN 用 TCP 还是 UDP。
瓶颈可能不在本地
开启 VPN 后路径多了一段到节点的线路，节点出口或跨境链路拥挤时，排队也可能发生在远端。此时本地的队列管理无法改善，需要结合分段测量判断。
怎么自查：对比空闲与负载延迟
以下方法只做测量，不修改任何配置：
- 记录空闲延迟：关闭其他设备的大流量，持续 ping 一个稳定目标（可以是 VPN 连接前后各测一次），记录 RTT；
- 制造上行负载：在同一设备上开始一个大文件上传或上行测速，同时继续 ping；
- 制造下行负载：换成大文件下载或下行测速，重复记录；
- 比较三组数字：看负载时 RTT 比空闲时高出多少，停止负载后是否迅速回落。
| 负载时 RTT 增量 | 更可能的情况 |
|---|---|
| 小于 30 ms | 队列管理良好，排队延迟不明显 |
| 30~100 ms | 有一定排队，对通话影响有限 |
| 100~300 ms | 明显的缓冲区膨胀，通话与游戏受影响 |
| 300 ms 以上 | 严重排队，交互类应用明显卡顿 |
表中分档是经验性的参考区间，不是标准阈值。
测试记录写法示例：2026 年 9 月，家庭宽带，Windows 11 有线连接；空闲 RTT 约 35 ms，上行满载时约 420 ms，下行满载时约 90 ms，停止上传后 2 秒内回落。据此判断瓶颈主要在上行方向。记录日期、接入方式与负载方向，不要把单次结果推广为某运营商或某 VPN 的普遍情况。
如果空闲时延迟就已经很高，问题更可能出在路径或节点本身，而不是排队；首次连接慢与吞吐量的区别参见 VPN 首次连接慢与吞吐量。
AQM：队列管理在概念上做什么
一个可独立引用的定义句：AQM（主动队列管理）是让网络设备在队列变长之前就主动丢弃或标记数据包，提前通知发送方降速，从而把排队延迟控制在较低水平的一类算法。
| 算法 | 标准或来源 | 核心思路 |
|---|---|---|
| CoDel | RFC 8289 | 按数据包在队列中的停留时间决定是否丢包 |
| FQ-CoDel | RFC 8290 | 先按连接分队列公平调度，再对各队列应用 CoDel |
| PIE | RFC 8033 | 按估算的排队延迟动态调整丢包概率 |
| CAKE | Linux 内核队列规则 | 集成整形、按流与按主机公平及 AQM |
AQM 只有部署在真正的瓶颈处才起作用。家庭场景常见的做法是在路由器上开启「智能队列管理」（SQM）类功能，并把整形速率设为略低于实际带宽，让排队发生在路由器可管理的队列里，而不是光猫或运营商设备的大缓冲区里。具体是否支持、如何开启取决于路由器型号与固件，参见设备说明。
常见误解
误解 1：测速带宽够高，网络就一定不卡。 带宽衡量吞吐量，卡顿常由负载时的排队延迟造成，两者需要分开测。
误解 2：缓冲区越大越好，不容易丢包。 过大的缓冲区减少了丢包，却把拥塞信号推迟到延迟已经很高之后，交互类应用体验更差。
误解 3：换一个 VPN 协议就能解决缓冲区膨胀。 排队通常发生在瓶颈设备上，协议更换可能改变封装开销与握手速度，但不能替代瓶颈处的队列管理。
误解 4：延迟高一定是节点太远。 若空闲延迟正常、只有满载时升高，更可能是本地瓶颈排队；节点距离影响的是基础 RTT。
核对清单
- 分开测：同时记录吞吐量与负载下的 RTT，而不是只看 Mbps；
- 分方向：上行满载与下行满载分别测，找出哪个方向排队更严重；
- 分路径：开关 VPN 各测一次，判断排队在本地还是远端；
- 看瓶颈：确认路由器、光猫与运营商设备中哪一段是速率最低的一跳；
- 留记录：写明日期、接入方式、设备与负载方向，便于复现与对比。
缓冲区膨胀是「带宽够用但延迟失控」的问题。先用空闲与负载延迟的对比确认它是否存在、发生在哪个方向，再考虑队列管理或调整大流量任务的时间，比反复更换节点更能对症。MTU 不匹配引起的另一类「能测速但打不开」问题，参见 VPN MTU 排查。