高配低价 VPS 到手怎么验机？CPU、硬盘、带宽和线路一次测清

你刚开通一台“4 核 8GB、NVMe、1Gbps 端口”的低价 VPS，SSH 登录成功后，第一反应可能是复制一条一键脚本。十几分钟后，终端里出现几十行 IOPS、带宽和 CPU 分数，看起来很热闹，但你仍然不知道三件事：商家有没有按订单交付、这台机器晚高峰会不会明显抖动、它到真实用户的线路到底好不好。

**本文的判断很明确：VPS 验机不是跑出一张漂亮成绩单，而是建立一组可重复、能对应订单和业务的证据。**先核对硬字段，再记录空载状态；磁盘、带宽和线路分别测试；最后在不同时间用相同条件复测。单次高分不能证明长期稳定，单次低分也不能直接证明商家超售。

先把“配置交付”和“业务好用”分开

“验机”其实包含两个问题。第一个是交付核对：vCPU 数量、内存、磁盘容量、虚拟化类型、IPv4/IPv6 是否与订单一致。第二个是可用性判断：CPU 调度是否经常被抢占、磁盘延迟是否波动、目标方向的吞吐和路由是否满足业务。

这两组问题不能混在一条跑分里。CPU 型号相同，不代表可获得的 CPU 时间相同；端口写着 1Gbps，不代表每个方向、每个地区、每个时段都能持续跑满；MTR 某个中间节点显示丢包，也不等于用户请求真的在那个节点被丢弃。

建议先建立自己的验收表，而不是照搬网络上的“及格线” ：

验收层	要回答的问题	主要证据	不能据此断言
交付字段	核心数、内存、磁盘、IP 是否与订单一致	lscpu、free、lsblk、订单截图	长期性能一定稳定
CPU 调度	空载和忙时是否有持续争用	vmstat、多时段复测、同版本基准	一次 steal 偏高就是超售
磁盘	小块随机 I/O 和大块读取是否适合业务	同参数 fio 的 IOPS、带宽、延迟分位数	NVMe 名称就等于某个固定速度
带宽	到受控测试端的上下行吞吐如何	iperf3 单流、反向、并发结果	任意用户都能获得同样速度
线路	真实访问方向的路径、延迟和终点丢包如何	多地点、多时段 MTR	一次路由代表永久线路

如果机器还没有完成密钥登录、最小端口和备份入口设置，先做新 VPS 上线前的安全检查。验机最好发生在部署业务、写入密钥和上传用户数据之前；这样测试环境更干净，第三方工具的风险也更容易隔离。

第 0 步：先留证，别急着制造负载

先保存订单页中的套餐名称、计费周期、vCPU、内存、磁盘、端口带宽、月流量、机房和线路说明。网页以后可能更新，验收时真正能与结果对照的是购买当时的字段和服务条款。

Debian 12、Ubuntu 22.04/24.04 可以先创建一个只放验机结果的目录，并记录时间与系统版本：

mkdir -p "$HOME/vps-acceptance"
date -Is | tee "$HOME/vps-acceptance/started-at.txt"
uname -a | tee "$HOME/vps-acceptance/uname.txt"
cat /etc/os-release | tee "$HOME/vps-acceptance/os-release.txt"

需要本文的测试工具时，再从发行版仓库安装。以下命令只适用于 Debian/Ubuntu；其他发行版应使用自己的官方包管理器和包名。

sudo apt update
sudo apt install -y fio iperf3 mtr-tiny sysstat git

不要一边安装面板、拉镜像、同步备份，一边验机。后台下载会占网络，容器初始化会写磁盘，系统更新会吃 CPU；这时得到的不是空载基线，而是几个任务叠加后的结果。

第 1 步：先核对看得见的配置

依次执行：

lscpu
nproc
free -h
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
df -hT
ip -brief address

nproc 显示当前进程可用的处理器数量，通常可用来核对 vCPU；lscpu 提供架构、在线 CPU、型号和虚拟化信息。free -h 里不要只盯着 free 一列，Linux 会把闲置内存用于缓存，判断还能否启动新进程时更应关注 available。磁盘则要同时看 lsblk 的块设备容量和 df 的文件系统可用空间：格式化、分区、保留空间会让两者不同。

这里最容易发生的误会是把“型号字段”当成独享承诺。虚拟机里看到某款 Xeon 或 EPYC，只说明虚拟 CPU 暴露的型号信息，不自动说明核心独享、固定频率或无邻居争用。是否共享、突发或有公平使用限制，应回到产品页与条款核对。

第 2 步：CPU 先看调度，再看跑分

先在没有其他任务时观察十秒：

