VPS 测试方法：性能、网络、路由与 IP 质量完整流程

VPS 测试方法的重点不是一次跑完多少脚本，而是把测试对象、时间、环境和限制记录清楚，再用可以复现的数据回答“这台机器适合什么”。同一套餐可能因宿主机、IP 段、测试节点和时段不同而出现明显差异，因此单次结果只能代表当时样本，不能替代长期稳定性观察。

本文给出一套适用于 VPS 测评和到货验机的固定流程。建议先完成低负载检查，再做磁盘、CPU 和网络压测；生产服务器应在备份和业务低峰期测试。

测试前先记录环境

缺少环境信息的跑分很难比较。每次测试至少记录以下内容：

• 测试时间、时区和持续时间；涉及中国大陆网络时，注明是否为晚高峰。
• 套餐名称、机房城市、虚拟化类型、CPU 核数、内存、磁盘和端口标称值。
• 操作系统、内核版本、拥塞控制算法，以及 IPv4、IPv6 是否可用。
• 测试脚本名称、版本或提交号，保留完整原始输出，不只截取最好看的几行。
• 测试端来源、目标节点和运营商。测速节点拥堵时应标记失败，不能把失败值当作线路上限。

可以先用系统自带命令建立环境快照：

date --iso-8601=seconds
uname -a
cat /etc/os-release
lscpu
free -h
lsblk
ip -brief address
sysctl net.ipv4.tcp_congestion_control

公开结果前应遮盖公网 IP、主机名、订单号和面板信息。测试日志中如果包含授权令牌或专用下载地址，不要直接上传。

建议的测试顺序

1. 核对资源是否与订单一致

先确认 CPU、内存、磁盘容量、虚拟化和网络协议栈。这里要回答的是“资源有没有交付正确”，不是“CPU 型号看起来是否高端”。共享 VPS 上显示的处理器型号不能证明整台物理机资源都由当前实例独享。

如果发现内存、磁盘或 IP 数量与订单不符，先保存证据并联系商家，不要继续高负载跑分掩盖交付问题。

2. 测试 CPU 与内存

CPU 跑分用于同架构、相近版本和相近负载条件下比较。至少重复两次，并观察两次结果差异。突发型实例、宿主机争用、温控和频率限制都可能影响结果。

内存很小的 VPS 运行综合跑分时可能失败。失败本身不等于 CPU 性能差，应记录脚本的内存要求、Swap 状态和失败原因，不能补造一个分数。

3. 测试磁盘

顺序吞吐量、随机 IOPS 和延迟回答的问题不同。建站与数据库更关注小块随机读写和延迟，大文件分发才更接近顺序吞吐场景。

磁盘压测会产生大量写入，可能影响同宿主机用户，也会消耗 SSD 写入寿命。不要在有重要数据、空间不足或高峰期的生产实例上直接运行重负载测试。测试前后都要记录剩余空间和系统负载。

4. 测试带宽、延迟和抖动

端口标称带宽不是任意目标都能跑满的保证。至少选择本地附近、业务目标地区和跨洲三个方向，分别记录上传、下载、延迟、抖动与丢包。

ping -c 20 1.1.1.1
mtr -rwzc 50 1.1.1.1

单个 Speedtest 或 iperf3 节点可能过载。出现异常值时应更换同地区节点复测；连续测试也可能触发流量限制。结果应注明测试线程数，不能把多线程峰值描述成单连接体验。

5. 检查去程与回程路由

去程是访问者到 VPS，回程是 VPS 返回访问者。两者可能不同，只测 VPS 发出的回程不能证明用户侧去程同样优化。

路由判断应保留完整跳点、ASN、超时位置和测试目标。中间节点不响应 ICMP 并不必然代表丢包，只有终点或后续节点持续丢包时才有诊断价值。线路名称也应以实际 ASN 和路径为证据，不能只照抄套餐宣传。

NextTrace 仍在维护，安装方式和参数应以其官方项目说明为准。优先使用项目维护的包仓库或发行文件，并在安装前核对来源。

6. 检查 IP 质量和区域识别

IP 数据库、流媒体平台、邮件服务和风控平台的判断彼此独立。一次“解锁”结果只说明测试时该平台和该 IP 的状态，换 IP、换账号、换协议或平台更新规则后都可能变化。

测试时应分别记录 IPv4 与 IPv6、数据库识别地区、常用服务结果和测试日期。不要把第三方风险分数直接写成“原生 IP”或“永久可用”，也不要公开完整 IP。

7. 观察稳定性后再下结论

到货当天的峰值不能代表长期体验。至少在非高峰和晚高峰各复测一次；重要业务还应连续观察 CPU steal、磁盘延迟、丢包、重启和故障记录。

最终结论建议按以下格式写：

• 适合什么：用原始数据说明适用场景。
• 不适合什么：写明内存、磁盘、路由、流量或条款限制。
• 证据边界：注明单台样本、测试日期和未验证项目。
• 复测条件：套餐迁移、IP 更换、线路调整或超过复核日期后重新测试。

综合脚本应该怎样使用

YABS 官方项目覆盖 fio、iperf3 和 Geekbench，适合快速建立可比较的性能基线。其网络测试会主动占用带宽，低流量套餐应减少节点或跳过网络项。项目也明确提示会下载并执行外部二进制，使用者需要自行承担风险。

不要为了省一步而盲目执行来源不明的 curl | bash。更稳妥的做法是先下载、查看来源和内容，再执行；对长期留存的报告，还应记录文件哈希和脚本版本。

curl -fsSL https://yabs.sh -o yabs.sh
less yabs.sh
sha256sum yabs.sh
bash yabs.sh -r

-r 会减少 iperf3 测试节点，适合先做低流量基线。是否执行完整网络测试、fio 或 Geekbench，应根据套餐流量和业务风险决定。本文不再推荐多年未维护、来源不清或只能通过短链接获取的旧脚本；历史输出可以保留，但不能继续当作当前安装指南。

如何阅读一份测评

读 VPS 测评时，先看测试时间和环境，再看原始输出，最后才看作者结论。以下是站内采用同一方法整理的样本：

• HostHatch 首尔 2GB 测评：硬件、国际带宽和中国大陆方向路由表现并不一致。
• VMRack L3 1C2G 测评：用于理解 CN2、AS9929、CMI 等回程标记与测试边界。
• BestVM 日本 BGP-Lite 测评：低内存导致部分跑分失败时，应怎样保留失败证据。
• RFCHOST 香港 512MB 测评：小内存套餐需要区分资源限制与线路表现。
• Cloudnium 洛杉矶简评：简评升级时应补齐方法、测试时间和结论。
• YXVM 东京测评：同一地区也要根据实际 ASN、路由和测试时段判断。

这些页面均保留各自测试时间。跨文章比较时，应先统一脚本版本、目标节点和指标口径；无法统一时，只能作为个案参考。

一份合格报告的最小清单

发布前可以按下面的清单复核：

• 测试时间、时区、套餐和系统环境完整。
• 原始输出保留，公网 IP 和敏感字段已遮盖。
• CPU、磁盘、网络、路由和 IP 结论没有互相替代。
• 至少说明一次失败、限制或未测试项目。
• 价格、库存和线路宣传与实测数据分开呈现。
• 结论限定在当前样本，没有把单次跑分外推成长期保证。
• 已设定复核日期，并在 IP、线路或宿主机变化后重新测试。

按这个流程得到的报告可能没有“跑分大全”看起来热闹，但更容易复现，也更能帮助读者判断一台 VPS 是否适合自己的真实用途。