WP Panel 新增系统内核优化，BBR+FQ 默认开启，跨洋访问成功率提升 13%

听取Diiamo的建议，给WP Panel面板的安装脚本新增了系统内核优化环节，安装完成后自动应用一套经过筛选的网络与内核调优参数（BBR+FQ、TCP缓冲、连接队列、文件描述符）。

优化项目一览

类别

优化项

作用

拥塞控制

BBR + FQ（2 核及以上默认开启）

替代内核默认的 Cubic 算法，提升高延迟/有丢包场景下的吞吐量

连接队列

somaxconn / tcp_max_syn_backlog / netdev_max_backlog

突发流量时不丢连接请求

TCP 缓冲区

rmem_max / wmem_max / tcp_rmem / tcp_wmem

增大网络收发缓冲，提高大文件传输速度

TIME-WAIT

tcp_tw_reuse / tcp_fin_timeout / 端口范围扩大

加速连接回收，减少端口耗尽

Keepalive

缩短空闲探测间隔

更快清理死连接，释放服务器资源

文件描述符

nofile 65535

解除单进程文件打开数限制，支持高并发

基础安全

tcp_syncookies / tcp_sack / tcp_timestamps

SYN flood 防护 + 选择确认 + 时间戳

单核机器会跳过 BBR：学术研究发现，在 CPU 被宿主邻居抢占的单核 VPS 上，BBR 吞吐量可能不升反降。WP Panel 安装脚本会自动检测 CPU 核心数，单核环境下保留系统默认的 Cubic，不做强行替换。

核心优化：BBR + FQ

什么是 BBR？

BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 开发的 TCP 拥塞控制算法。Linux 内核默认的 Cubic 算法诞生于 2006 年，它的核心逻辑是”丢包 = 拥塞”，一检测到丢包就大幅降速。这在光纤普及、无线网络占主导的今天已经过时——丢包不一定是因为拥塞，可能只是无线信号波动或物理线路噪声。

BBR 不把丢包当作拥塞信号，而是持续测量网络的瓶颈带宽和往返时延，以此来控制发送速度。结果是：在有丢包但带宽充足的长距离链路上，BBR 的吞吐量远超 Cubic。

为什么必须搭配 FQ？

FQ（Fair Queue）是 Linux 内核的公平队列调度器。BBR 依赖精确的数据包发送节奏控制，如果不用 FQ 搭配，内核会退化为高精度定时器模式，每个连接都产生额外的 CPU 开销。两者必须同时开启。

BBR 在普通服务器上开箱即用吗？

不完全是。Debian 13 的内核已内置 BBR 模块（tcp_bbr），但默认不启用。需要手动写 sysctl 配置 + 加载内核模块。WP Panel 的安装脚本把这步自动化了。

对比测试

测试环境

BBR 组

Cubic 组

服务商

Vultr

机房

芝加哥

机型

共享 CPU，2 核 2G，65GB SSD

系统

Debian 13

拥塞控制

BBR

Cubic（Vultr 默认开启 BBR，我们手动关闭后测试）

队列调度

特别说明：Vultr 的 Debian 13 镜像默认启用了 BBR。我们在 Cubic 组所在的机器上手动执行 sysctl -w net.ipv4.tcp_congestion_control=cubic 关闭 BBR 后进行对比。

测试机

服务商

腾讯云

机房

广州

机型

轻量云服务器

测试工具

wrk 4.1.0、curl

低并发测试（2 线程 / 10 连接 / 30 秒）

两组服务器均运行相同的 WordPress 站点。测试机从国内发起 HTTPS 请求，模拟真实访客通过跨太平洋链路访问网站。

wrk -t2 -c10 -d30s https://bbr.wp-panel.org/
wrk -t2 -c10 -d30s https://nobbr.wp-panel.org/

指标

BBR

Cubic

BBR 优势

平均延迟

793.08 ms

524.09 ms

—

总完成请求数

367

313

+17.3%

每秒请求数

12.22

10.43

+17.2%

每秒传输量

828.88 KB

712.44 KB

+16.3%

超时请求数

少 97.6%

请求成功率

99.7%

86.9%

+12.8 个百分点

为什么平均延迟更高，结果反而更好？

一个反直觉的数据点：BBR 组的平均延迟是 793ms，Cubic 组是 524ms。看起来 Cubic 更快？

实际上，跨太平洋链路存在不可避免的随机丢包。Cubic 把丢包当成拥塞信号，一旦丢包就砍半降速，降到底之后就超时放弃——测试中 41 个请求因此直接失败，没有被计入平均延迟统计。Cubic 的”低延迟”实际上是淘汰了慢请求后的幸存者偏差。

BBR 不把丢包当拥塞，继续保持稳定的发送节奏，几乎全部请求都顺利完成。367 次请求中只超时 1 次，成功率 99.7%。而 Cubic 的 313 次请求中失败了 41 次，成功率仅 86.9%。

换句话说：BBR 不是让每个请求跑得更快，而是让更多请求能跑完。

不要神化 BBR

测试中 BBR 在成功率上完胜 Cubic，但这不意味着开启 BBR 就能让网站脱胎换骨。

BBR 优化的是 TCP 传输层——也就是数据”怎么从服务器发出去”。它能做的上限，受制于服务器的硬件配置和网络带宽。一台 1 核 1G、10Mbps 带宽的 VPS，不管用什么拥塞控制算法，都不可能跑出 100Mbps 的效果。

真正决定网站体验的，按优先级排：

硬件和带宽 — CPU 核心数、内存大小、网络带宽是物理天花板
服务器整体优化 — Nginx 配置、PHP-FPM 进程管理、数据库索引、Redis 缓存、Swap 策略、文件描述符限制……WP Panel 安装脚本一次性覆盖了这些
TCP 拥塞控制 — 也就是 BBR，是锦上添花，不是雪中送炭

把 BBR 想象成变速器的调校——它能让发动机的动力更高效地传到轮子上，但如果发动机本身就是小排量，调校再好也跑不进 5 秒破百。

WP Panel 的系统内核优化模块把 BBR 设为默认，是因为它确定有益且零成本——不需要额外硬件、不需要额外付费、不需要维护。但它只是面板整体优化方案中的一环，不是全部。

单文件下载测试

curl -o /dev/null -w "%{speed_download}" https://****/twentytwentyfive/style.css

三次下载取平均（单位：B/s）：

次数

BBR

Cubic

第 1 次

3,885

3,403

第 2 次

2,311

2,286

第 3 次

4,628

4,263

平均

3,608

3,317

小文件下载速度，BBR 平均快 8.8%。

总结

WP Panel 此次新增的系统内核优化，核心是将 BBR + FQ 作为默认的网络传输方案。对于 WordPress 站点来说，访客往往分布在不同网络环境中，跨地区、跨运营商的访问不可避免。BBR 在这种场景下的优势——不是让网站变快，而是让更多人能顺利打开。

如果你还没有启用 BBR，手动开启只需两行命令：

echo "net.core.default_qdisc=fq" >> /etc/sysctl.d/99-bbr.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.d/99-bbr.conf
sysctl --system
modprobe tcp_bbr

或者，直接使用 WP Panel 安装脚本，所有优化自动完成。