把 VPS 网速榨到极限：BBRv3、BBR Plus 与 XanMod 自定义内核升级指南

延伸阅读

更多相关攻略推荐：【VPS 硬件选型指南 (CPU 篇) 04】AMD EPYC 还是、【发行版选型 07】Arch Linux 深度科普：滚动发布、pac、【VPS 进阶玩法精选 014】ARM 架构 VPS 值不值得上？A、【对象存储 01】对象存储怎么选：Backblaze B2 vs C、【TCP优化 01】美国 VPS 跑不快？多半是没开 BBR，一个命。

一、你已经开了 BBR，为什么还要折腾内核

假设你已经按本站基础教程把经典的 BBRv1 打开了，网速确实比默认 cubic 快了一截。但事情没那么简单：BBRv1 是 2016 年随 Linux 4.9 合入主线内核的初代版本，它在"干净、缓冲深、独占"的链路上很强，但在共享瓶颈链路上有个老毛病——它基本无视丢包这个拥塞信号，于是会抢走本该分给邻居（跑 cubic 的流）的带宽，被吐槽"不公平"。Google 后来搞了 BBRv2、BBRv3 来修补这个问题，而主线内核从 6.4 版本开始把 BBRv3 带了进来。

所以本文不重复"BBR 是什么、怎么开"的基础，直接聊进阶：官方 BBRv3 到底改了什么、第三方魔改 BBR Plus 值不值得上、XanMod 这类高性能内核怎么装、以及装完怎么用 sysctl 把 TCP 缓冲区调到匹配你的大带宽高延迟线路。

二、BBRv3 相比 BBRv1 到底改了什么

根据社区对内核源码的梳理，BBRv3（约 2023 年随 6.4 主线引入）相对 v1 有这几处实打实的改进：

• 开始阶段增益下调。STARTUP 的 pacing gain 和 cwnd gain 从经典的 2.89 降到了 2.77。别小看这点，它让启动阶段在瓶颈处堆的队列更浅、丢包概率更低，相当于"起步别那么猛"。
• 更早识别拥塞。每个 RTT 内触发退出 STARTUP 的丢包事件阈值从 8 个降到 6 个，对拥塞反应更快，少发一堆注定丢的包。
• PROBE_RTT 改成动态。v1 永远把 inflight 降到固定的 4 个数据段去探测最小 RTT，v3 改成根据当前 RTT 和 RTprop 的偏差动态调整探测量，减少了不必要的吞吐抖动。
• 多流公平性大幅改善。v1 和 cubic 共存时公平性较差，v3 引入了 ECN（显式拥塞通知）和丢包信号，会稍微"手软"地退让，实测把约 30% 的 v1 吞吐增益还给了邻居，换来在共享链路上不被骂。
• 带宽收敛修复。多流共享瓶颈时，v1 的增益循环会导致带宽分配剧烈震荡，v3 通过改进相位同步机制实现了平滑收敛。

一句话：BBRv3 更"懂事"了，在高丢包、高延迟、多流竞争的跨境线路上表现比 v1 稳，但也因为更克制，单流极限吞吐比 v1 略低一点点。对普通 VPS 用户，默认选 v3 是更省心的选择。

三、第三方魔改：BBR Plus 是什么

BBR Plus 是国内社区（dog250 等作者）在官方 BBR 基础上打的"加速补丁"，目标是进一步压榨单边加速效果，尤其在存在一定丢包的弱网上把吞吐顶得更高。它的卖点是"比原版 BBR 还猛"，常配合一键脚本（如 jinwyp 的 one_click_script）安装 4.14.129 或 5.10 LTS 的 BBR Plus 内核。

优点很直接：弱网、有丢包时体感可能比原版更猛，很多跨国网络访问/代理场景喜欢它。缺点也得说清楚：它是第三方魔改，不在主线内核里，安全更新滞后、内核版本偏老（常见 4.14 / 5.10），而且"更猛"意味着在共享瓶颈上更不友好、更容易被邻居或运营商限速策略针对。我的看法：如果你只关心自己这条链路的极限速度、且机器是独享带宽，可以试；如果机器在 crowded 的共享口上，BBRv3 反而更稳更不容易翻车。

四、XanMod / Liquorix：高性能内核怎么选

想用上官方 BBRv3，你的内核得是 6.4 以上。很多 VPS 默认还是 5.10 / 5.15 这种 LTS，自带的是 BBRv1。要升级又不自己编译，最省事的就是装第三方高性能内核发行版：

• XanMod。面向桌面和服务器的性能内核，开了 BBRv3、增强了调度和网络栈，对高吞吐和延迟敏感负载友好。它按 CPU 微架构分了 x64v1 / v2 / v3 / v4 几个包，越往后要求越新的 CPU 指令集（v3 需要 AVX2 等）。近几年买的 VPS 大多能上 x64v3。
• Liquorix。基于 Zen 内核、偏桌面低延迟调校，也常被拿来做服务器网络优化，风格和 XanMod 类似但侧重点不同。

选型建议：通用服务器无脑 XanMod（稳定版 linux-xanmod-x64v3，追新可上 linux-xanmod-edge）；追求极致低延迟的桌面/游戏类负载可以看 Liquorix。切记：第三方内核不保证和你的云厂商驱动 100% 兼容，下面专讲避坑。

五、实战：升级 XanMod 内核（Debian / Ubuntu）

下面以 Debian / Ubuntu 为例，最稳妥的流程：

