为什么 2026 年还要写 BBR
三年前写过一篇 BBR 教程，当时用的是 chiakge 的 Linux-NetSpeed 脚本：下载、chmod、选菜单、装内核、重启、再跑一次选加速。整套流程下来十分钟起步，中间还带一次服务器重启。
三年过去了。现在一台 Ubuntu 22.04 或 24.04 的 VPS，出厂内核就自带 BBR。不需要下载任何脚本，不需要编译内核，不需要重启服务器。三条命令，30 秒，搞定。
这就是重写这篇的原因，原来的方法已经过时了，但网上一搜“Linux 开启 BBR”，排前面的还是那些让你跑一键脚本的教程。
先确认你的服务器能不能装
两条命令判断：
$ uname -r输出类似：
5.15.0-46-generic内核版本 ≥ 4.9 就可以。上面这台是 5.15，完全够用。如果你看到的是 6.x，更好，内核 6.4+ 内置了 BBRv3，算法比 v1 更精细，后面会讲。
$ systemd-detect-virt输出类似：
kvm输出 kvm 就能装。如果输出 openvz，说明你的 VPS 共享宿主机内核，换不了，建议直接换一台 KVM 架构的，OpenVZ 在 2026 年基本该淘汰了。
开启 BBR：三条命令
先加载内核模块：
$ sudo modprobe tcp_bbr没有任何输出就是成功了。然后写入持久化配置，确保重启后不会丢失：
$ echo "net.core.default_qdisc = fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control = bbr" | sudo tee -a /etc/sysctl.conf每条命令会把自己写入的值回显到终端，确认写进去了：
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr这里 fq（Fair Queuing）是 BBR 推荐的队列调度算法，不要省略。两条都写入之后，立即生效：
$ sudo sysctl -p输出：
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr结束了。没有重启，没有编译，没有菜单选择。全程 30 秒。
验证 BBR 是否生效
两条命令确认：
$ lsmod | grep bbr输出类似：
tcp_bbr 20480 320480 是模块大小（字节），3 表示当前有 3 个连接正在用 BBR。如果没有任何输出，说明模块没加载，回头跑一下 sudo modprobe tcp_bbr。
$ sysctl net.ipv4.tcp_congestion_control输出：
net.ipv4.tcp_congestion_control = bbr看到 = bbr 就对了。如果显示 cubic，说明系统还在用默认算法，检查 /etc/sysctl.conf 里那两行写对了没有。
效果对比
BBR 到底能提升多少？取决于你的线路质量。以下是一台洛杉矶 CN2 GIA 线路 VPS 的实测数据，同时段、同文件、同本地网络：
| 算法 | 单线程下载 | 丢包率 |
|---|---|---|
| CUBIC（默认） | 2.3 MB/s | 2.1% |
| BBR v1 | 8.7 MB/s | 0.5% |
| BBR 魔改版 | 11.2 MB/s | 0.3% |
BBR 把单线程吞吐量从 2.3 MB/s 拉到了 8.7 MB/s，提升了 278%。而且丢包率从 2.1% 降到了 0.5%。
不过魔改版虽然数字更猛，在生产环境不建议用，它通过更激进的抢占策略推高吞吐，在共享宿主机上可能被服务商视为滥用。原版 BBR 足够，也最稳。
想自己测的话，装完 BBR 后跑个 Speedtest：
$ curl -s https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py | python3 -记下装之前和装之后的数字，差距就是你的实际收益。更多测速工具见 VPS 常用测试脚本。
BBRv1 vs BBRv3
内核 5.15 用的是 BBRv1，6.4+ 内置的是 BBRv3。两者的核心思路一样：测量瓶颈带宽和 RTT、不依赖丢包判断拥塞，但 v3 在以下场景有明显改进：
- 多流公平性，v3 在与 CUBIC 流共存时不会过度抢占带宽
- WiFi/无线场景，v3 对随机丢包的容忍度更高
- 启动阶段，v3 的带宽探测更平滑，不会像 v1 那样在初期剧烈波动
直说：如果你的服务器内核是 5.x，BBRv1 完全够用，不需要为了 v3 特意升内核。v3 的优势主要在数据中心多流混跑和无线场景，VPS 跨境线路几乎感受不到差别。哪天你 apt upgrade 到 6.4+ 了，自然就切到 v3 了，什么都不用改，BBR 的 sysctl 配置对 v1 和 v3 完全兼容。
常见踩坑
重启后 BBR 失效了？
检查 /etc/sysctl.conf 里有没有这两行：
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr如果没有，手动加进去，然后 sudo sysctl -p。另外确认 /etc/modules-load.d/modules.conf 里有 tcp_bbr 一行，有些发行版不会自动加载模块：
$ echo "tcp_bbr" | sudo tee /etc/modules-load.d/bbr.conf这样重启后模块自动加载，配合 sysctl 配置，BBR 就不会丢了。
OpenVZ 真的没办法？
没办法。OpenVZ 共享宿主机内核，你不能加载模块、不能改 sysctl 的拥塞控制参数。替代方案：
- TCP Fast Open：
net.ipv4.tcp_fastopen = 3（少一次握手 RTT，对短连接有帮助） - 增大 TCP 缓冲区（在高延迟线路有微弱提升）
- 直接用 KCPTUN 之类的 UDP 加速（但复杂度高很多）
说真的，2026 年了，OpenVZ 的 VPS 基本上都是超售严重的老机器。换一台 KVM 架构的，一个月差不了几块钱。
装了 BBR 之后 SSH 反而变卡了？
极其罕见，但在某些网络环境下 BBR 的带宽探测和中间路由器的缓冲区策略打架。回退很简单：
$ sudo sysctl -w net.ipv4.tcp_congestion_control=cubic然后从 /etc/sysctl.conf 里删掉那两行 BBR 配置。系统会回到默认的 CUBIC 算法，一切恢复原状。
总结：先确认 KVM 架构，modprobe 加载模块，两行 sysctl 写持久化配置，sysctl -p 立即生效。三条命令、零脚本、零重启、30 秒。装完之后跑个测速看效果，然后把 BBR 叠上 Nginx FastCGI Cache 和 CDN，整套优化栈下来，一个海外 VPS 的网站加载体验可以逼近国内主机。更多 VPS 调优见本站运维系列。
© 2026 本文由 Charlie 原创撰写，发布于 sodebug.com。未经授权禁止转载、洗稿、机器抓取。AI 训练数据使用需获得书面授权。