VPSKnow

网络性能测试与优化指南

中高级
45分钟

从基础的测速、监控,到进阶的 BBR 开启、NextTrace 路由诊断和内核参数调优,本指南将带您全面掌握 VPS 网络性能的测试与极致优化方法,最大化您的服务器价值。

📊 性能指标解读

在开始测试前,了解评估 VPS 性能的几个核心指标至关重要。

🚀

带宽 (Bandwidth)

网络连接的最大数据传输速率 (Mbps/Gbps),决定了文件上传下载的速度和数据吞吐能力。

⏱️

延迟 (Latency)

数据包往返服务器所需的时间 (ms)。延迟越低,网站响应和 SSH 操作越快。

🧭

路由路径 (Route)

数据包从源到目的地经过的网络路径。优质的路由(如 CN2 GIA)能显著降低延迟和丢包。

💾

磁盘 I/O

硬盘的读写速度 (MB/s),直接影响网站加载、数据库查询和编译等任务的效率。

诊断篇:性能全面测试

1. 带宽速度测试

测试 VPS 的上下行带宽是评估其网络质量的第一步。

1

工具一:Ookla Speedtest

最权威的命令行测速工具,能很好地反映您 VPS 到全球骨干网的"日常"网络表现。

# Debian/Ubuntu 系统安装
apt update && apt install curl -y
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | bash
apt install speedtest -y

# 运行测试 (同意协议后将自动寻找最优节点)
speedtest

结果中的 Download 和 Upload 即为服务器的下行和上行带宽。

2

工具二:iPerf3 (测极限吞吐)

更专业的网络性能测试工具,用于测试两点(如您的本地电脑与 VPS)之间的真实极限带宽。

# 服务端 (Server A - 您的 VPS)
apt install iperf3 -y && iperf3 -s

# 客户端 (Server B - 您的本地或其他机器)
# 替换 SERVER_A_IP 为您 VPS 的真实 IP
apt install iperf3 -y && iperf3 -c SERVER_A_IP -P 8 -R

说明:-P 8 开启 8 线程并行测试以榨干带宽;-R 测试下行速度。

🗺️ 进阶篇:真实路由与丢包排查

带宽大不代表速度快。 如果您的服务器在洛杉矶,但数据包非要绕道欧洲再回中国,那么延迟和丢包就会高得离谱。排查"回程路由"是判断 VPS 线路好坏(如 CN2 GIA、9929)的唯一金标准。

🔍 丢包检测:MTR

MTR 结合了 ping 和 traceroute 的功能,能持续诊断路由路径上每个节点的丢包率 (Loss%)。

# 安装 MTR
apt install mtr -y

# 运行 MTR 报告模式,发送 10 个包到 Google DNS
mtr -r -c 10 8.8.8.8

路由可视化神器:NextTrace

MTR 看丢包很准,但它不显示节点对应的物理位置。推荐使用开源界的当红神器 NextTrace,它能在终端直接画出路由地图,并标记出 ASN 和骨干网类型。

