为什么开了BBR，网速却感觉一点没提升
网上一搜BBR教程，标题动不动就是"网速提升3倍"“涡轮增压”，跟着敲完三行命令，兴冲冲测个速，发现数字跟开之前差不多，甚至一模一样。很多人到这一步就得出结论："BBR就是个噱头，没用。"这个结论下得有点冤——问题往往不在BBR本身，而在对它的期待从一开始就搞错了方向。
BBR到底在优化什么
BBR是一种拥塞控制算法，它管的是数据包在网络出现拥堵时该怎么应对，不是给你的服务器凭空变出更多带宽。传统的Cubic算法看到丢包就本能地大幅减速，哪怕丢包只是网络抖动一下，跟真正的拥堵没关系，它也会误判，结果该跑的带宽没跑满。BBR不这么干，它会持续估算这条链路真实的带宽上限和往返时间，尽量把发送速率精确地贴着这个上限走，不会因为一点风吹草动就自废武功。
节点论坛上有个说法挺形象："垃圾线路，你用BBR，50分，调优TCP，55分；好的线路，你用BBR，90分，调优TCP，95分。"意思很直接——BBR是给线路本身的质量做加法，不是从0变出100。这条链路物理上能跑多快是有天花板的，BBR顶多帮你更接近这个天花板，天花板本身有多高，它说了不算。
什么情况下BBR基本感觉不出差别
如果你测速的目标是同城、甚至同一个数据中心内部的节点，延迟本来就低到几毫秒，链路干净得几乎不丢包，这种场景下Cubic和BBR的表现差距很小——因为压根没什么"拥堵"需要被更聪明地应对，两种算法交出的答卷自然相差无几。BBR真正大放异彩的场景，是跨洋、跨运营商、延迟动辄上百毫秒、偶尔还丢包的链路，这种情况下传统算法的保守应对方式会白白浪费掉大量本该能用上的带宽，BBR的优势才真正体现出来。拿同城测速的结果去否定BBR，本身就是拿错了考卷。
除了原理，还有几个技术上的坑
除了期望值搞错，也有不少是BBR压根没真正生效导致的：
sysctl设置完tcp_congestion_control=bbr，不代表配置全对了，配套的队列调度算法qdisc同样得设成fq，不然内核实际用的还是默认的pfifo_fast，BBR跑起来的效果会打折扣：
1 | sysctl net.core.default_qdisc |
确认输出是fq（或者较新内核用fq_codel），不是别的。
老内核压根不支持BBR，sysctl命令执行时不报错，看着像是设置成功了，重启之后拿命令一验证，发现又悄悄变回了cubic：
1 | sysctl net.ipv4.tcp_congestion_control |
如果验证结果不是bbr，说明内核版本不够，得先升级内核才行，不是配置写错了。
还有个容易被忽略的情况——如果这台VPS上同时跑着好几条代理连接，物理带宽早就被这几条连接瓜分完了，单条连接测出来的速度自然上不去，这不是BBR的锅，是带宽本身已经被占满了。
该怎么判断BBR到底有没有用
最靠谱的办法不是跟别人的"提升3倍"截图比，是用自己这台机器的实际线路，开BBR前后各测一次，对比同样的目标、同样的时间段。如果这台VPS本身线路质量就一般，之前提过的CPU使用率明明很低系统却卡那篇里讲的超售问题，同样会拖累网络表现，BBR再怎么调也调不出一条干净的物理线路；测速工具的选择也有讲究，具体可以看VPS网络测速用什么工具最好，用对工具测对场景，才能看出BBR到底帮没帮上忙。