VPS网络加速实战：TCP BBR开启、队列算法与内核参数调优

一、为什么你的 VPS 带宽总是用不满

很多站长给 VPS 配了 100Mbps、甚至 1Gbps 的带宽，但实际下载速度只有几 MB/s，ping 值也不高，问题却一直存在。这通常不是商家限速，而是 Linux 默认的拥塞控制算法太"保守"。

Linux 默认的 cubic 算法是为传统长链路设计的，在高带宽高延迟（BDP 大）的链路下，它探测可用带宽的速度很慢，加窗像挤牙膏，于是带宽被白白浪费。Google 开源的 BBR（Bottleneck Bandwidth and Round-trip propagation time） 不再靠"丢包"判断拥塞，而是主动测量瓶颈带宽与最小 RTT，能显著跑满带宽、降低延迟，对跨境 VPS、CN2 线路尤其有效。

本文从内核检查开始，给出开启 BBR、调优内核参数的完整流程，并附上验证与排错方法。

二、确认内核版本与 BBR 模块

BBR 需要 Linux 4.9+ 内核，Debian 10 / Ubuntu 18.04+ / CentOS 8+ 默认都满足。先检查现状：

uname -r
# 示例输出：5.10.0-28-amd64，大于 4.9 即可

# 查看当前拥塞控制算法（默认一般是 cubic）
sysctl net.ipv4.tcp_congestion_control

# 查看内核支持的算法
sysctl net.ipv4.tcp_available_congestion_control

# 检查 BBR 模块是否可加载
modprobe tcp_bbr
lsmod | grep bbr

如果 tcp_available_congestion_control 里没有 bbr，多半是内核太老或没编译该模块，需要升级内核（Debian/Ubuntu 可用 elrepo / backports，或用秋水逸冰等一键脚本）。老内核也可以先跑 BBR 的 LKL 用户态方案，但不推荐在生产环境折腾。

三、开启 BBR 的正确姿势

开启 BBR 需要同时设置默认队列算法 fq（公平队列）和拥塞控制算法 bbr，写入 /etc/sysctl.conf 持久生效：

# 追加配置
cat >> /etc/sysctl.conf <<'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF

# 立即生效
sysctl -p

# 确认已切换
sysctl net.ipv4.tcp_congestion_control

看到输出 net.ipv4.tcp_congestion_control = bbr 即成功。注意：部分云厂商镜像把 sysctl.conf 设为只读或由 cloud-init 接管，改完重启后可能被还原，记得用 sysctl -p 验证，必要时写入 /etc/sysctl.d/99-bbr.conf 并重新生成 initramfs。

四、配合调优的内核参数（sysctl 全家桶）

BBR 只管拥塞控制，想要整体提速还需调整收发缓冲与连接队列。以下是一份经过生产验证的参数模板：

cat >> /etc/sysctl.d/99-net-perf.conf <<'EOF'
# 连接队列，抗并发
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# 收发缓冲，配合 BBR 吃掉大 BDP
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 开启 Fast Open（需 Nginx 侧同时开启 listen ... http2 so_keepalive）
net.ipv4.tcp_fastopen = 3

# 空闲连接不再降低慢启动阈值，利于长时间大流量
net.ipv4.tcp_slow_start_after_idle = 0

# 时间戳与 SACK 保底
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
EOF

sysctl --system
# 或 sysctl -p /etc/sysctl.d/99-net-perf.conf

注意事项：

• rmem_max/wmem_max 调大后，若有大量并发小连接会占内存，2G 内存以下的小鸡建议降到 8MB。
• tcp_fastopen = 3 表示客户端与服务端都开启；若后端程序不支持，可能引起连接异常，可退到 1（仅客户端）。
• 不要盲目叠加网上的"魔改"参数，尤其是关掉 tcp_timestamps 会影响 NAT 环境下的 RTT 估算。

五、验证加速是否真的生效

# 1. 确认算法已切换
sysctl net.ipv4.tcp_congestion_control

# 2. 用 ss 查看当前连接的拥塞算法
ss -tin | grep -i bbr
# 输出形如：cubic wscale:7,7 rto:204 rtt:12.3/4.5 时说明还没生效
# 输出包含 bbr 即生效

# 3. 实测带宽
wget -O /dev/null https://speed.cloudflare.com/__down?bytes=100000000
# 或用 iperf3 -c 目标IP 直接测

# 4. 观察是否出现 SACK 与重传率
ss -tin | grep -E 'rtt|retrans'

判断技巧：下载大文件时速度是否稳定贴着商家标称带宽；观看 ss -tin 里 rtt 抖动是否变小。若算法已切换但速度没变化，问题往往在下一节。

六、常见排错与注意事项

1. 开启了 BBR 但速度没提升
先怀疑商家 QoS：很多低价 VPS 标注"共享带宽/不限速"，实际做端口限速或按流量限速。用 iperf3 换不同时段多测几次排除高峰期。另外检查是否是 tc 或云监控把网卡限了：

tc qdisc show dev eth0
# 若有大量 "htb 1: 或 tbf" 输出，说明商家在系统内做了限速，BBR 无能为力

2. 与其他加速工具冲突
之前装过锐速（ServerSpeeder）、LotServer、魔改 BBR（bbrplus/bbr2）的，务必先卸载干净，它们会替换内核模块并占用 22 端口做授权校验，残留会导致新 BBR 失效甚至开机异常：

# 以锐速为例
/opt/ServerSpeed/serverSpeeder.sh uninstall
# 清理残留
rm -rf /appex /root/.acme.sh/..  # 仅示例，按实际残留路径清理

3. 重启后 BBR 丢失
检查 cloud-init 是否覆盖了 sysctl：cloud-init clean 后重启，或在 /etc/rc.local 里补一条 sysctl -w net.ipv4.tcp_congestion_control=bbr 兜底。

4. 大并发下内存告警
缩小缓冲参数并观察 free -h，同时用 ss -s 看连接数是否异常放大。

BBR 不是魔法：它只是把"被算法浪费的带宽"还给你。若线路本身丢包严重（跨境绕路），建议配合 WARP、中转或选择三网优化的商家线路，再叠加 BBR 使用。