VPSKnow

网络性能测试与优化指南

中高级
45分钟

网络优化先回答“慢在哪里”:客户端、DNS、路由、丢包、单流拥塞、套餐限速、CPU,还是应用本身。使用固定节点、时段、方向与并发数建立基线,每次只改一个变量并保留回退;跑分更高不等于真实用户体验更好。

📊 性能指标解读

在开始测试前,了解评估 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 | bash
curl -fL -o /tmp/ookla-repo.sh   https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh
less /tmp/ookla-repo.sh
sudo bash /tmp/ookla-repo.sh
apt install speedtest -y

# 固定测试节点、记录时间和服务器 ID,才便于前后对比
speedtest --servers
speedtest --server-id <ID> --format=json

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

2

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

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

# 服务端:只允许测试端 IP 访问 5201,并仅处理一次连接后退出
apt install iperf3 -y
iperf3 -s -1 --server-max-duration 30

# 客户端:先测单流上传/下载,再用 4 流判断并发差异
apt install iperf3 -y
iperf3 -c SERVER_A_IP -t 15
iperf3 -c SERVER_A_IP -t 15 -R
iperf3 -c SERVER_A_IP -t 15 -P 4

# 测试完成立即撤销临时防火墙规则;不要长期公开无认证测速服务

先测单流反映常见连接体验,再用少量并发判断是否受单流、CPU 或拥塞控制限制;-R 反转数据方向。高并发会占满链路并影响线上业务。

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

带宽大不代表速度快。 如果服务器在洛杉矶,但数据包绕道欧洲再回中国,延迟和稳定性通常都会受影响。回程路由是判断线路表现的重要证据之一,但仍要结合去程、协议、运营商、时段和真实业务请求复测。

🔍 丢包检测:MTR

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

# 安装 MTR
apt install mtr -y

# 使用业务目标并采集足够样本;分别测试 ICMP 与 TCP 业务端口
mtr -r -w -c 100 yourdomain.com
mtr --tcp --port 443 -r -w -c 100 yourdomain.com

路由可视化神器:NextTrace

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

# Debian/Ubuntu 优先使用 NextTrace 官方签名 APT 仓库
sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL -o /tmp/nexttrace.gpg   https://github.com/nxtrace/nexttrace-debs/releases/latest/download/nexttrace-archive-keyring.gpg
sudo install -m 0644 /tmp/nexttrace.gpg /etc/apt/keyrings/nexttrace.gpg
# 按官方文档添加带 Signed-By 的 nexttrace.sources 后安装
sudo apt update && sudo apt install nexttrace

# 对真实用户方向和业务协议测试,并保存结果
nexttrace --output-default your-user-side-target
💡 优质路由特征一览:
  • 59.43.x.x (中国电信 CN2 GIA):最顶级的越洋专线,晚高峰依然丝滑。
  • AS9929 (中国联通 A网):联通的 VIP 线路,对标 CN2,性价比极高。
  • AS58453 (中国移动 CMIN2):移动新一代精品网。
  • 注意:看到较多 202.97(163 骨干网)只能说明该次探测经过普通骨干路径;是否在晚高峰拥塞,应以固定端点、多时段 MTR 和真实业务请求复测。

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 是一种 TCP 拥塞控制算法,可能改善部分高延迟、有丢包链路的 TCP 吞吐与排队延迟,但不能增加套餐带宽、改变路由或修复上游拥塞。先记录当前算法、iperf3 吞吐、延迟和丢包,再决定是否启用并用相同条件复测。

开启系统原生 BBR

# 先记录当前值并确认内核提供 BBR
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
modinfo tcp_bbr

# 使用独立 drop-in,便于审阅和删除回退
sudo tee /etc/sysctl.d/90-vpsknow-bbr.conf >/dev/null <<'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sudo sysctl --system
sysctl net.ipv4.tcp_congestion_control net.core.default_qdisc

# 用相同节点、时段、方向和并发数复测;无收益就删除 drop-in 并 sysctl --system

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

提示:这是进阶操作。Linux 默认会自动调节 TCP 缓冲;盲目放大上限可能增加每连接内存和本机排队,反而抬高延迟。只有指标证明窗口或队列是瓶颈时才调整。

不要把通用“大数值模板”追加到主 sysctl.conf。先读取当前值和业务指标,确有瓶颈时写入独立 drop-in,一次只调整一个参数,并记录验收与删除回退方式。

# 先读取有效配置、Socket 统计和真实业务指标
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
sysctl net.core.rmem_max net.core.wmem_max
ss -s
nstat -az

# 只有证据显示窗口/队列是瓶颈时,才按带宽时延积和并发量计算目标值
# 每次只改一个参数,写入独立 /etc/sysctl.d/91-network-tuning.conf
# 先运行 sysctl -p <该文件> 验证语法,再以相同负载复测延迟、重传与吞吐
# 删除该文件并执行 sysctl --system 即可持久回退

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

