买了香港CN2 VPS，商家标着100Mbps独享带宽，结果测速只能跑到30-50Mbps。找客服，对方甩过来一句“请检查本地网络”——本地宽带明明是500M的，问题到底出在哪?这种情况太常见了。香港CN2线路的带宽资源极其昂贵，商家标称的“独享”往往带着各种隐性限制。但抛开商家因素，服务器本身的内核参数配置不当，同样会让你的带宽发挥不出应有的水平。

　　先确认：带宽跑不满，是“谁”的锅

　　在动手调参数之前，先花五分钟做个基础判断。跑不满带宽可能来自三个层面：商家限制、本地瓶颈、服务器配置。

　　商家侧的限制是最难排查的，但有几个迹象：测速开始时很快(比如瞬间到80Mbps)，然后迅速下降到30Mbps并稳定——这是典型的QoS动态限速;或者白天正常、晚高峰明显掉速，说明共享带宽被邻居抢占。

　　本地瓶颈同样常见。用一台只有100Mbps上行的家用宽带去测1Gbps的VPS，结果永远卡在94Mbps左右，这组数据只能说明对端瓶颈。换一台同城云服务器做客户端再测。

　　服务器配置问题才是本文要解决的重点。如果本地和商家都没问题，测速工具显示吞吐量远低于标称值，那大概率是内核参数在拖后腿。

　　第一步：用iperf3做一次可信的基准测试

　　在调优之前，先拿到一个干净的基准数据。用iperf3而不是网页测速工具——后者混合了磁盘IO、浏览器开销和单线程窗口限制，误差来源太多。

　　服务端(你的香港VPS)：

# 安装
sudo apt install iperf3 -y

# 启动服务端
iperf3 -s

　　客户端(另一台你控制的机器)：

# 单线程测试
iperf3 -c 你的VPS_IP -t 30

# 多线程测试（更接近真实场景）
iperf3 -c 你的VPS_IP -P 4 -t 30

　　关键看两个数字：Bitrate(吞吐量)和Retr(重传次数)。如果单线程跑不满但多线程能跑满，问题在TCP窗口而不是带宽本身。如果重传次数很高，说明线路有丢包，那是网络层的问题，不是内核参数能解决的。

　　第二步：理解瓶颈——带宽延迟积(BDP)

　　调优的核心逻辑绕不开一个概念：BDP(Bandwidth-Delay Product，带宽延迟积)。

　　简单说，BDP = 带宽 × 往返延迟。它代表“在收到对方确认之前，这条链路上最多能塞进去多少数据”。香港到内地的典型RTT在40-80ms之间，如果带宽是100Mbps，那BDP大约是：100Mbps ÷ 8 × 0.06s ≈ 750KB

　　这意味着，你的TCP缓冲区至少要750KB以上，才能让带宽被完全利用。如果缓冲区只有128KB，TCP窗口就那么大，数据发出去就要等确认，带宽自然跑不满。

　　查看当前缓冲区大小：

sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

　　输出通常是类似 4096 87380 6291456 的三个值：最小值、默认值、最大值。如果最大值只有几MB，对于高BDP链路来说可能不够。

　　第三步：调整TCP缓冲区参数

　　根据BDP计算的结果，把缓冲区最大值调大。对于香港CN2 VPS(100Mbps-1Gbps带宽，RTT 40-80ms)，建议将缓冲区最大值设置在16MB-64MB之间。

　　编辑/etc/sysctl.conf，追加以下内容：

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

　　参数解释：

　　rmem_max/wmem_max：单个Socket缓冲区的硬上限

　　tcp_rmem/tcp_wmem：TCP接收/发送缓冲区的最小、默认、最大值

　　保存后生效：

sysctl -p

　　注意：缓冲区不是越大越好。设得太大会导致“缓冲区膨胀”(bufferbloat)，每个连接占用过多内存，在高并发场景下反而拖垮系统。16MB对于大多数香港VPS场景是够用的，如果带宽超过500Mbps，可以调到32MB或64MB。

　　第四步：启用BBR拥塞控制

　　这是整个优化流程中效果最明显的一步。

　　Linux默认的Cubic算法是“丢包驱动”的——它把丢包当作网络拥堵的信号，一旦检测到丢包就主动降速。香港到内地的跨境链路天然存在一定丢包率，Cubic在这种环境下会频繁误判，导致发送速率反复下降。

　　BBR是Google开发的算法，它不再依赖丢包判断拥堵，而是主动测量网络的瓶颈带宽和往返延迟。在跨境高延迟、有丢包的链路上，BBR的优势非常明显。

　　检查内核版本(BBR需要内核≥4.9)：

uname -r

　　Ubuntu 20.04默认内核是5.4，满足要求。

　　启用BBR：

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

　　验证是否生效：

sysctl net.ipv4.tcp_congestion_control
lsmod | grep bbr

　　如果输出net.ipv4.tcp_congestion_control = bbr，且lsmod能看到tcp_bbr模块，说明启用成功。

　　BBR和缓冲区的关系：BBR需要足够大的缓冲区才能发挥效果。如果缓冲区太小，BBR即使探测到了可用带宽，也无法把数据塞进管道里。第三步和第四步是黄金搭档，只做一半效果会打折扣。

　　第五步：其他值得调整的内核参数

　　除了缓冲区和拥塞控制，还有几个参数值得关注：

　　1. 连接队列：高并发场景下，如果连接队列满了，新连接会被丢弃。调大somaxconn和netdev_max_backlog：

net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535

　　2. TCP窗口缩放：确保窗口缩放功能已启用，否则窗口大小会被限制在64KB以内：

net.ipv4.tcp_window_scaling = 1

　　3. TCP Fast Open：允许在SYN包中携带数据，减少一次往返，对短连接场景有改善：

net.ipv4.tcp_fastopen = 3

　　第六步：验证优化效果

　　参数调完之后，用同样的iperf3命令再测一次，对比优化前后的数据。

iperf3 -c 你的VPS_IP -P 4 -t 30

　　重点关注：

• Bitrate是否提升？
• Retr是否下降？(如果重传次数没变，说明丢包来自线路本身，不是TCP配置问题)

　　如果优化后吞吐量有明显提升，说明调参起了作用。如果没有任何变化，那瓶颈可能在商家侧的QoS策略或者线路本身的质量上，继续折腾内核参数意义不大。

　　一个容易被忽视的“隐形瓶颈”：CPU和IO

　　还有一种情况：内核参数全调对了，BBR也开了，但带宽就是跑不满。这时候要检查CPU和磁盘IO。

　　1核CPU的VPS在跑大流量时，网络中断处理本身就会吃掉大量CPU时间。大流量还没跑满，CPU先满载了，带宽自然上不去。用top看一眼CPU占用，如果测速时CPU接近100%，那就不是网络的问题了。

　　磁盘IO同理。如果是下载站或文件分发场景，磁盘读取速度跟不上网络发送速度，也会表现为“带宽跑不满”。

　　总结：香港CN2 VPS跑不满带宽，排查顺序应该是：先用iperf3确认基准 → 检查本地和商家侧是否有硬限制 → 调整TCP缓冲区大小(按BDP计算)→ 启用BBR → 补充连接队列等其他参数 → 最后检查CPU和IO。

　　内核参数调优能解决的是“服务器自己没有发挥出应有能力”的问题。如果调完之后吞吐量纹丝不动，那说明带宽瓶颈来自商家策略或线路质量本身——这种情况下，换一家线路更实在的服务商，比继续折腾内核参数划算得多。