VPS 网络优化实战：从内核到应用层

买了 VPS 却发现速度慢、丢包高、网页加载卡，往往不是带宽不够，而是网络路径和协议栈没有调好。这篇文章从内核拥塞控制、TCP 参数、CDN 优选、代理协议选择四个层面，讲清楚怎么让一台普通 VPS 的网络体验接近专线。

一、先诊断：问题出在哪一层

优化之前要定位瓶颈：

物理层/路由层：本地到 VPS 的 RTT、丢包、抖动；
传输层：TCP 拥塞控制、窗口大小、连接数限制；
应用层：代理协议、TLS 握手、DNS 解析、并发连接。

基础诊断命令：

# 看路由和每一跳延迟
mtr -r -c 100 your-vps-ip

# 看 TCP 连接状态
ss -s

# 看当前拥塞控制算法
sysctl net.ipv4.tcp_congestion_control

# 看带宽和丢包（服务端和客户端都跑）
iperf3 -s  # 服务端
iperf3 -c your-vps-ip -t 30  # 客户端

二、内核层：开启 BBR

BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 提出的拥塞控制算法。传统 Reno/Cubic 靠丢包判断拥塞，容易在高延迟、高丢包链路上把窗口压得太小；BBR 直接估计带宽和 RTT，能更激进地利用链路。

2.1 检查内核版本

BBR 需要 Linux 4.9+，BBRv2 / BBR3 需要更新内核。建议用 ELRepo 升级 CentOS 内核，或直接用 Ubuntu 22.04+/Debian 12。

# 查看当前内核
uname -r

# CentOS 升级内核示例
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
dnf install https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm -y
dnf --enablerepo=elrepo-kernel install kernel-ml -y
grub2-set-default 0
reboot

2.2 开启 BBR

# 编辑 /etc/sysctl.conf 或创建 /etc/sysctl.d/99-bbr.conf
cat <<EOF > /etc/sysctl.d/99-bbr.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_notsent_lowat = 16384
EOF

sysctl --system

# 验证
sysctl net.ipv4.tcp_congestion_control
lsmod | grep bbr

对于高丢包链路，可以尝试 BBRv3 或配合 fq_codel / cake qdisc。注意：BBR 在带宽竞争激烈的共享线路上可能表现不如 Cubic「礼貌」，但单用户 VPS 场景下通常更优。

三、TCP 参数调优

除了拥塞控制，还有几个参数显著影响吞吐：

cat <<EOF > /etc/sysctl.d/99-tcp-tune.conf
# 文件描述符与连接数
fs.file-max = 1048576
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535

# TCP 内存（按机器内存调整，单位 page，通常 4KB）
net.ipv4.tcp_mem = 786432 1048576 1572864
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# 连接复用与保活
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# 关闭反向路径过滤（多网卡 / 代理场景）
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
EOF

sysctl --system

调完用 iperf3 重新测速，观察吞吐和 CPU 占用。如果 CPU 满了而带宽没跑满，说明是加密/应用层瓶颈，不是 TCP。

四、CDN 优选：让入口更近

如果你的服务面向国内用户，VPS 在海外，直接访问往往绕路严重。通过 Cloudflare 等 CDN 可以把入口放到离用户更近的节点。

4.1 Cloudflare 优选 IP

Cloudflare 有几百个边缘节点，不同运营商访问不同 IP 速度差异巨大。可以通过工具批量测速，找出本地最快的 IP：

CloudflareSpeedTest：国内常用的 CF IP 测速工具；
测完后把最优 IP 写进 hosts，或者自建 DNS 分流。

# 示例：把 cf.example.com 解析到优选 IP
# /etc/hosts
104.19.157.118 cf.example.com

4.2 源站回源优化

CDN 到源站的回源链路也要优化：

开启 Cloudflare Argo Smart Routing：动态选择更优路径回源；
启用 gRPC 或 HTTP/2 多路复用，减少连接数；
源站部署在 BGP 线路或多线机房，减少跨网绕路。

五、代理协议选择

如果你用 VPS 做代理，协议选择直接影响延迟和稳定性：

协议	优点	缺点	适用场景
VMess / VLESS + WS/TCP	兼容性好，可套 CDN	TCP 握手开销大	通用翻墙
Hysteria2 / TUIC	QUIC 多路复用，抗丢包	UDP 易被 QoS	网页、视频、游戏
Reality / XTLS	TLS 指纹伪装强	配置复杂	高审查环境
WireGuard	内核态，吞吐高	UDP 易被 QoS，不能套 CDN	内网组网、高吞吐

针对网页加载慢的优化思路：减少每个网页需要新建的 TCP 连接数。这就是为什么 Hysteria2 / TUIC 这类基于 QUIC 的协议，在「延迟可接受但网页加载卡」的场景下往往体验更好。

六、应用层优化

即使网络层调好了，应用层细节也会拖慢体验：

TLS 1.3 + 0-RTT：减少握手往返；
HTTP/2 或 HTTP/3：多路复用、头部压缩；
BBR + 启用 TCP Fast Open：net.ipv4.tcp_fastopen = 3；
DNS 分流：国内域名走国内 DNS，海外域名走代理或 DoH；
连接池与 Keep-Alive：Nginx / 代理客户端保持长连接。

# Nginx 示例优化
server {
    listen 443 ssl http2;
    
    ssl_protocols TLSv1.3;
    ssl_prefer_server_ciphers off;
    
    keepalive_timeout 65;
    keepalive_requests 1000;
    
    gzip on;
    gzip_types text/plain text/css application/json application/javascript;
}

七、验证优化效果

改完后不要凭感觉，要测数据：

iperf3：测试纯 TCP 吞吐；
ping / mtr：看 RTT 和丢包；
curl -w：测 TTFB、TLS 握手时间、总耗时；
浏览器 DevTools：看每个资源加载瀑布流。

# 测首字节时间和总时间
curl -o /dev/null -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://your-site.com

小结

VPS 网络优化是系统工程：内核层开 BBR 提升高延迟链路吞吐，TCP 参数 释放连接潜力，CDN 优选 缩短用户到入口的距离，代理协议 根据场景选择最合适的传输方案。

不要一次性改太多，每次改一项就测一项。最终目标不是跑满带宽，而是在你的实际使用场景下（网页、视频、代码同步、SSH）达到稳定、低延迟的体验。

← 返回首页