亚马逊云EC2服务器装BBR的关键动作不是装一个软件，而是确认内核支持tcp_bbr模块，再用sysctl把拥塞控制算法切到bbr；Amazon Linux 2、Amazon Linux 2026和Ubuntu的操作路径并不一样。
先把这台EC2当成一台普通Linux机器看,别被控制台吓到，BBR是Google贡献到Linux内核的拥塞控制算法，内核版本≥4.9才有稳定支持，近年来主流镜像多数已经内置tcp_bbr模块，真正容易卡住的地方是“模块没加载”和“sysctl没写对”，下面按系统拆开讲，命令可以直接在SSH里执行。
亚马逊云EC2服务器如何开启BBR加速？先判断内核和系统版本
登录EC2后,先别急着改配置，不同AMI的内核差异很大，先看清现状，后面少走弯路。
检查当前内核和拥塞控制算法
依次执行下面几条命令,输出结果就是判断依据：
uname -r sysctl net.ipv4.tcp_congestion_control lsmod | grep bbr modinfo tcp_bbr
uname -r看内核版本，≥4.9才具备BBR基础条件。sysctl net.ipv4.tcp_congestion_control看当前算法，常见默认是cubic。lsmod | grep bbr看模块是否已加载，没有输出不代表内核不支持。modinfo tcp_bbr看模块是否存在，有输出说明当前内核带了这个模块。
如果modinfo tcp_bbr有结果，但lsmod没有，说明模块还没加载，后面手动加载即可，如果modinfo直接报错，才需要考虑升级内核或换镜像。
哪些EC2系统镜像已经自带BBR
行业共识认为,较新的Linux发行版内核普遍已经编译了tcp_bbr模块，差别主要在默认是否启用，按EC2常见镜像看：
| 系统镜像 | 内核情况 | BBR支持判断 | 推荐动作 |
|---|---|---|---|
| Amazon Linux 2026 | x内核 | 通常内置tcp_bbr |
加载模块并写sysctl |
| Amazon Linux 2 | 14内核 | 部分镜像需确认模块 | 先modinfo tcp_bbr，没有再考虑升级或迁移 |
| Ubuntu 22.04 | 15内核 | 通常内置tcp_bbr |
加载模块并写sysctl |
| Ubuntu 20.04 | 4内核 | 通常内置tcp_bbr |
加载模块并写sysctl |
这张表不是让你背,而是提醒你：Amazon Linux 2是变量最大的一类，如果modinfo tcp_bbr没有输出，继续硬装sysctl没有意义。
亚马逊云EC2 Ubuntu安装BBR教程：内核、模块与sysctl三步走
Ubuntu在EC2上比较省心,多数情况下不需要换内核，按下面三步走，重启后也能保持。
步骤1 更新系统并确认内核版本
先更新软件包索引,再确认内核：
sudo apt update uname -r
如果内核已经是x或更高，并且modinfo tcp_bbr有输出，直接进入下一步，若内核低于4.9，才需要安装HWE内核，以Ubuntu 22.04为例，可执行：
sudo apt install linux-generic-hwe-22.04 sudo reboot
重启后再次uname -r，确认新内核已经生效，这里要注意：EC2重启后如果内核没变，检查GRUB默认启动项，别让旧内核抢了默认位置。
步骤2 加载tcp_bbr模块并写入sysctl
先临时加载,确认可用：
sudo modprobe tcp_bbr lsmod | grep bbr
然后设置队列规则和拥塞控制算法：
sudo sysctl -w net.core.default_qdisc=fq sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
为了让重启后继续生效,写入配置文件：
echo "tcp_bbr" | sudo tee /etc/modules-load.d/bbr.conf sudo tee /etc/sysctl.d/99-bbr.conf <<'EOF' net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr EOF
fq和bbr通常成对出现，fq负责队列管理，bbr负责拥塞控制，只改tcp_congestion_control不改default_qdisc，部分场景下效果会打折扣。
步骤3 验证BBR是否生效
执行：
sysctl net.ipv4.tcp_congestion_control sysctl net.core.default_qdisc lsmod | grep bbr
期望看到net.ipv4.tcp_congestion_control = bbr和net.core.default_qdisc = fq，如果lsmod没有bbr，但sysctl显示bbr，说明模块可能已编译进内核，仍然可用，重启一次再检查，确认配置没有被cloud-init或别的配置覆盖。
Amazon Linux 2升级内核开BBR与Ubuntu方案对比：选哪个更省事
业内专家指出,BBR在高丢包链路下比传统CUBIC更积极，但前提是内核模块真的可用，放在EC2上，Amazon Linux 2和Ubuntu的差别主要在“要不要动内核”。
Amazon Linux 2安装较新内核的路径
先查模块：
modinfo tcp_bbr
如果有输出,直接按Ubuntu那套加载模块、写sysctl即可，如果没有输出，再查amazon-linux-extras里是否有可用内核：
amazon-linux-extras list | grep kernel
部分区域和实例类型可以通过amazon-linux-extras安装较新内核，操作前先看可用列表，不要盲装，安装后重启，再用uname -r确认，对生产实例来说，更稳妥的做法是评估迁移到Amazon Linux 2026，而不是在旧镜像上反复折腾内核。
两种系统装BBR的差异和注意点
- Ubuntu：内核较新，多数情况只需加载模块和写sysctl，步骤少。
- Amazon Linux 2026：同样省事，默认内核较新，重点检查模块加载。
- Amazon Linux 2：变量最大，可能涉及升级内核或迁移镜像，重启风险要提前评估。
- 共同风险：升级内核后GRUB默认项可能没切过去；
sysctl配置可能被其他配置覆盖；重启会中断业务，建议在维护窗口操作。
亚马逊云EC2服务器装BBR要额外收费吗？场景与地域差异
BBR本身不收费,它是Linux内核功能，启用它不会产生额外许可费，EC2账单仍然按实例规格、存储和流量计费，真正影响体验的是实例类型、区域链路和业务模型，如果你在亚马逊云EC2新加坡节点装BBR，效果还受跨境链路和实例网络性能影响，不是开了BBR就一定能跑满带宽。
BBR不是万能加速键
- 对高丢包、长肥管道场景，BBR通常能改善吞吐。
- 对低延迟、低丢包的内网场景，收益可能不明显。
- 对已经拥塞的出口,BBR不能替代带宽扩容。
- 对UDP业务,BBR不直接起作用，它主要影响TCP拥塞控制。
据Google公开技术文档,BBR基于带宽和RTT建模，不依赖丢包作为唯一信号，这个特性让它在跨境链路上更稳，但也意味着不要把它当成“破解限速”的工具，EC2的安全组、网络ACL和实例带宽上限仍然生效。
亚马逊云EC2服务器装BBR常见坑：内核不匹配与模块未加载
- 只改了
sysctl，没加载tcp_bbr，重启后回到cubic。 - 内核低于4.9，
modinfo tcp_bbr直接报错，却继续照抄命令。 - 升级内核后没检查GRUB默认项,EC2重启仍进旧内核。
- 把
net.core.default_qdisc设成fq_codel却期待BBR满速，队列规则和拥塞控制要配合。 - 在Amazon Linux 2上直接套Ubuntu命令，包管理器和内核路径都不同。
- 忘记在维护窗口重启,业务中断后才发现配置没持久化。
最后收束一句：亚马逊云EC2装BBR的核心是“内核支持+模块加载+sysctl持久化”，系统镜像不同只是路径不同，不是目的不同。
亚马逊云EC2服务器装BBR常见问题Q&A
亚马逊云EC2装BBR后需要重启吗？
加载模块和写sysctl后，当前会话即可生效，不强制重启，但为了让/etc/modules-load.d/bbr.conf和/etc/sysctl.d/99-bbr.conf在开机时稳定加载，建议在维护窗口重启一次并复查sysctl net.ipv4.tcp_congestion_control。
亚马逊云EC2服务器装BBR对下载和上传都有效吗？
BBR作用于TCP发送端的拥塞控制,主要影响服务器向外发送数据的方向，对EC2作为服务端提供下载的场景更明显；上传方向取决于客户端拥塞控制和服务端接收窗口，不是单方面开BBR就能完全决定。
亚马逊云EC2服务器装BBR要额外收费吗？
BBR是Linux内核自带的拥塞控制算法,启用它不会产生额外许可费；EC2账单仍按实例规格、存储和流量计费。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/795142.html
