工具教程

用 MTR、NextTrace 和 PingMesh 建立可复现的 VPS 测评流程

给出从测试窗口、节点选择、数据留档到结论分级的一套标准化流程。

2026/5/15 #Methodology#MTR#VPS

为什么要标准化

VPS 测评最容易出现的问题是：只用一个地区、一个时间点、一条命令，就得出过度确定的结论。论坛和社区里的争论很多都来自这个问题。有人在欧洲测日本 VPS 觉得很好，有人在中国移动晚高峰测同一台机器觉得很差，两者都可能是真的。

标准化不是为了让测试变复杂，而是为了让结论能复查。你应该能在一周后用同样方法复测，也能让其他读者知道你的结果适用于什么条件。

一套可复现流程至少包含：

  • 固定测试时间窗口：白天、晚高峰、深夜。
  • 多运营商来源：电信、联通、移动，必要时加入教育网和企业出口。
  • 多目标区域：大陆、日本、香港、新加坡、美国西海岸、欧洲。
  • 原始数据留档：命令、时间、节点、IP、系统版本、套餐信息。
  • 明确结论边界：适合什么，不适合什么。

测试前先记录环境

不要一上来就跑脚本。先把机器背景写清楚：

商家：
机房：
套餐：
CPU：
内存：
硬盘类型：
虚拟化：
测试 IP：
系统版本：
测试时间：

如果商家使用动态路由或多上游，最好记录当时的 ASN、RPKI 状态和主要上游。

基础命令组合

网络方向：

mtr -rwzc 100 1.1.1.1
mtr -rwzc 100 8.8.8.8
nexttrace 1.1.1.1
nexttrace 8.8.8.8
iperf3 -c <server> -P 4 -t 30

系统性能方向：

curl -sL yabs.sh | bash
fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --size=1G --numjobs=1 --runtime=60 --group_reporting

YABS 在国外 VPS 社区里很常见，优点是输出统一、方便横向比较。缺点是它不能代表所有业务负载，尤其不能说明数据库、长期 CPU sustain、邻居噪声和晚高峰网络。

MTR 怎么读

MTR 的核心不是看中间某一跳丢包，而是看最终目标是否丢包，以及丢包从哪一段开始持续出现。

常见误读：

  • 中间路由器 ICMP 限速，不代表真实丢包。
  • 某一跳显示 80% loss，但后续恢复正常，通常不是故障点。
  • 最后一跳丢包并伴随 RTT 抖动，才更值得关注。
  • 路由器隐藏或 MPLS 不显示，不代表没有经过那段网络。

所以结论里不要写“第 5 跳丢包严重”，而要写“从某运营商边界后到目标持续丢包，最终目标丢包 X%”。

NextTrace 怎么用

NextTrace 更适合看地理路径、ASN 和线路变化。它能帮助判断：

  • 是否绕路到美国或欧洲。
  • 是否进入商家宣传的线路。
  • 是否跨运营商绕行。
  • 是否出现异常 ASN 或 IXP。

但它同样不是绝对真相。ICMP、UDP、TCP traceroute 可能走不同路径，ECMP 也可能让多次结果不同。因此建议保存多次输出，并标注协议。

PingMesh 的意义

如果只从一个家庭宽带测 VPS，结论很窄。PingMesh 的价值是用多个节点同时观察同一目标。

可以选择：

  • 国内三网探针。
  • 海外云厂商节点。
  • 自己的几台长期 VPS。
  • Looking Glass。

最小化方案是保留三类节点：国内电信、国内联通、国内移动。对日本 VPS，再加一个日本本地节点和一个美国西海岸节点。

结论分级建议

不要用“神机”“垃圾”这样的绝对词。更好的方式是描述适用场景：

  • A：多运营商稳定，晚高峰仍可用，适合生产建站。
  • B：多数方向可用，某些运营商或时间段有短板。
  • C：适合低成本落地、测试、轻量代理，不适合关键业务。
  • D：存在持续丢包、严重绕路或性能不稳定。

同时写清楚证据：

联通晚高峰 MTR 最后一跳 0% loss，平均 RTT 42ms。
移动晚高峰 最后一跳 6% loss，抖动 80ms 以上。
YABS 单核 Geekbench 正常，但 fio 4k randwrite 明显偏低。

参考来源