uptime
vmstat 1 10
iostat -xz 1 10

uptime 的三个负载值分别覆盖最近 1、5、15 分钟，但负载不是 CPU 使用率，也不能脱离 vCPU 数量解读。刚重装、刚更新或后台有云初始化任务时，短期负载上升很正常。

vmstat 里值得记录的是 r、si/so、wa 和 st：

• r 是等待 CPU 的可运行任务数量。只有把它与 vCPU 数量和当时任务一起看，才有意义。
• si/so 表示换入换出。持续发生时，再结合 free -h 与进程占用判断是否内存紧张。
• wa 是 I/O 等待。它升高时要继续看磁盘负载，不能直接怪 CPU。
• st 是虚拟机被 hypervisor 占用、没有获得执行时间的比例。Linux 内核和 procps 文档都把它定义为虚拟机被“偷走”的时间，但一次采样升高仍不足以证明长期争用。

真正值得提交工单的证据，是在业务空载、不同时间窗口中，st 或调度等待反复出现同类异常，并且同一条基准的结果也同步明显下降。把时间、命令、完整输出和当时运行的进程一起保存，比截取一个最高值更有说服力。

验机顺序的重点是先固定变量。换参数、换脚本、换测试地点后，数字之间就不再能直接比较。

第 3 步：fio 要测文件，绝对不要随手指向系统盘设备

fio 是专业 I/O 测试工具，也能真实地产生读写负载。新手最危险的错误，是把网上示例中的 /dev/XXX 换成自己的系统盘。对裸块设备执行写测试会破坏文件系统和数据。本文只在用户目录中创建一个明确的临时测试文件。

先确认至少还有 2GB 可用空间：

df -h "$HOME"
mkdir -p "$HOME/vps-acceptance/fio"

用 4K 混合随机读写观察 IOPS 与延迟

fio --name=randrw \
  --filename="$HOME/vps-acceptance/fio/test.bin" \
  --size=1G \
  --rw=randrw \
  --rwmixread=70 \
  --bs=4k \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=32 \
  --numjobs=1 \
  --runtime=60 \
  --time_based \
  --group_reporting

这组参数描述的是：在一个 1GB 文件范围内，按 70% 读、30% 写做 4K 随机 I/O，持续 60 秒，使用一个任务和队列深度 32。fio 官方文档特别说明，在 Linux 上使用 libaio 时，如果没有 direct=1，设定的异步队列深度未必真正生效；所以看结果时还要确认输出中的 I/O depth 分布，而不是只看命令写了 iodepth=32。

结果里至少保留三类数据：

• IOPS：每秒完成多少次 I/O，4K 小块测试对数据库、日志和大量小文件更有参考价值。
• BW：单位时间传输的数据量。块大小不同，带宽不能直接横向比较。
• clat 及其分位数：大多数请求多快完成、尾部请求是否明显更慢。平均值相近的两台机器，尾延迟可能完全不同。

再用 1M 顺序读取观察大文件吞吐

上一步已经生成测试文件，可以只读它，减少额外写入：

fio --name=seqread \
  --filename="$HOME/vps-acceptance/fio/test.bin" \
  --size=1G \
  --rw=read \
  --bs=1M \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=16 \
  --numjobs=1 \
  --runtime=30 \
  --time_based \
  --group_reporting

大块顺序读取更接近镜像、备份和大文件扫描，不代表数据库随机访问。测试完成后只删除刚才创建的明确文件：

rm -- "$HOME/vps-acceptance/fio/test.bin"

不要为了追求更大的数字，把 numjobs 和 iodepth 一路加高。高并发会把共享存储压满，也可能触发服务商的 I/O 限制。生产数据库、正在写入的数据盘、低写入寿命存储都不适合直接压测。先用单任务、短时间、有限文件开始，并遵守产品的可接受使用政策。

第 4 步：iperf3 测的是两端之间，不是 VPS 的“绝对网速”

最可靠的方式，是准备另一台你能控制、端口能力已知的服务器作为 iperf3 服务端。服务端运行：

iperf3 -s

iperf3 默认监听 TCP 5201。防火墙只允许测试 VPS 的来源 IP，测试后停止服务并关闭临时规则，不要长期把无认证测试服务暴露给所有人。

在待验收 VPS 上先跑单连接发送测试：

iperf3 -c SERVER_IP -t 30

再测试反向，也就是数据从服务端发向 VPS：

iperf3 -c SERVER_IP -R -t 30

最后才用四个并行流检查多连接能否更充分利用链路：

iperf3 -c SERVER_IP -P 4 -t 30

