Linux 4.9+内核才原生支持BBR，需通过sysctl net.ipv4.tcp_available_congestion_control确认含bbr；启用须同时配置fq队列与bbr算法，且重启后验证新内核版本及实时连接状态。
确认内核是否支持BBR（4.9+是硬门槛）
BBR不是装个包就能用的功能，它从 Linux 4.9 内核起才被主线合入。低于这个版本（比如 CentOS 7 默认的 3.10.0 或 Ubuntu 16.04 的 4.4.0），tcp_bbr 模块压根不存在，强行写配置也没用。
- 先执行
uname -r—— 如果输出像5.15.0-100-generic或4.19.216这样主版本 ≥4.9，可继续；若为3.10.0-1160，必须升级内核 - 别只看
lsmod | grep bbr是否有输出：没输出≠不支持，只是没加载；有输出≠已启用，只是模块在内存里 - 真正可靠的判断是：
sysctl net.ipv4.tcp_available_congestion_control输出中是否含bbr—— 这个命令能反映内核编译时是否启用了 BBR 支持
临时启用 vs 永久启用：别混淆作用域
临时启用仅对当前运行生效，适合快速验证兼容性或调试；永久启用靠写入 /etc/sysctl.conf 并加载，但很多人漏掉关键依赖项导致失败。
- 临时启用两步到位：
sudo sysctl -w net.core.default_qdisc=fq+sudo sysctl -w net.ipv4.tcp_congestion_control=bbr - 永久启用不能只加
net.ipv4.tcp_congestion_control=bbr—— 必须同时配net.core.default_qdisc=fq，否则 BBR 无法获得稳定的发送节奏，实际效果可能不如默认的cubic -
sudo sysctl -p执行后，务必再跑一次sysctl net.ipv4.tcp_congestion_control确认返回值确实是bbr，而不是报错或仍显示cubic
CentOS/RHEL 7 升级内核是常见卡点
原生 CentOS 7 内核长期停留在 3.10.x，必须借助 ELRepo 仓库安装 kernel-ml（Mainline Stable）才能满足 BBR 要求，这步跳过就全白忙。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 导入密钥和仓库：
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org→rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm - 安装新内核：
yum --enablerepo=elrepo-kernel install kernel-ml -y（注意不是kernel-lt） - 设为默认启动项：
grub2-set-default 0后，必须执行grub2-editenv list确认saved_entry已更新，否则重启后仍在旧内核上跑 - 重启后再次
uname -r，确保看到的是5.x或4.19+版本号，再开始配置 BBR
验证是否真生效：别被“配置写入”骗了
很多人改完 /etc/sysctl.conf、跑完 sysctl -p 就以为大功告成，但 BBR 是否真在接管连接，得看运行时状态。
- 检查当前算法：
sysctl net.ipv4.tcp_congestion_control—— 必须返回bbr - 检查可用算法列表：
sysctl net.ipv4.tcp_available_congestion_control—— 输出应包含bbr（如bbr cubic reno） - 检查模块是否加载：
lsmod | grep tcp_bbr—— 应有类似tcp_bbr 20480 1的输出，数字表示引用计数，>0 才算真正挂载 - 真实流量下验证：用
ss -i查看某条 TCP 连接（如 SSH 或 curl 请求），字段中出现bbr和非零的bbr_bw值，才算落地生效
最常被忽略的一点：BBR 对单次连接有效，但不会改变已有长连接的行为。验证时最好新建连接（比如新开 SSH 会话或 curl -v http://example.com），而不是复用旧终端里的连接。
