必须同时设置net.ipv4.tcp_congestion_control=bbr和net.core.default_qdisc=fq，内核≥4.9且tcp_available_congestion_control含bbr，双向启用并验证ss -i和tc qdisc输出，缺一不可。
要让Linux服务器真正跑满专线带宽、降低高延迟场景下的TCP抖动，必须开启BBR拥塞控制算法——它不靠丢包判断拥塞，而是实时测量瓶颈带宽和最小RTT，把在途数据量精准锁死在BDP（带宽×时延）黄金点上。
确认系统是否支持BBR
运行uname -r查看内核版本，输出如5.15.0-105-generic或4.19.216即可；若为3.10.0-1160或4.4.0-252，内核原生不识别tcp_bbr模块，配置会静默失败。
执行sysctl net.ipv4.tcp_available_congestion_control，输出中必须包含bbr，否则后续所有设置无效——某些阿里云定制内核虽标称4.19+，但已阉割BBR，必须实测。
【注意：lsmod | grep tcp_bbr无输出 ≠ 不支持，只是未加载；关键看tcp_available_congestion_control是否含bbr】
永久启用BBR的两行核心配置
BBR必须搭配fq（Fair Queueing）队列调度器才能稳定发包，否则吞吐抖动、延迟不降反升——就像给涡轮车配了个化油器。
用tee追加配置（避免权限问题且防止systemd-sysctl覆盖重复键）：
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
执行sudo sysctl -p加载，漏掉这步配置就躺在文件里不动。
验证BBR是否真在跑流量上
第一步：确认参数生效
运行sysctl net.ipv4.tcp_congestion_control和sysctl net.core.default_qdisc，两个输出必须分别为bbr和fq。
第二步：确认连接启用
查活跃连接：ss -i dst example.com:443（把域名换成你实际访问的服务），输出中要有bbr字样才确认该连接启用了算法。
第三步：确认网卡队列
运行tc qdisc show dev eth0（eth0换成你实际网卡名），输出应含fq；若还是pfifo_fast，说明default_qdisc没生效或被其他配置覆盖。
【客户端和服务端必须双向启用：Nginx开了BBR，但你的手机用Android 11（默认CUBIC）或macOS 12以前内核，整条流仍按老算法跑】
第四步：排查中间链路干扰
企业防火墙、SD-WAN、甚至某些家用路由器会丢弃pacing包，导致BBR自动降级为Reno；可用mtr或抓包看TCP options是否被清空。