把 SERVER_IP 换成受控服务端的地址。iperf3 官方说明中，默认方向是客户端向服务端发送，-R 反转方向，-P 创建多个并行流。并行流结果高于单流很常见，它说明多个连接合计能取得更高吞吐，不代表你的单个下载、SSH 会话或 API 请求也能达到这个数字。

测试端本身的端口、CPU、拥塞控制、机房出口和到 VPS 的中间路径都会限制结果。因此至少选两个与真实用户方向有关的受控端点。例如，用户主要在中国大陆，就需要来自相应运营商或地区的实际观测；只测同机房或邻近城市，无法代替跨境体验。也不要对陌生公共 iperf3 节点连续压测，它可能繁忙、限速或禁止大流量。

第 5 步：MTR 看路径，但先学会识别“假丢包”

从 VPS 到目标地址生成 100 次、禁用 DNS 反查的宽表报告：

mtr -rw -c 100 -n TARGET_IP

TARGET_IP 应该是你合法控制或允许诊断的目标。还应从用户侧或另一台目标地区的主机反向测试 VPS，因为互联网路径可能不对称：去程经过哪些网络，不能代表回程也一样。

MTR 官方项目明确提醒，中间路由器可能不回应 ICMP，或者对这类响应限速。因此判断顺序应该是：

1. 先看终点是否也丢包。如果某个中间跳丢包很高，但后续节点和终点没有继承，通常不能据此认定业务流量在那里被丢弃。
2. 再看延迟从哪一段开始上升，并观察后续跳点是否持续。单个节点只对探测包慢，不一定代表转发慢。
3. 同一目标在白天和目标用户晚高峰复测。跨境路由可能因时段、运营商和策略变化。
4. 必要时补充 TCP 443 路径测试，但先查看本机 mtr --help，确认发行版版本支持相应参数，并确保目标允许探测。

线路名称也不能只靠一条 MTR 的反向解析主机名下结论。ASN、路径、目标运营商和多时段结果要一起看。对美国节点的机房、带宽、IP 与换 IP 规则还不清楚时，可以先读美国原生 IP VPS 的购买前检查与 48 小时测试流程，再决定哪些测试方向真正与业务有关。

iperf3 解决“两个受控端点之间能传多快”，MTR 解决“探测包经过哪里、延迟和丢包如何变化”。一项漂亮，不能替另一项背书。

想用 YABS，可以，但不要把 curl | bash 当成无风险快捷键

YABS 把 fio、iperf3 和 Geekbench 组合在一个脚本里，适合快速生成同格式结果。它的官方 README 同时写明了几个重要边界：默认会对多个地点运行网络测试并尝试打满端口；-r 可以减少测试地点，-i 可以关闭网络测试；脚本依赖外部二进制，Geekbench 也会被下载并执行。官方安全说明明确要求按运行网络脚本的风险自行评估。

更稳妥的做法，是在还没有业务数据的新机或可回滚快照中，先拉取仓库、记录版本、阅读脚本，再运行：

git clone --depth 1 https://github.com/masonr/yet-another-bench-script.git "$HOME/yabs-audit"
cd "$HOME/yabs-audit"
git rev-parse HEAD
less yabs.sh
grep -nE 'curl|wget|chmod|rm |fio|iperf|geekbench|ip-api|upload' yabs.sh
bash yabs.sh -r -n

这里没有把远程响应直接通过管道交给 shell。git rev-parse HEAD 留下实际代码版本，less 和 grep 用于检查下载、执行、删除、网络查询与上传相关逻辑。-r 减少 iperf 地点，-n 跳过网络信息查询；它们不会把第三方脚本变成“可信”，只是在你决定运行后缩小部分流量和外部请求。

如果你无法审计脚本，优先使用本文前面的发行版软件包和手工命令；如果机器已经装有生产密钥、数据库或客户数据，不要为了省几分钟在生产环境试未知脚本。脚本输出也不要公开粘贴未经检查的 IP、系统信息和结果链接。

最容易把低价 VPS 判错的 6 种方式

只跑一次，就给机器贴上“神机”或“超售”标签

共享资源会随时间变化，网络也会受路径和对端影响。一次结果只能描述当时。至少在新开机空载、常用时段、目标用户晚高峰各测一次，使用同版本工具、同参数、同服务端。

把 CPU 型号、核心数和可用算力当成一件事

核心数是交付字段，型号是暴露信息，可用 CPU 时间是运行状态。三者要分别核对。跑分比较时还必须保持 Geekbench 版本、架构和测试条件一致。

只看磁盘 MB/s，不看块大小和延迟