很多现代 VPS 默认开启双栈(IPv4 + IPv6),应用会依据地址选择规则和自身的 Happy Eyeballs 实现选择连接。若某一地址族的 DNS、路由或握手异常,apt updatecurl 或 GitHub 连接可能出现等待;先分别测试 A / AAAA、curl -4curl -6,不要仅凭一次卡顿全局禁用 IPv6。

诊断方法:对同一目标分别测试 IPv4 与 IPv6。 只有问题能稳定复现时,才对受影响的软件做临时、可撤销的地址族限制。

# 先确认域名同时返回哪些地址
getent ahosts yourdomain.com

# 对同一 HTTPS 目标分别记录 IPv4 / IPv6 的连接与总耗时
curl -4 -sS -o /dev/null   -w 'IPv4 connect=%{time_connect} total=%{time_total}\n' https://yourdomain.com/
curl -6 -sS -o /dev/null   -w 'IPv6 connect=%{time_connect} total=%{time_total}\n' https://yourdomain.com/

# 再结合应用日志、MTR 和多时段复测确认问题,不直接改全局地址优先级

工具篇:第三方脚本与高风险实验

高风险实验:第三方内核与 BBRv3

只有在发行版内核、应用配置和链路瓶颈均已排查,并且具备快照、控制台和旧内核回退能力时,才考虑测试 XanMod 等第三方内核。BBRv3 是否更合适取决于内核版本、流量模型和链路条件,不能预设一定降低延迟或提高吞吐;生产机器不应仅为追求跑分直接更换内核。

# 安装任何第三方内核前先确认虚拟化、CPU 指令集、当前内核和启动项
systemd-detect-virt
lscpu
uname -a
grep menuentry /boot/grub/grub.cfg | head

# 先确认商家控制台可用、创建快照并保留发行版旧内核
# 只按 XanMod 当前官方签名仓库文档安装与核验,不复制长期静态安装命令
# 重启后验证应用、网络、磁盘驱动与回退启动项;没有量化收益就回到发行版内核

第三方评测脚本(先审阅再运行)

YABS (Yet Another Bench Script)

功能全面

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

curl -fL -o /tmp/yabs.sh https://yabs.sh less /tmp/yabs.sh bash /tmp/yabs.sh

Bench.sh

经典轻量

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

wget -O /tmp/bench.sh https://bench.sh less /tmp/bench.sh bash /tmp/bench.sh

📈 进阶: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

💡 使用建议: 至少覆盖多个业务高峰和低峰时段,再比较相同端点的趋势;不要把固定小时或单一倍数当作拥塞结论。建议同时记录国内不同运营商、境外节点和真实业务请求,并区分 ICMP 限速、路由变化与端到端错误。

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

与第 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),有办法改善吗?

202.97 表示该次探测经过中国电信普通骨干路径,本身不能证明持续拥塞。先用不同运营商、方向、协议和时段复测真实业务;若问题稳定复现,再考虑:① 更换线路或机房,并核实商家所称的回程范围与测试入口;② 网站接入 CDN,验证命中率、回源路径和受支持端口,CDN 不能改善 SSH 或任意 TCP / UDP;③ 合规中转,评估成本、容量、故障点和当地规则。BBR 能改善部分传输场景,但不能改变物理路由。参见 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 默认用 TCP 5201 建立控制连接,UDP 测试仍需要该 TCP 控制连接。先用 ss -tlnp | grep 5201 确认服务,再检查云防火墙和主机防火墙是否仅允许测试端 IP;不要关闭整个防火墙,也不要为了 TCP 测试额外开放 UDP。推荐 iperf3 -s -1 --server-max-duration 30 单次限时运行,必要时用 -B 绑定指定地址。测试结束后确认进程退出并撤销临时规则,不要把公开测速服务长期后台运行。

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

不应把强制 IPv4 当作默认设置;若 IPv6 路由正常,全局改变地址优先级可能降低可用性。先用 curl -4curl -6 和应用日志确认问题。若此前在 /etc/gai.conf 添加了 precedence ::ffff:0:0/96 100,可注释该行恢复;需要临时绕过时,优先使用软件级选项,例如 apt 的 Acquire::ForceIPv4 "true"; 或单次 curl -4,并在故障解除后撤销。

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

YABS 是一次性综合样本,不能用固定 IOPS、单核分或某个测速节点直接判定机器好坏。先记录测试版本、实例规格、节点、时间和并发负载,再结合真实应用的延迟、吞吐、错误率与成本比较;磁盘测试还可能影响同机业务并消耗写入额度。不同虚拟化、CPU 代际、文件系统和测速节点的结果不可直接混为一谈,第三方汇总只能作为线索,不能代替自己的重复测量。

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

完成基线测量和单变量验证后,可按需求继续:① CDN 加速配置(第23篇):为适合缓存的 Web 内容验证边缘命中、回源与安全边界,参见CDN 加速配置;② 异地组网(第24篇):将多台 VPS 和本地设备组成受控私有网络,参见异地组网与虚拟局域网;③ 网络诊断自动化:定期记录 MTR、NextTrace 与真实业务指标,并保留节点、方向、协议和时间等上下文。