Linux VPS 如何启用 BBR？检查内核、验证新连接与回滚

· 更新于 · Linux教程

BBR 是 Linux TCP 拥塞控制算法，不是通用的“网络加速开关”。它可能改善某些链路上的吞吐和延迟，也可能对当前业务没有明显帮助。正确做法是先确认当前内核支持，再临时启用，对新连接做可重复测试，最后才持久化。

不要下载第三方“一键换内核”脚本。来源不明的脚本可能改写软件源、引导和内核，也会扩大生产机的回滚范围。内核不支持 BBR 时，应使用发行版仍受支持的官方内核升级路径。

第一步：记录变更前状态

先确认发行版仍在安全支持期，并记录当前内核、拥塞控制算法和默认队列规则：

cat /etc/os-release
uname -r
sysctl -n net.ipv4.tcp_congestion_control
sysctl -n net.core.default_qdisc

如果准备在同一个终端内完成测试，可把原值保存在 shell 变量中：

ORIGINAL_CC=$(sysctl -n net.ipv4.tcp_congestion_control)
ORIGINAL_QDISC=$(sysctl -n net.core.default_qdisc)
printf '原拥塞控制算法：%s\n原队列规则：%s\n' "$ORIGINAL_CC" "$ORIGINAL_QDISC"

另行记下这两个输出。重连或重启后，shell 变量不会保留。

第二步：确认内核确实提供 BBR

sysctl net.ipv4.tcp_available_congestion_control

Linux 内核文档说明，这个列表显示当前已注册、可选择的拥塞控制算法。若输出已经包含 bbr，可以进入下一步。

若没有 bbr，先尝试加载发行版内核随附的模块，再重新检查：

sudo modprobe tcp_bbr
sysctl net.ipv4.tcp_available_congestion_control

lsmod 没有显示 tcp_bbr，不一定代表 BBR 不可用：它也可能已内建到内核。应以 tcp_available_congestion_control 的结果为准。如果 modprobe 报错且重新检查后仍没有 bbr，到此停止；不要继续写入配置，也不要用第三方脚本替换内核。

第三步：先临时启用

只有可用算法列表包含 bbr 时，才执行：

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

net.ipv4.tcp_congestion_control 设置的是新连接默认使用的算法，已经建立的 TCP 连接可能继续沿用原算法。内核文档还明确：被动连接会从监听 socket 继承拥塞控制选择。因此，修改 sysctl 前已经启动的 Web、代理或数据库服务，其监听 socket 接受的后续连接不一定自动改用 BBR。

Google BBR 当前文档指出，现代内核并不强制 BBR 配合 fq 才能工作，不过 fq 在高负载下可能表现更好。不要把 fq 当作 BBR 支持条件。如果你决定把队列规则也纳入同一轮对照测试，可单独执行：

sudo sysctl -w net.core.default_qdisc=fq

这样可以分别判断收益来自拥塞控制算法、队列规则，还是两者组合。

第四步：验证新连接与真实效果

先确认系统对新连接的默认选择：

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc

对于本机主动发起的连接，在修改后建立一个仍在传输的新连接，再查看连接详情。对于接收入站连接的服务，先用以下命令识别实际监听端口和进程：

sudo ss -ltnp

如果监听 socket 早于本次 sysctl 变更，应在维护窗口按该服务的官方检查和完整重启流程重新创建监听 socket；只让客户端重连并不足够。使用 systemd socket activation 的服务还要核对相应 .socket 单元。这里不提供通用重启命令，因为不同服务的配置检查、优雅退出和流量切换方式不同。

重新创建监听后，从获准测试的客户端建立一条仍在传输的新入站连接。以下以服务端本地端口 443 为例，应替换成实际端口：

sudo ss -tinp 'sport = :443'

本机主动发起的连接可按实际目标端口改用 dport 过滤。活跃连接详情可能显示 bbr 及速率、往返时延和重传等信息。仅看到 sysctl 返回 bbr，只能证明默认值已改变；没有检查对应进程和端口的实际新连接，就不能证明业务流量已经按预期运行。

性能对比应固定客户端、服务端、并发量、测试数据和时段，并重复多轮观察吞吐、RTT、重传与应用响应时间。只在你拥有或获准测试的端点之间运行压测。跨境线路会随运营商和时段变化，单次测速不能证明长期收益。

第五步：确认有效后再持久化

先只持久化已经验证的 BBR 选择，并加载这一份由本文创建的文件：

printf '%s\n' 'net.ipv4.tcp_congestion_control = bbr' | sudo tee /etc/sysctl.d/99-bbr.conf
sudo sysctl --load=/etc/sysctl.d/99-bbr.conf

如果你也独立验证了 fq，再把它加入同一个文件：

printf '%s\n' 'net.core.default_qdisc = fq' | sudo tee -a /etc/sysctl.d/99-bbr.conf
sudo sysctl --load=/etc/sysctl.d/99-bbr.conf

不要为这项变更运行 sysctl --system，否则其他目录中尚未验证的 sysctl 配置也会被一并应用。

只有在本次必须执行 modprobe tcp_bbr 后 BBR 才出现时，才需要让模块随系统启动加载：

printf '%s\n' 'tcp_bbr' | sudo tee /etc/modules-load.d/bbr.conf

内核已内建 BBR 或系统本来就能列出 bbr 时，不需要创建模块加载文件。重启验证前，先确认实例有控制台或其他恢复路径。

如何回滚

先停用持久化文件，而不是重新加载系统内所有 sysctl 文件：

sudo mv /etc/sysctl.d/99-bbr.conf /etc/sysctl.d/99-bbr.conf.disabled

如果仍在保存了原值的同一终端中，可立即恢复：

sudo sysctl -w "net.ipv4.tcp_congestion_control=${ORIGINAL_CC}"
sudo sysctl -w "net.core.default_qdisc=${ORIGINAL_QDISC}"

否则，把你在第一步记录的实际值明确填入命令后再执行。若曾创建 /etc/modules-load.d/bbr.conf，确认不再需要后也应将它改名停用。恢复后同样要按服务维护流程重新创建受影响的监听 socket，再建立新连接并用 ss -tinp 按端口检查；默认值的变化不会改写已经建立的连接或既有监听选择。

使用边界

参考链接