VPS 到手网速拉胯？BBR 开启 + TCP 参数调优实战，把闲置带宽榨出来
很多朋友 VPS 到手，跑完一遍 yabs….
很多朋友 VPS 到手，跑完一遍 yabs.sh 一看，CPU、内存、硬盘都还行，可一测速——下载只有几十 Mbps，跨境传输更是惨不忍睹。于是不少人转身去装各种「一键加速脚本」，有的还要改内核、装锐速，折腾一圈，机器反而更不稳了。今天这篇，大叔就聊聊 VPS 网络提速最实在的一招：BBR，再顺手把几个关键的 TCP 参数调一下。全程不用装任何第三方脚本，只用系统自带的内核和 sysctl，稳，也干净。
一、BBR 到底是什么，为什么它能提速
BBR 是 Google 在 2016 年开源的一套拥塞控制算法，全称 Bottleneck Bandwidth and Round-trip propagation time。传统算法（比如老牌的 CUBIC）判断「网络堵不堵」主要靠丢包：一旦发生丢包就认为拥塞，主动压低发送速度。这个思路在局域网、国内低延迟线路上还行，可一碰到跨境、高延迟、带一定丢包率的链路，就特别吃亏——它会把线路本身的正常抖动误判成拥塞，导致发送窗口始终涨不上去，带宽白白浪费。
BBR 的思路完全反过来：它不盯着丢包，而是持续测量当前链路的最大带宽（Bottleneck Bandwidth）和最小往返时延（RTT），让发送速率尽量贴着物理带宽的上限走。所以同样的线路，开了 BBR 之后，高延迟场景下的吞吐量常常有明显提升，尤其适合 VPS 这种跨境传输场景。
这里得先把话说清楚：BBR 是拥塞控制算法，不是「翻墙加速器」，它突破不了物理线路的带宽上限，也改变不了线路本身的质量。它能做的是——让你的机器把现有线路的潜力尽量榨干，别再因为算法保守而白白降速。
二、开启之前，先看内核够不够
BBR 从 Linux 4.9 内核开始内置，4.20 之后又加入了 BBRv2 的早期支持，5.x 内核已经相当成熟。所以先查一下内核版本和当前用的算法：
uname -r
sysctl net.ipv4.tcp_congestion_control如果内核低于 4.9，说明这 VPS 的系统镜像太老了，建议直接重装一个较新的系统——Debian 12、Ubuntu 24.04 都自带 5.x 或 6.x 内核，省心。如果内核够新，第二条命令输出的默认算法大概率还是 cubic，我们接下来就把它换成 bbr。
三、三步开启 BBR
第一步，确认 BBR 模块在不在：
modprobe tcp_bbr
lsmod | grep bbr第二步，把配置写进 sysctl 的持久化文件，这样重启也不会丢：
cat > /etc/sysctl.d/99-bbr.conf <<'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF这里有两个关键点：一是拥塞控制算法设为 bbr，二是默认队列调度器 default_qdisc 要设成 fq（Fair Queueing）。BBR 官方推荐配合 fq 一起用，别只设 bbr 忘了 fq，否则效果会打折扣。
第三步，让配置生效并验证：
sysctl --system
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc当这两条命令分别输出 bbr 和 fq，就说明 BBR 已经跑起来了。
四、再顺手调几个 TCP 参数
光开 BBR 还不够，默认的缓冲区往往偏保守。下面这几个参数，是我在几台 VPS 上长期用的，兼顾高带宽传输和高并发连接：
cat > /etc/sysctl.d/99-tcp-tuning.conf <<'EOF'
# 扩大发送/接收缓冲区上限（单位：字节）
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
# 自动调优区间：最小 默认 最大
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
# 开启窗口缩放和 MTU 探测
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_mtu_probing = 1
# 空闲后不要立刻慢启动（对长连接友好）
net.ipv4.tcp_slow_start_after_idle = 0
# 开启 TCP Fast Open（3 表示客户端+服务端都启用）
net.ipv4.tcp_fastopen = 3
# 高并发连接相关
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 65535
EOF
sysctl --system简单解释几句：rmem_max / wmem_max 是单条连接缓冲区的上限，设成 128MB 是为了在高速大带宽场景下不被缓冲区卡住；tcp_slow_start_after_idle = 0 是让长连接空闲一段时间后不用重新慢启动，对 API 服务和数据库连接很友好；tcp_fastopen = 3 能省掉一次握手往返，对短连接密集的服务（比如 Web 静态资源）有收益。至于那三个 backlog 参数，是给高并发场景准备的，扛并发时能明显减少丢握手的情况。
五、验证效果：别只看宣传，自己测
调完之后，用 speedtest 前后对比一下才实在。单机测速最省事，装个 speedtest-cli 就行：
apt update && apt install -y speedtest-cli
speedtest-cli这里大叔得泼盆冷水：BBR 不是万能的。如果线路本身带宽就小，或者运营商 QoS 严重，开 BBR 也不会有质的飞跃。它擅长的是「把保守算法的浪费找回来」，而不是「无中生有变出带宽」。所以测完如果提升不明显，先怀疑线路，别怀疑自己配错了。
六、那些「一键加速脚本」，尽量别碰
最后说点掏心窝的。网上各种「一键 BBR / 一键锐速」脚本，动不动就要替换内核、加载第三方模块。大叔的建议是：能不装就不装，原因有三：
- 内核是系统的心脏，乱换容易出兼容性问题，尤其 VPS 是虚拟化环境，换内核风险更高。
- 有些脚本会往系统里塞来路不明的二进制，安全上不放心。
- 现在的 5.x/6.x 内核自带 BBR 已经够好用了，除非有极端特殊需求，否则没必要为了那一点点差异去冒险。
系统自带 + 官方内核，才是长期稳定运行的底气。
结语
VPS 提速这件事，与其迷信脚本，不如先把 BBR 和 TCP 参数这两件「基础内功」练扎实。一套配置写进 sysctl，重启也不丢，干干净净。下次 VPS 到手，记得先别急着装面板，把这两步做了，再谈其他。
