VPS到手怎么验货：性能、线路与双源基线实测
买完 VPS 别急着搬家上生产。绝大多数问题——配置缩水、IO 拉胯、线路绕路、IP 被流媒体封——都能在退款期内测出来，拖过了就只能自己扛。这篇把 VPS 验货拆成能照着敲的顺序，并附一组真实双源实测数据，用来说明一个常被忽略的前提：同一个目标，从不同地区测出来的数字可以差一倍。
结论先行：三步验货法
| 阶段 | 花多久 | 测什么 | 能发现什么问题 |
|---|---|---|---|
| 快筛 | 5 分钟 | 硬件信息、IP 归属、一键脚本 | 配置与宣传不符、IP 段被滥用 |
| 细测 | 30 分钟 | UnixBench / sysbench、dd / fio | CPU 被超售、磁盘是 HDD 或严重超售 |
| 复测 | 分时段 | ping、speedtest、tracepath | 晚高峰掉速、出口绕路、丢包 |
顺序别颠倒。先快筛能立刻刷掉一批明显不合格的 VPS，省得你在上面白跑半小时基准测试。
第一步：确认这台 VPS 到底是什么配置
别急着部署，先看系统实际给了你什么：
| 命令 | 看什么 | 异常信号 |
|---|---|---|
cat /proc/cpuinfo | CPU 型号、主频、缓存 | 型号被隐藏成 "QEMU Virtual CPU" |
nproc | 可用核心数 | 与购买页面写的核数不一致 |
free -h | 内存总量与可用 | 总量明显少于标称（部分被 balloon 占用） |
df -h | 磁盘挂载与容量 | 实际容量小于标称，或根分区被拆得很小 |
uname -r | 内核版本 | 过于老旧，可能缺少新特性与安全补丁 |
有一个常见误区：VPS 的核心数只是标称，不等于性能。一颗独享高主频的核心，跑赢那些「2 核超售」的机器是常事。真正的判断依据是下面两步的跑分和负载表现。
第二步：CPU 与内存
UnixBench：给这台 VPS 一个综合分
UnixBench 覆盖整数、浮点、进程创建、文件操作等多项，最后给一个总分，方便横向比较。装和跑：
wget --no-check-certificate https://github.com/teddysun/across/raw/master/unixbench.sh
chmod +x unixbench.sh
./unixbench.sh脚本来自 teddysun 的 across 项目（github.com/teddysun/across），单核跑完通常要十几到四十分钟。跑的时候别同时做别的任务，否则分数会被自己拖低。
sysbench：只测单项，更可控
想单独压 CPU 或内存，sysbench 更灵活：
sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench memory --memory-block-size=1K --memory-total-size=100G run--threads 要显式写。不写的话它按 CPU 核数起线程，在超售的 VPS 上反而测不出单核真实水平。
同一台 VPS 不同时段跑分可能差不少，空闲时多跑几次取平均，别拿单次结果下结论。
第三步：磁盘 IO——很多卡顿的元凶
网站加载慢、数据库响应迟，往往不是 CPU 不够，而是磁盘读写拖后腿。
dd：三十秒看个大概
dd if=/dev/zero of=test bs=64k count=4k oflag=dsync
rm -f test这条会写 256MB 并同步落盘，跑完删掉测试文件。普通 SSD 写入 100MB/s 以上算正常，NVMe 通常 500MB/s 起步。低于 50MB/s 要警惕——可能是超售，也可能这台 VPS 根本不是 SSD。
fio：模拟真实负载
dd 只能看顺序写。要模拟数据库那种随机读写，用 fio：
fio --name=randrw --rw=randrw --bs=4k --size=1G --numjobs=4 \
--direct=1 --time_based --runtime=60 --group_reporting这三个参数容易被漏掉，但都会影响结果能不能用：
| 参数 | 作用 | 漏掉的后果 |
|---|---|---|
--direct=1 | 绕过系统缓存 | 测出来是内存速度，虚高好几倍 |
--time_based | 按时间跑而不是按数据量 | --runtime 直接失效，测不出持续性能 |
--group_reporting | 汇总多任务结果 | 4 个任务各出一份报告，没法看总吞吐 |
dd 和 fio 该信哪个
| 维度 | dd | fio |
|---|---|---|
| 测什么 | 顺序写、单线程 | 可自定义读写比例、块大小、并发 |
| 耗时 | 几十秒 | 1–5 分钟 |
| 适合 | 快速排除「明显不正常」 | 判断 VPS 能不能扛住数据库、虚拟化 |
| 局限 | 测不出随机 IO 与并发瓶颈 | 参数多，配错会得出误导性结论 |
第四步：带宽、延迟，以及一个被传错的前提
带宽先看上限，再看实际
pip install speedtest-cli
speedtest-cli测速节点要选对：选错节点，测出来的是节点到你这台 VPS 的速度，不是你到目标用户的速度。1Gbps 口跑到八九百 Mbps 属正常，但一定要在晚高峰再测一次。
ping 的基线目标别用 114.114.114.114
很多教程会让你 ping 114.114.114.114 当作基线。实测下来这个地址不回 ICMP——我们用两个国内探测源各发 20 包，两边都是 100% 丢包。拿它做基线，只会得到一个假的「线路不通」结论。
换成会回包的公共 DNS：
ping -c 20 223.5.5.5双源实测：同一条目标，换个地区就换个结论
2026-10-01，我们用两个真实探测源，对同一批公开目标各 ping 20 包：
- 源 1：广东电信 AS4816（
103.39.226.31） - 源 2：阿里云北京 AS37963（
8.140.30.240）
目标全部是公开、可复现的地址：两个国内公共 DNS，加上 Vultr 官方公开测试主机名（东京 / 首尔 / 洛杉矶）。
| 目标 | 归属 | 广东电信 avg | 丢包 | 北京阿里云 avg | 丢包 | 两源差 |
|---|---|---|---|---|---|---|
| 114DNS 公共解析 | 中国 | 未取得 | 100.0% | 未取得 | 100.0% | — |
| 阿里云公共 DNS | 中国 | 5.331 ms | 0.0% | 2.482 ms | 0.0% | 2.849 ms |
| Vultr 东京 | 日本东京 | 243.371 ms | 5.0% | 114.422 ms | 40.0% | 128.949 ms |
| Vultr 首尔 | 韩国首尔 | 163.11 ms | 30.0% | 189.314 ms | 10.0% | 26.204 ms |
| Vultr 洛杉矶 | 美国洛杉矶 | 258.378 ms | 15.0% | 157.214 ms | 5.0% | 101.164 ms |
114.114.114.114 两源 20 包全丢，未取得延迟，未做任何估算。
这张表最值得看的不是绝对值，是同一目标的地区差：国内唯一有回包的目标两源只差 2.849ms，而三个跨境目标分别差了 128.949 / 26.204 / 101.164ms。东京方向北京比广东快 128.949ms，首尔方向反过来广东比北京快 26.204ms，洛杉矶方向又是北京快 101.164ms——连「谁快」都不能一概而论。
流传的地区延迟区间，为什么经常不成立
网上常见一张参考表：日本/韩国 50–100ms、香港 30–50ms、美西 150–200ms。对照上面这组实测：
- 东京：广东 243.371ms、北京 114.422ms
- 首尔：广东 163.11ms、北京 189.314ms
- 洛杉矶：广东 258.378ms、北京 157.214ms
没有一条落在那张表的区间里。 这不是表格写错了，而是它漏了两个前提：
- 线路类型。那些区间默认的是 CN2 GIA、9929 这类优化直连线路；我们测的 Vultr 公开测试点是普通国际线路，走 Arelion（
62.115.x.x）骨干，延迟天然更高。 - 测量地区。同一个日本机房，从广东看和从北京看可以差出 128.949ms。
所以看到任何延迟数字，先问三件事：从哪儿测的、走什么线路、什么时候测的。三个前提缺一个，这个数字就没有参考价值。
别只测一次，晚高峰才是照妖镜
ping -c 100 223.5.5.5真正要看的是晚高峰（20:00–23:00）。不少廉价 VPS 白天一切正常，到了晚高峰延迟翻倍甚至开始丢包。经验判断：晚高峰延迟涨幅超过 30%，或丢包率高于 3%，这条线路就不适合对延迟敏感的业务。
第五步：路由——延迟高，到底是哪一段高
ping 只给你一个端到端数字。想知道数据包经过了谁、在哪一跳开始变慢、有没有绕路，得看路由。
apt install mtr -y
mtr -r -c 100 223.5.5.5如果 VPS 上没有 mtr 或装不了（部分精简系统如此），tracepath 是随时可用的替代：
tracepath -n -m 30 108.61.219.200这是广东电信源到 Vultr 洛杉矶的真实输出片段：
10: 202.97.91.213 7.718ms
11: 202.97.43.74 178.361ms
12: 218.30.54.182 155.599ms
13: 62.115.139.16 166.115ms asymm 15
...
18: 173.199.80.241 175.009ms第 10 跳到第 11 跳，延迟从 7.718ms 直接跳到 178.361ms——这就是典型的国际出口跳：数据包在国内段只花了不到 8ms，一到出口就付掉了全程的大部分延迟。第 11 跳 202.97.43.74 归属 AS4134（中国电信骨干），已经是电信的国际段设备。看路由时先找这种「一次性跃升」的跳，你就知道延迟是在境内产生的还是出境后产生的。
同一目标从北京源看，出口在第 10 跳：
9: 202.97.55.186 6.305ms
10: 202.97.41.50 171.879ms
11: 218.30.54.182 153.039ms asymm 13
12: 62.115.140.226 160.431ms asymm 15
...
17: 173.199.80.241 162.500ms asymm 18两条路由在出口后汇入了同一条国际路径：第 11/12 跳都是 218.30.54.182（AS4134 中国电信国际段），第 15 跳都是 62.115.149.37（AS1299 Arelion），最后都走到 173.199.80.241（AS20473 The Constant Company，即 Vultr 母公司）。也就是说，广东与北京的差异主要产生在国内段与出口选择上，出境之后走的是同一条路。
看路由时的三个要点：
- 找跃升点，判断延迟发生在境内还是境外；
- 看
asymm标记，它表示回程路径与去程不一致，不对称路径会让实际体验与去程数据对不上； - 跳的 RTT 不等于端到端延迟。上例里两条路由可见跳的 RTT 都在 150–180ms 区间，但端到端 ping 分别是 258.378ms 与 157.214ms，差出 101.164ms。中间不可见的跳、ICMP 回包限速、不对称路径都会造成这种偏差。路由用来看「经过了谁」，ping 用来看「有多快」，两者不能互相替代。
两个源的 tracepath 在第 18–30 跳与第 20–30 跳均为 no reply（Too many hops: pmtu 1500），这是目标侧不回 ICMP 的正常表现，不代表链路中断。
第六步：IP 质量与流媒体解锁
便宜的 VPS 经常整段换 IP，拿到被滥用或被封的 IP 并不罕见。装好系统后先跑一次解锁检测：
bash <(curl -sSL https://github.com/lmc999/RegionRestrictionCheck/raw/main/check.sh)脚本来自 lmc999/RegionRestrictionCheck（5,100+ star，社区里最常用的一个），能一次性列出 Netflix、Disney+、YouTube Premium、ChatGPT 等服务的可用状态。
如果结果里目标服务是「被封锁」，趁退款期还在，尽快联系商家换 IP 或申请退款。IP 被封通常不会自己恢复。
一键脚本：想省事就先跑个总览
不想逐个装工具，可以先跑一键脚本拿个整体印象，再决定要不要深入。
| 脚本 | 跑法 | 覆盖内容 | 来源 |
|---|---|---|---|
| bench.sh | curl -Lso- bench.sh | bash | 系统信息、磁盘 IO、下载测速 | bench.sh（Teddysun） |
| YABS | curl -sL yabs.sh | bash | CPU（Geekbench）、磁盘（fio）、iperf3 网络 | masonr/yet-another-bench-script |
| UnixBench 一键 | wget --no-check-certificate https://github.com/teddysun/across/raw/master/unixbench.sh && chmod +x unixbench.sh && ./unixbench.sh | 综合跑分 | teddysun/across |
YABS 跑得比 bench.sh 全面，代价是慢一些（Geekbench 与 iperf3 都要联网下载）。注意：一键脚本给的是「能不能用」的粗筛结论，配置是否缩水、随机 IO 是否达标，还是得回到前面几项逐项测。
参考标准：带前提才有意义
下面这些区间是经验值。其中跨境延迟那一行默认指优化直连线路（CN2 GIA / 9929 一类），换成普通国际线路直接作废——我们实测的 Vultr 洛杉矶从广东走 258.378ms，已经比「还行」的上限高出不少。
| 指标 | 还行 | 不错 | 拉胯 |
|---|---|---|---|
| UnixBench（1 核 1G） | 800–1500 | > 1500 | < 800 |
| 磁盘顺序写（SSD） | 100–300 MB/s | > 300 MB/s | < 100 MB/s |
| 磁盘顺序写（NVMe） | 500–800 MB/s | > 800 MB/s | < 500 MB/s |
| 到国内延迟（优化线路，美西） | 150–200 ms | < 150 ms | > 200 ms |
| 晚高峰丢包率 | < 3% | 0% | > 5% |
不同用途对这些指标的敏感度完全不同。用 VPS 跑数据库，优先看随机 IO 和 --direct=1 下的 fio 结果；做加速代理，优先看出口跃升点和晚高峰丢包；建站则 CPU 单核分数和磁盘写入更关键。
六个容易踩的坑
- 只跑一次 UnixBench 就下结论。邻居负载对分数影响很大，空闲时多跑几次取平均。
- 拿 dd 的结果判断「磁盘好不好」。dd 绕不过缓存，
oflag=dsync加了才接近真实，随机性能更是完全测不到。 - 用 114.114.114.114 当 ping 基线。实测两源 20 包全丢，它不回 ICMP，换了会回包的地址再测。
- 只在一个地区、一个时段测一次。上表里东京方向两源差了 128.949ms，只看一个数会得出完全相反的结论。
- 把路由跳的 RTT 当成端到端延迟。两者可以差出一百多毫秒，各看各的。
- 忽略 IP 质量。IP 被流媒体封是退款期内最容易解决、过期后最麻烦的问题。
快速检查清单
| 顺序 | 动作 | 判断依据 |
|---|---|---|
| 1 | 核对 VPS 的 CPU / 内存 / 磁盘容量 | 与购买页面是否一致 |
| 2 | 查 IP 归属与 ASN | 是否与商家宣称的机房一致 |
| 3 | 跑 UnixBench 或 sysbench | 对照参考区间 |
| 4 | 跑 dd 快速看写入 | 低于 50 MB/s 立即警惕 |
| 5 | 跑 fio（带 --direct=1 --time_based） | 随机 IO 能否支撑你的用途 |
| 6 | speedtest 测带宽 | 白天与晚高峰各一次 |
| 7 | ping 会回包的公共 DNS | 建立本机基线 |
| 8 | tracepath 看出口跃升点 | 延迟产生在境内还是境外 |
| 9 | 跑解锁检测脚本 | 目标服务是否可用 |
| 10 | 截图保存全部结果 | 出问题时用于举证与维权 |
最后一步最容易被省掉，但恰恰最重要：结果截图是你和商家沟通时唯一的证据。发现问题就在退款期内提，别拖。
常见问题
Q：一键脚本和逐项测试，选哪个？
先跑一键脚本做粗筛，通过之后再逐项测。一键脚本能快速排除明显不合格的 VPS，但它给不了随机 IO、晚高峰表现这类结论。
Q：UnixBench 跑多久算正常？
1 核 VPS 通常十几到四十分钟。跑的时候别做其他任务，跑分会被自己拖低。
Q：为什么我 ping 某些地址一直是 100% 丢包？
目标不回 ICMP。实测中 114.114.114.114 在两个国内探测源上都是 20 包全丢，这属于目标策略，不代表你的 VPS 线路有问题。换 223.5.5.5 这类会回包的地址再测。
Q：ping 延迟正常，但实际访问很慢，为什么？
延迟只反映往返时间。可能是带宽被打满、磁盘 IO 瓶颈，或晚高峰线路拥塞。按「带宽 → 磁盘 → 分时段复测」的顺序排查。
Q：同一个机房，为什么别人测出来比我快很多？
测量地区、线路类型、时段三个变量都可能不同。我们的实测里，同一个 Vultr 东京目标从广东走 243.371ms、从北京走 114.422ms，差 128.949ms。先对齐这三个前提再比较。
Q：商家宣传的「优化线路」怎么验证？
看 tracepath 的出口跃升点与骨干 ASN。走 CN2 GIA、9929 这类优化线路的 VPS，出口跳之后的延迟通常明显低于普通国际线路。
延伸阅读
- 想直接看具体机房的实测数据，可以翻本站的 VPS 测评汇总；
- 下单前想先对比各家优惠与在售套餐，看可核实的优惠码清单；
- 还在挑商家，主机商汇总按机房与线路做了分类；
- 看别人的测评时，注意区分「官网标称」和「真机实测」，这篇RackNerd 洛杉矶 DC03 实测是按本文方法写的完整示例；
- 需要具体机房的公开测试地址，JustVPS 测试 IP 汇总和V.PS 测速文件可以直接拿来当 ping 目标。