• 第一步，确认架构。换内核只支持 KVM / 裸金属架构的 VPS；OpenVZ、LXC 这种共享内核的容器根本换不了，别白费劲。用命令 hostnamectl 或 cat /proc/1/cgroup 大致判断，或者直接 lscpu 看虚拟化类型。
• 第二步，导入 XanMod 签名密钥并加源：先下载 archive.key 用 gpg --dearmor 写进 /usr/share/keyrings/xanmod-archive-keyring.gpg，再把 deb [signed-by=...] http://deb.xanmod.org releases main 写进 /etc/apt/sources.list.d/xanmod-kernel.list。
• 第三步，安装内核：apt update 后执行 apt install linux-xanmod-x64v3 -y。安装过程会自动生成新的 GRUB 配置。
• 第四步，更新引导并重启：执行 update-grub，然后 reboot。重启后 uname -r 输出里应带 xanmod 字样，例如 6.6.12-x64v3-xanmod1。
• 第五步，开启 BBRv3。编辑 /etc/sysctl.conf，加入 net.core.default_qdisc = fq 和 net.ipv4.tcp_congestion_control = bbr，保存后 sysctl -p 生效。用 sysctl net.ipv4.tcp_congestion_control 确认输出是 bbr。注意装了 XanMod 后这个值往往默认已是 bbr。

小提示：新手如果怕敲错命令，社区有一键脚本（如 LXBBR 工具箱）把内核升级、算法切换、队列选择和参数调优都做成中文菜单，零门槛。但一键脚本也要从可信源拉，别乱 curl 不明链接。

六、避坑：网卡驱动冲突、KVM/OVZ、GRUB 与 DKMS

• 确认能换内核。OpenVZ / LXC 容器换不了内核，只能在 KVM 或裸金属上操作。这是第一大坑，先确认再动手。
• 网卡驱动冲突。某些 VPS 用的是云厂商定制网卡（如部分 ENS、virtio 变体或旧版 e1000），新内核可能没自带对应模块，重启后网卡起不来、直接失联。稳妥做法：操作前确保有 VNC / 串口控制台（云面板自带的"救援模式"）能救砖；或者先保留旧内核，在 GRUB 里确认新内核能正常进系统再设为默认。
• DKMS 模块。如果你装了 WireGuard、某些 HIDS、或第三方文件系统模块的 DKMS 版本，换内核后 DKMS 需要重新为 6.x 内核编译，可能失败。升级后跑一遍 dkms status 检查，必要时重装对应模块包。
• GRUB 默认项。多内核共存时，确认 GRUB_DEFAULT 指向新内核；部分发行版用 boot-order 而不是 GRUB_DEFAULT，重启后要用 uname -r 验证确实进了新内核，而不是静默回退到旧版。
• 别在 Production 直接试。先在测试机或快照/备份后操作，重启失联能秒回滚。

七、sysctl 调优 rmem / wmem，匹配大带宽高延迟

光换内核开 BBR 还不够。BBR 管的是"发送节奏"，但 TCP 套接字读写缓冲区（rmem / wmem）决定了"路上能同时塞多少数据"。在跨境这种高带宽、高延迟（长肥管道，long-fat pipe）线路上，默认缓冲区太小会直接把吞吐上限锁死。

核心公式是带宽时延积 BDP = 带宽 × 往返时延。举例：200Mbps 带宽、RTT 100ms 的链路，BDP ≈ 200,000,000 × 0.1 ÷ 8 ≈ 2.5 MB。也就是说你的接收缓冲区至少得覆盖 2.5 MB，否则管道永远喂不满。一般把 max 设成 BDP 的 2~4 倍留余量。

实操，把下面写进 /etc/sysctl.d/99-tcp-tuning.conf 后执行 sysctl -p：

• net.core.rmem_max = 67108864（接收缓冲区上限 64MB）
• net.core.wmem_max = 67108864（发送缓冲区上限 64MB）
• net.ipv4.tcp_rmem = 4096 87380 67108864（TCP 接收：最小 默认 最大）
• net.ipv4.tcp_wmem = 4096 65536 67108864（TCP 发送：最小 默认 最大）
• net.ipv4.tcp_window_scaling = 1（窗口缩放，高 BDP 必需，默认已开）
• net.ipv4.tcp_timestamps = 1 和 net.ipv4.tcp_sack = 1（提升 RTT 估计与重传效率）

注意：tcp_rmem / tcp_wmem 的 max 不能超过 rmem_max / wmem_max；缓冲区不是越大越好，过大反而吃内存、还可能加重 bufferbloat。按你实际链路的 BDP 算，10Gbps 级别才需要 128MB 那种量级。改完用 iperf3 在调优前后各跑一次对比，眼见为实。

八、怎么验证你真的变快了

• 确认内核：uname -r 看到 xanmod 且版本 ≥ 6.4。
• 确认算法：sysctl net.ipv4.tcp_congestion_control 输出 bbr；用 ss -ti 看具体连接的算法。
• 跑基准：两端 iperf3 -s / iperf3 -c 目标 -t 30 -w 64M，对比调优前后吞吐；跨境建议挑离你用户近的节点测。
• 看实际体感：下载大文件、测代理速度，观察是否稳定拉满套餐带宽，长时间传输丢包率是否下降。

最后提醒一句：BBR 不是万能药。在最后一公里的浅缓冲、高竞争住宅链路上，cubic 有时反而更稳；算法选哪个，取决于你的 RTT 波动、丢包率和瓶颈在核心还是边缘。调好内核和缓冲区，再用实测数据说话，别盲信"开了就快三倍"的传说。