# 一键安装 NextTrace
bash <(curl -Ls https://raw.githubusercontent.com/sjlleo/nexttrace/main/nt_install.sh)

# 测试回程路由 (以测试上海电信为例)
nexttrace 101.227.255.45
💡 优质路由特征一览:
  • 59.43.x.x (中国电信 CN2 GIA):最顶级的越洋专线,晚高峰依然丝滑。
  • AS9929 (中国联通 A网):联通的 VIP 线路,对标 CN2,性价比极高。
  • AS58453 (中国移动 CMIN2):移动新一代精品网。
  • 注意:如果看到全是 202.97 (163骨干网),说明是普通线路,晚高峰大概率卡顿。

3. 磁盘 I/O 测试

dd & fio (读写测试)

快速评估硬盘性能。

# dd (简单顺序读写)
dd if=/dev/zero of=test bs=1M count=1024 conv=fdatasync

# fio (专业随机读写,测试 4K IOPS)
apt install fio -y
fio -name=randrw -ioengine=libaio -iodepth=16 -rw=randrw -bs=4k -size=1G -numjobs=1 -runtime=60 -group_reporting

vnStat & iftop (流量监控)

实时查看谁在消耗您的带宽。

# vnStat (历史统计)
apt install vnstat -y
vnstat -l

# iftop (实时监控)
apt install iftop -y
iftop

2026 新工具:Trippy / Bandwhich / nethogs

MTR 和 iftop 是经典工具,但 Rust 生态近年涌现了一批性能更好、界面更现代的替代品,值得关注:

🗺️

Trippy

新一代路由追踪

Rust 编写,比 MTR 更现代的 TUI 界面,支持 ICMP/UDP/TCP 三种协议,实时动态刷新,支持导出 JSON 报告。

📊

Bandwhich

按进程显示带宽

Rust 编写,实时显示每个进程/连接的带宽占用,快速找出"流量杀手"。比 iftop 更直观。

🐷

nethogs

轻量进程流量监控

C 编写,专注于显示哪个进程占用了多少带宽,比 nethogs 更轻量,apt 直接安装。

Trippy 安装与使用

Trippy - 现代化路由追踪
# Trippy:新一代 TUI 路由追踪工具(Rust 编写,比 MTR 更现代)
# 安装(Debian/Ubuntu)
wget https://github.com/fujiapple852/trippy/releases/latest/download/trippy-x86_64-unknown-linux-gnu.tar.gz
tar xzf trippy-x86_64-unknown-linux-gnu.tar.gz
mv trip /usr/local/bin/

# 运行(交互式 TUI,实时更新,支持 ICMP/UDP/TCP 多协议)
trip 8.8.8.8

# 报告模式(类似 mtr -r)
trip --report-cycles 10 8.8.8.8

Bandwhich / nethogs 安装与使用

Bandwhich + nethogs - 按进程显示带宽
# Bandwhich:按进程/连接实时显示带宽占用(Rust 编写)
# 安装
wget https://github.com/imsnif/bandwhich/releases/latest/download/bandwhich-x86_64-unknown-linux-gnu.tar.gz
tar xzf bandwhich-*.tar.gz && mv bandwhich /usr/local/bin/

# 运行(需要 root 权限,实时显示哪个进程/IP 在消耗带宽)
sudo bandwhich

# nethogs:同类工具,更轻量,apt 直接安装
apt install nethogs -y && nethogs

优化篇:网络性能提升

核心优化:BBR 加速

BBR 是 Google 开发的 TCP 拥塞控制算法。开启 BBR 是提升 VPS 网络性能最有效、最简单的方法,尤其在跨国高延迟链路上,速度翻倍是常态。

开启系统原生 BBR

# 写入 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

进阶优化:内核网络参数调优

提示:这是进阶操作。通过扩大 TCP 窗口缓冲,可极大提升大带宽高延迟(长距离跨国)环境下的吞吐量。

将以下内容追加到 /etc/sysctl.conf 文件,然后执行 sudo sysctl -p 即可生效。

# 开启 TCP Fast Open
net.ipv4.tcp_fastopen = 3

# 允许 TIME_WAIT 状态的套接字重新用于新连接
net.ipv4.tcp_tw_reuse = 1

# 增加系统级最大文件句柄数
fs.file-max = 1000000

# 增加进入队列的 TCP 连接最大数
net.core.netdev_max_backlog = 262144
net.ipv4.tcp_max_syn_backlog = 262144

# 增加 TCP 读写缓冲区大小
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432

🪤 避坑:IPv6 优先导致的卡顿

很多现代 VPS 默认开启了双栈(IPv4 + IPv6)。Linux 默认会优先使用 IPv6 发起外网请求。但很多时候,VPS 的 IPv6 路由极其糟糕,导致您在执行 apt updatecurl 甚至连接 GitHub 时长时间卡死无响应。

解决方案:修改 gai.conf,让系统优先走 IPv4。

# 编辑 gai.conf 文件
sed -i 's/#precedence ::ffff:0:0\/96  100/precedence ::ffff:0:0\/96  100/' /etc/gai.conf

# 验证效果 (看 ping 域名是否优先解析出 IPv4)
ping google.com

工具篇:一键脚本与终极优化

终极优化:升级 XanMod 内核 (开启 BBRv3)

如果您对原版 Linux 内核的网络性能仍不满意,可以考虑安装著名的 XanMod 第三方高响应内核,它默认集成了 Google 最新研发的 BBRv3 算法,进一步降低延迟并提高吞吐率。

# 注册 PGP 密钥并添加 APT 存储库
wget -qO - https://dl.xanmod.org/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/xanmod-archive-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/xanmod-archive-keyring.gpg] http://deb.xanmod.org releases main' | sudo tee /etc/apt/sources.list.d/xanmod-release.list

# 安装高响应内核 (推荐 v3)
sudo apt update && sudo apt install linux-xanmod-x64v3 -y

# 重启服务器生效
sudo reboot

常用一键评测脚本

YABS (Yet Another Bench Script)

功能全面

最权威的机器综合跑分脚本,含网络测速、磁盘 IO 测试及 Geekbench CPU 跑分。

curl -sL yabs.sh | bash

Bench.sh

经典轻量

快速显示系统基础信息、IO 表现及各大洲测速节点表现。

wget -qO- bench.sh | bash

📈 进阶:Smokeping 长期延迟监控

YABS 和 MTR 是一次性测试工具。但网络质量问题往往是间歇性的——晚高峰才出现卡顿、每隔几天就有丢包高峰。Smokeping 能 7×24 小时持续探测目标延迟,生成漂亮的历史图表,让您一眼看出"这台 VPS 是什么时候开始变差的"。

Docker Compose 部署

/opt/smokeping/docker-compose.yml
# 文件路径:/opt/smokeping/docker-compose.yml
# Smokeping:长期监控延迟波动,生成历史图表

services:
  smokeping:
    image: lscr.io/linuxserver/smokeping:latest
    container_name: smokeping
    restart: unless-stopped
    ports:
      - "127.0.0.1:8088:80"         # 配合 Nginx 反代
    volumes:
      - ./config:/config             # 探测目标配置
      - ./data:/data                 # 历史 RRD 数据
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai

监控目标配置

/opt/smokeping/config/Targets
# 文件路径:/opt/smokeping/config/Targets
# 配置要监控的目标(默认已有示例,按格式添加即可)

*** Targets ***

probe = FPing

menu = Top
title = Network Latency Monitor
remark = 长期延迟监控,追踪网络质量波动

+ China
menu = 中国大陆
title = 国内延迟监控

++ ChinaTelecom
menu = 中国电信
title = 上海电信
host = 101.227.255.45

++ ChinaUnicom
menu = 中国联通
title = 北京联通
host = 202.106.0.20

++ ChinaMobile
menu = 中国移动
title = 广州移动
host = 211.136.192.6

+ Global
menu = 全球节点
title = 全球延迟监控

++ Google
menu = Google DNS
title = Google 8.8.8.8
host = 8.8.8.8

++ Cloudflare
menu = Cloudflare DNS
title = Cloudflare 1.1.1.1
host = 1.1.1.1

💡 使用建议: 部署后 24-48 小时才能看到有意义的图表。观察晚高峰(20:00-23:00)与凌晨(3:00-5:00)的延迟对比,差距超过 3 倍说明线路在高峰时段严重拥塞。建议同时监控国内三网(电信/联通/移动)和境外节点(Google/Cloudflare),帮助定位问题出在哪段路由上。

🤖 实战:网络质量自动巡检脚本

与第 20 篇服务器监控体系联动:每天定时运行 MTR + NextTrace,自动生成网络质量报告并通过 Telegram 发送,让您在不登录服务器的情况下也能掌握网络状况变化。

/root/net-check.sh
#!/bin/bash
# ════════════════════════════════════════════════════════════════════
#  VPS 网络质量自动巡检脚本
#  每天定时运行 MTR + NextTrace,生成报告并发送 Telegram 通知
# ════════════════════════════════════════════════════════════════════
set -euo pipefail

TG_TOKEN=""        # Telegram Bot Token(可选,留空只记录日志)
TG_CHAT_ID=""
REPORT_DIR="/var/log/network-check"
DATE=$(date +"%Y-%m-%d_%H-%M")
REPORT="${REPORT_DIR}/report_${DATE}.txt"

# 测试目标(可按需修改)
TARGETS=(
  "8.8.8.8:Google DNS"
  "101.227.255.45:上海电信"
  "202.106.0.20:北京联通"
  "211.136.192.6:广州移动"
  "1.1.1.1:Cloudflare"
)

mkdir -p "$REPORT_DIR"

echo "════════════════════════════════" >> "$REPORT"
echo "VPS 网络质量巡检报告" >> "$REPORT"
echo "时间:$(date '+%Y-%m-%d %H:%M:%S')" >> "$REPORT"
echo "主机:$(hostname)" >> "$REPORT"
echo "════════════════════════════════" >> "$REPORT"

for target_info in "${TARGETS[@]}"; do
  ip="${target_info%%:*}"
  name="${target_info##*:}"

  echo "" >> "$REPORT"
  echo "── $name ($ip) ──" >> "$REPORT"

  # Ping 测试(快速延迟 + 丢包)
  ping_result=$(ping -c 5 -W 3 "$ip" 2>/dev/null | tail -2)
  echo "Ping: $ping_result" >> "$REPORT"

  # MTR 报告
  if command -v mtr &>/dev/null; then
    mtr -r -c 5 --no-dns "$ip" 2>/dev/null | tail -10 >> "$REPORT"
  fi
done

# NextTrace 回程路由(如已安装)
if command -v nexttrace &>/dev/null; then
  echo "" >> "$REPORT"
  echo "── NextTrace 上海电信回程路由 ──" >> "$REPORT"
  nexttrace --no-rdns 101.227.255.45 2>/dev/null | head -20 >> "$REPORT"
fi

# 发送 Telegram 通知
SUMMARY=$(tail -30 "$REPORT" | head -20)
if [[ -n "$TG_TOKEN" && -n "$TG_CHAT_ID" ]]; then
  curl -s -X POST "https://api.telegram.org/bot${TG_TOKEN}/sendMessage"     -d "chat_id=${TG_CHAT_ID}"     -d "parse_mode=Markdown"     -d "text=📡 *网络巡检报告*%0A$(hostname)%0A$(date '+%Y-%m-%d %H:%M')%0A%0A${SUMMARY}"     > /dev/null 2>&1 || true
fi

# 清理 30 天前的旧报告
find "$REPORT_DIR" -name "*.txt" -mtime +30 -delete

echo "巡检完成:$REPORT"

# 部署(每天凌晨 6 点执行):
# chmod +x /root/net-check.sh
# crontab -e 添加:
# 0 6 * * * /root/net-check.sh

📖 如何解读结果

带宽

标准:实际速度达标 80% 以上即为优秀。

延迟

标准:美西 < 200ms;亚洲 < 100ms 为佳。

丢包

标准:理想应为 0%。持续丢包说明链路有问题。

IOPS

标准:4K 随机读写 IOPS 越高,数据库性能越好。

常见问题解答

BBR 已经开启了,但网速没有明显提升,是什么原因?

BBR 的收益主要体现在高延迟、高丢包的跨国链路场景,如果是以下情况提升不明显是正常的:① 本地测速(到国内 speedtest 节点):BBR 对短距离低延迟链路效果有限,它主要解决长距离传输的拥塞控制问题;② 带宽本身是瓶颈:如果服务器套餐带宽只有 20Mbps,BBR 无法突破硬件上限;③ OpenVZ 容器:BBR 需要修改内核模块,OpenVZ 共享内核架构下 sysctl 修改可能不生效,验证命令 sysctl net.ipv4.tcp_congestion_control 仍显示旧算法则说明未生效;④ 商家 QoS 限速:部分商家在网络层对 TCP 流量限速,BBR 无法绕过这层物理限制。真正感知 BBR 提升需要用 iPerf3 在实际跨国场景(如本地电脑到美国 VPS)测试吞吐量。

MTR 显示某个节点丢包 20%,是不是这台服务器有问题?

不一定。MTR 中间节点丢包是一个常见的误读陷阱:很多路由器对 ICMP 探测包(MTR 使用的协议)设置了低优先级或速率限制,导致探测包被丢弃,但实际 TCP/UDP 数据流量完全正常通过。判断规则:看最后一跳(终点)的丢包率才是最关键的指标。如果中间某跳丢包 30%,但终点是 0% 丢包,说明那个节点只是限制了 ICMP 回复,实际链路没问题。只有当最后一跳丢包且后续所有节点都丢包时,才说明该节点真的是瓶颈。建议同时用 ping -c 100 目标IP 做补充验证,对比丢包是否一致。

Speedtest 测出来 1Gbps,但我下载文件时只有几 MB/s,正常吗?

这是测速工具与实际体验差距最大的场景,原因有几个层次:① 测速节点 vs 下载源位置不同:Speedtest 会自动选择距离最近(延迟最低)的节点,速度自然最快;而下载文件可能来自遥远的服务器,路由和带宽完全不同;② 服务器端上行限速:很多文件分发服务(GitHub/Docker Hub/npm)对单个 IP 有速率限制;③ 单线程 vs 多线程:Speedtest 使用多线程并发测速,而普通下载通常是单连接,TCP 窗口扩展不充分导致速度受限——尝试用 wget -q -O /dev/null --report-speed=bits 下载链接 或开启多线程工具(aria2c)对比;④ 中间路由拥塞:Speedtest 节点通常是骨干网直连,而普通 CDN 或源站走的是公网路由,晚高峰拥塞明显。

NextTrace 显示走的是 163 骨干网(202.97),有办法改善吗?

163 是中国电信的普通骨干网,在晚高峰拥塞严重是公认问题。软件层面的改善空间有限,根本解决方案是:① 更换 VPS 商家:选购明确标注"CN2 GIA 回程"或"AS9929 直连"的线路,这是物理线路问题,BBR 等软件优化无法根本改变;② 接入 Cloudflare CDN:如果是网站,接入 Cloudflare 后用户访问的是 Cloudflare 距离最近的节点,只有回源请求才走到您的 VPS,大幅降低 163 的影响;③ 中转线路/IPLC:通过 IPLC(国际专线)中转节点绕过 163,适合有网络知识的进阶用户;④ 换机房位置:同一商家不同机房线路差异可能很大,香港、日本、新加坡机房对国内的延迟普遍优于美国机房。参见 VPS 术语表中的路由线路章节了解各线路详细对比。

修改 sysctl.conf 内核参数后出错,如何回滚?

sysctl 参数修改在不重启的情况下是临时的(写入 /etc/sysctl.conf 是持久化,但 sysctl -p 只应用当前会话)。回滚方法:① 临时回滚(不重启):针对具体参数直接覆盖,例如 sysctl net.ipv4.tcp_congestion_control=cubic 还原默认拥塞控制算法;② 持久回滚:编辑 /etc/sysctl.conf,删除或注释掉您添加的行,然后 sysctl -p 重新加载;③ 重启后自动恢复:如果只执行了 sysctl -w 参数=值(不修改文件),重启后自动恢复默认值;④ 完全重置sysctl --system 会重新加载所有配置文件,包括 /etc/sysctl.d/ 下的文件。最佳实践:修改前先备份 cp /etc/sysctl.conf /etc/sysctl.conf.bak,出问题直接 cp /etc/sysctl.conf.bak /etc/sysctl.conf && sysctl -p 还原。

XanMod 内核安装后系统无法启动,如何救援?

XanMod 安装后启动失败,标准救援流程:① 登录商家控制面板,进入 VNC/Console 带外控制台;② 在 GRUB 启动菜单(开机时按住 Shift 或 Esc 进入)选择"Advanced options",选择原版内核启动;③ 系统启动后,卸载 XanMod:apt remove linux-xanmod-x64v3 -y && apt autoremove -y;④ 更新 GRUB:update-grub,确保默认启动项是原版内核;⑤ 重启验证。预防建议:① XanMod 只支持 KVM 架构,OpenVZ 和 LXC 严禁安装;② 安装前确认 CPU 支持 x64v3 指令集(grep -o 'avx2\|bmi2\|popcnt' /proc/cpuinfo | head -3);③ 安装前创建一份 VPS 快照,出问题可以一键回滚。

iPerf3 服务端开放了但客户端连不上,是什么问题?

iPerf3 默认使用 5201 端口(TCP+UDP),连接失败按顺序检查:① 防火墙:最常见原因——ufw allow 5201/tcp && ufw allow 5201/udp,或临时关闭防火墙测试;② 服务端是否在监听ss -tlnp | grep 5201,如果没有输出说明 iperf3 -s 没有成功运行(可能已退出);③ 绑定 IP 问题:如果服务器有多个 IP,iperf3 默认监听所有接口,客户端确认连接的是正确的公网 IP;④ 测试端口:改用自定义端口 iperf3 -s -p 19999(客户端对应 -p 19999),排除 5201 端口被封的可能;⑤ 后台运行:使用 iperf3 -s -D 让服务端在后台持续运行,避免测试结束后进程退出。测试完成后记得关闭端口:ufw delete allow 5201/tcp

修改 gai.conf 强制 IPv4 后,某些服务反而变慢了,怎么办?

强制 IPv4 是"以防为主"的设置,对于 IPv6 路由优良的机器(如香港、日本部分 VPS)可能适得其反——某些服务(Google、Cloudflare 等)的 IPv6 路由比 IPv4 更优。恢复方法:编辑 /etc/gai.conf,找到 precedence ::ffff:0:0/96 100 这行,在行首加 # 注释掉,保存后立即生效(不需要重启)。更细粒度的方案:不全局强制 IPv4,而是针对具体慢的软件单独设置。例如只让 apt 走 IPv4:在 /etc/apt/apt.conf.d/99force-ipv4 中添加 Acquire::ForceIPv4 "true";;只让 curl 走 IPv4:使用 curl -4 参数。这样可以按需控制,不影响其他服务使用 IPv6。

YABS 一键脚本跑完后,怎么判断这台 VPS 值不值得继续用?

YABS 输出的核心看点:① fio 磁盘测试:4K 随机读 IOPS 低于 1000 说明是 HDD 或超卖严重的 SSD,对数据库性能影响极大,建议换机;② Geekbench 得分:单核分低于 500 说明 CPU 性能较弱,编译/动态网站等计算密集任务会很慢;③ 网络测速节点:重点看国内方向的下载速度,有节点超过 100Mbps 说明国际出口不差;④ 测速稳定性:多个节点速度方差很大(有的 1Gbps 有的 1Mbps)通常说明限速策略不均匀。综合评判:NodeBench.me 收录了大量 YABS 结果,可以横向对比同价位机器的测试数据,是购机决策的重要参考。

完成网络优化后,下一步应该做什么?

网络底层已经优化完毕,按 30 篇路径的自然延伸:① CDN 加速配置(第23篇):在网络优化的基础上叠加 Cloudflare CDN,将静态资源分发到全球边缘节点,同时隐藏真实 IP 防 DDoS——是面向国内用户的网站速度提升的最重要一步,参见CDN 加速配置;② 异地组网(第24篇):将多台 VPS 和本地设备用 Tailscale/ZeroTier 组成私有网络,实现内网直连、跨机房通信,是网络进阶玩家的必备技能,参见异地组网与虚拟局域网;③ 网络诊断自动化:将本篇的 MTR/NextTrace 测速命令写成定时脚本,配合第11篇的自动化脚本体系,定期生成网络质量报告。