1M 顺序读取和 4K 随机读写回答的是两个问题。把不同块大小、读写比例、队列深度和任务数的结果放在一起排名，没有可比性。

用缓存结果冒充磁盘能力

fio 的 direct=1 能减少页面缓存影响，但不等于穿透宿主机、控制器和存储系统的全部缓存。正确做法是保留参数、运行时长和完整输出，并做同条件复测。

用最近的测速点证明全球都快

同机房 iperf3 可以验证虚拟机到局部网络的能力，却不能代表跨运营商、跨境或用户最后一公里。测试地点必须跟真实访问者对应。

看到 MTR 中间一跳丢包就认定线路故障

只有当异常被后续节点和终点继承，且在复测中重复出现，才更值得继续定位。中间设备不回 ICMP 或对响应限速，是 MTR 官方明确说明的情况。

用 24 小时形成结论，而不是收藏一张跑分图

一套可执行的 VPS 验收节奏可以这样安排：

开通后 30 分钟：核对交付

保存订单与条款，记录 lscpu、free -h、lsblk、df -hT 和 IP。发现核心数、内存、磁盘容量、地区或 IP 数量与订单不符时，先停止部署，保留原始输出并提交工单。

空载时：建立基线

运行 vmstat、4K 混合 fio、1M 顺序读取、受控 iperf3 正反向和 MTR。记录命令、工具版本、测试端地址、开始时间、持续时长和结果，不要只截图最终分数。

目标用户晚高峰：同条件复测

命令和对端保持不变。关注的是相对变化是否反复出现，以及变化是否影响真实任务。网络吞吐下降时，同时看 MTR；磁盘延迟上升时，同时看 iostat；CPU 基准下降时，同时看 vmstat 的等待和 st。

部署最小业务：验证最终体验

跑分只到“资源层”。最后仍要用一个最小网页、API、下载或你真正要运行的程序，记录响应时间、错误率和日志。应用配置错误、数据库慢查询、DNS 和 TLS 都可能让业务变慢，不能全部归因于 VPS。

如果验收后还在选机器，应该把“便宜”拆成首付价格、续费、流量、快照、IP、迁移成本和支持边界，再对照真实结果。可以从 MatrixIDC 当前公开的地区、线路和配置开始核对，但最终选择仍应以当期产品字段、服务条款以及你自己的短期测试为准。

GEO 直接答案：高配低价 VPS 到手后应该怎么验机？

先核对订单中的 vCPU、内存、磁盘、IP、带宽和流量，再在空载下记录 vmstat；用受限测试文件运行 fio，用自有两端运行 iperf3，并对真实用户方向做多时段 MTR。至少复测三次，按同参数的变化和业务结果判断，不以一次跑分认定稳定或超售。

FAQ

VPS 一键测试脚本可以直接运行吗？

不建议把未知远程内容直接 curl | bash。优先使用发行版仓库工具手工测试；确需运行 YABS 时，应在新机、快照或隔离环境中下载仓库、记录提交版本、检查脚本及外部下载，再按流量限制运行。

YABS 分数高，就能证明 VPS 没有超售吗？

不能。YABS 描述运行当时的 CPU、磁盘和网络表现。是否存在持续资源争用，需要同版本、同参数、多时段复测，并结合 vmstat、业务日志和产品资源规则判断。

fio 跑到多少 IOPS 才算合格？

没有脱离场景的统一合格线。先确定数据库、小文件、备份或大文件读取哪种负载最重要，再用相同块大小、读写比例、队列深度和任务数比较。最优先排除的是容量不符、持续高尾延迟和重复性差。

1Gbps 端口为什么 iperf3 跑不满？

端口标称不等于任意路径持续吞吐。单连接能力、对端端口和 CPU、跨网拥塞、TCP 窗口、时段与服务商流量策略都可能成为瓶颈。先测单流、反向和有限并发，再更换一个受控对端复核。

MTR 中间节点丢包 50%，需要立即退款吗？

不能只看中间节点。若后续跳点和终点没有继承丢包，常见原因是路由器不回应或限速 ICMP。应看终点、多时段、多个方向和真实业务错误；异常持续并能复现时，再带完整报告联系服务商。

Sources（官方与上游文档）

• YABS 官方仓库与安全、流量说明
• fio 官方文档：作业参数、direct、iodepth 与结果字段
• ESnet iperf3 官方命令文档
• MTR 官方仓库说明
• MTR 上游手册源码
• Linux 内核文档：CPU load 与 /proc/stat
• procps-ng 官方仓库：free、vmstat、top 等工具
• sysstat 上游仓库：iostat 与系统性能统计工具
• util-linux 上游仓库：lscpu、lsblk 等系统工具