BBR 到底有没有用：VPS 网络调优的实测与边界
几乎每篇 VPS 教程都会让你"开启 BBR 加速"。但它到底是什么、什么时候真有用、什么时候纯属心理安慰，很少有人讲清楚。
BBR 是什么
BBR 是 Google 在 2016 年提出的拥塞控制算法，代替传统的 CUBIC。
传统算法（CUBIC、Reno）的核心思路是丢包即拥塞——一丢包就把发送速度砍半。这个假设在局域网成立，但在跨境链路上不成立：
- 跨境链路经常因为路由抖动、运营商限速而丢包，不是因为链路真的满了
- 一丢包就降速，于是永远跑不满带宽
BBR 换了个思路：它主动测量带宽和最小 RTT，估算出这条链路的真实容量，然后按这个容量发送，而不是一遇丢包就退让。
一句话：CUBIC 看丢包判断拥塞，BBR 看带宽和延迟建模。跨境高丢包场景下，这个差别非常明显。
什么时候 BBR 有感知
| 场景 | 效果 |
|---|---|
| 跨境、RTT > 100ms、有丢包 | 明显，吞吐可能提升数倍 |
| 跨境、晚高峰拥塞 | 明显，抗抖动能力强 |
| 同城/同区域、低延迟、低丢包 | 几乎无感 |
| 瓶颈在出口带宽上限（比如 30Mbps 峰值限制） | 无效，怎么调都跑不过上限 |
| 对端是单线程且窗口很小 | 效果有限 |
所以"开了 BBR 但没变快"很正常——先确认你的瓶颈是不是在带宽本身。
怎么开（三行）
# 1. 加载模块
sudo modprobe tcp_bbr
echo tcp_bbr | sudo tee /etc/modules-load.d/bbr.conf
# 2. 设置拥塞控制和队列规则
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq
# 3. 确认
sysctl net.ipv4.tcp_congestion_control net.core.default_qdisc
# 应输出 bbr 和 fq队列规则必须是 fq（Fair Queueing）。BBR 依赖它做 pacing，配 fq_codel 效果会打折。
永久生效写进 /etc/sysctl.d/99-tuning.conf，然后 sudo sysctl --system。
真正值得调的参数
网上流传的"一键优化脚本"动辄几十行，其实现代内核里真正有用的没几个：
| 参数 | 建议值 | 作用 |
|---|---|---|
net.core.default_qdisc | fq | BBR 的前提 |
net.ipv4.tcp_congestion_control | bbr | 算法本身 |
net.core.rmem_maxnet.core.wmem_max | 32MB 左右 | 大缓冲区，高 RTT 场景需要 |
net.ipv4.tcp_slow_start_after_idle | 0 | 空闲后不重置拥塞窗口，避免"卡一下" |
net.ipv4.tcp_fastopen | 3 | 客户端+服务端都启用，省一个 RTT |
net.core.somaxconn | 65535 | 高并发连接队列 |
反例：tcp_tw_recycle 早就从内核移除了，tcp_timestamps=0 会带来副作用，net.ipv4.tcp_max_tw_buckets 设太小反而制造问题。看到脚本里有这些，直接跳过。
怎么验证有没有用
先看算法是否真的生效：
sysctl net.ipv4.tcp_congestion_control
ss -ti | grep -o 'bbr' | headss -ti 能看到每个连接用的算法，这是最直接的证据。
然后做同条件对比：在同一台机器、同一个时间段，一个用 bbr、一个用 cubic，下载同一个文件比吞吐。顺序反过来再测一次，排除时段波动。
诚实地说：只测一次"开之前 / 开之后"没有意义。跨境网络的波动比 BBR 带来的差异还大，必须交叉对比。
一个被忽略的副作用
BBR 抢带宽的"攻击性"很强。在共享带宽的环境下（比如同一台物理机的其他 VPS，或者你和其他服务争同一条出口），开了 BBR 的机器会把公平排队的资源抢得更多。
对独享带宽没影响；但在共享链路上，这可能让邻居变慢。这也是部分机房默认不给开 BBR 的原因。
新一点的方案是 BBRv3（Linux 6.10+ 主线的 BBR 已经改进），在保持高吞吐的同时对公平性更友好。
结论
- 跨境 VPS 值得开，尤其是高丢包、高 RTT 的线路，收益真实存在
- 同区域/本地服务没必要折腾，CUBIC 完全够用
- 瓶颈在带宽上限时，任何拥塞控制算法都救不了
- 参数只调那几个关键的，别抄几十行的"一键脚本"