VPS下单后第一小时：该测什么怎么测

导读：很多人在VPS开通后只登录一次面板就放一边，等站点访问异常才发现机器根本不对。真正该做的是下单后第一小时跑完一套验收：确认硬件系统是否符合标注、实测网络延迟丢包与回程质量、跑磁盘IO与CPU基准、核对IP归属与信誉、提交工单验证售后响应。下面给出每项的测试命令、判读标准和不达标时的处置动作。

VPS下单后第一小时做的事，决定了这台机器是能用还是白买。绝大多数人的流程是：收到邮件、登录面板、装个宝塔、把域名绑上去、然后开始想别的。问题在于，这套流程里没有任何一步是在验证商家兑现了他承诺的东西。机器可能是超售的共享CPU，IP可能是上一任用户污染过的，端口可能标称十兆实际走的是绕地球的路由。等到发现这些问题时，退款窗口通常已经关了。

所以第一小时应该有明确的验收清单，顺序也很讲究：先测最可能致命的东西（IP 可达性、线路质量），再测性能（CPU、磁盘、带宽），最后测商务项（工单响应、续费规则）。如果第一步就发现 IP 在大陆不可达，后面所有性能测试都可以直接跳过，因为机器再好也用不了。

一、开机后第一时间：确认硬件与系统是否符合标注

第一件事是把机器的「实际底数」摸清楚。这一步看起来平淡，但它能挡掉相当一部分纠纷——标称 SSD 实际是机械盘、标称 2 GB 内存实际只有 768 MB、CPU 型号和商家页面写的不一样，这些情况都真实发生过。测完发现不对，正好在退款窗口内。

延伸对照：cloudcone 的公开机型与线路说明，可结合本节的判断标准自行核对。

下面这组命令一次就能把硬件、系统和网络状态全查一遍，建议在机器上跑完并把输出留档：

# 系统版本与内核
cat /etc/os-release | head -4
uname -r

# CPU 型号、核数、是否支持虚拟化
lscpu | grep -E 'Model name|CPU\(s\)|Thread|Core|Hypervisor|Virtualization'

# 内存：标称值与真实可用值
free -m
grep -E 'MemTotal|MemAvailable|SwapTotal' /proc/meminfo

# 磁盘：设备类型、挂载点、容量
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,ROTA,MODEL
df -hT

# 网卡、路由与默认网关
ip -br a
ip route

判读方式有四个要点。第一，lsblk 输出里的 ROTA 列如果显示 1，说明是机械盘——商家宣称 SSD 时这个列应当是 0；如果显示的是 MODEL 为型号字符串，大概率是虚拟盘，性能要靠后面的 fio 测试确认。第二，free -m 里的 total 减去 available 通常在 130 到 180 MB 之间（随发行版和已装服务浮动），所以 1 GB 机器装完系统后的实际可用内存大约在 830 到 900 MB 之间，这是估算值。如果 total 明显小于标称，比如 2048 MB 的套餐只有 1024 MB，直接找商家。第三，lscpu 里的 Model name 如果是 KVM 或者 QEMU 之类的通用型号，说明底层是虚拟化层，看不出宿主 CPU 型号，这种情况属于正常，不必追究。第四，Hypervisor 一行如果是 kvm，说明是真虚拟化，性能损耗小；如果是 xen 或者 lxc，性能表现会有差别。

内存、磁盘和网络的标称值对得上，只能说明「没有偷工减料」，不能说明「性能达标」。性能必须单独测。

这一阶段还要做一件容易被跳过的事：建立一份基线记录。这台机器刚到手时的所有数字，就是你日后判断「它是不是变慢了」的参照物。没有基线，三个月后你只会凭感觉说「好像变慢了」，而感觉在商家面前毫无说服力。

# 生成一份基线快照，包含硬件、网络、磁盘三项的关键指标
{
  echo "### 基线快照 $(date '+%F %T')"
  echo "--- CPU ---"; lscpu | grep -E 'Model name|CPU\(s\)'
  echo "--- 内存 ---"; free -m | head -2
  echo "--- 磁盘 ---"; lsblk -o NAME,SIZE,ROTA,MODEL | head -8
  echo "--- 网络 ---"; curl -s ifconfig.me; curl -s ipinfo.io/json
} | tee ~/vps-baseline.txt

判读方式：把这份文本存进你的笔记或工单附件里，标注日期。以后每次性能投诉都带上「这是购买当天的基线，这是现在的实测」，商家无法用「你刚买时就是这样」来搪塞。需要注意的一点是，磁盘型号那一行如果显示的是虚拟盘（MODEL 列为空或显示虚拟设备名），不必纠结型号本身，关键是把 fio 的实测延迟记下来作为数值基线。

顺便说一句硬件核对里最容易被忽略的一项：磁盘容量。标称 40 GB 的硬盘，lsblk 显示的 Size 常常只有 38 GiB 或者更小，这是十进制和二进制单位换算造成的，不是虚标。真正需要警惕的是挂载点不对——有些商家给的系统盘和标注的套餐盘不是同一个，或者数据盘没有正确挂载到预期路径，导致你以为有 40 GB 可用，实际可用空间被系统占满。这类问题的表现是装到一半就报「空间不足」。

二、网络测试：延迟、丢包、路由路径三件事分开测

网络是 VPS 体验的真正瓶颈所在，也是商家页面最不会写清楚的部分。同一个机房、同一个套餐，晚上八点和下午三点的表现可能天差地别，所以测网络必须固定时段，并且要在晚高峰重复测。

延伸对照：digitalocean 的公开机型与线路说明，可结合本节的判断标准自行核对。

先测基础连通性和延迟，用 ping 观察丢包和抖动：

# 连续 ping 100 个包，重点看最后一行：丢包率与平均延迟
ping -c 100 -i 0.2 你的服务器IP

# 看网络接口的 MTU、错包与丢包统计
ip -s link show eth0

判读方式：丢包率必须是 0。抖动看的是延迟的离散度，如果每个包的延迟在 5 毫秒和 80 毫秒之间反复横跳，即使平均延迟看起来还行，体验也会很差，因为 TCP 的拥塞窗口会因为抖动频繁收缩。稳定性的一个粗略判断是看标准差，如果标准差超过平均延迟的三分之一，基本可以判定这条线路晚高峰不稳定。

再看路由路径和真实丢包。这里有一个新手几乎都会踩的坑：mtr 输出里某跳显示 20% 丢包、后面几跳又变成 0% 丢包，很多人会以为线路坏了。实际上那是中间路由器对 ICMP 限速，不是真的丢包。真正的丢包表现为连续两跳或更多跳同时丢包。

# 从本地发起，观察去程路径经过哪些骨干网
traceroute -T -p 443 你的服务器IP

# mtr 连续采样 100 个包，这是判断丢包与抖动的主力工具
mtr --tcp --port 443 -c 100 -r 你的服务器IP

# 登上服务器反向测回程，这是很多商家说明里不会提的一环
mtr -c 100 -r 你的公网IP

判读方式：去程和回程都要测。业内的说法是「去程决定能不能访问，回程决定访问快不快」，因为绝大多数站点是服务器主动把内容推给你，回程拥塞直接影响下载速度。更反直觉的是，回程往往更难优化——反向路径由对端网络决定，商家在前面不一定有话语权。如果去程 30 毫秒但回程 200 毫秒，浏览体验会明显偏向「打开慢、内容加载慢」。

测试时段要固定在晚高峰 20:00 到 23:00，连续测三天，三天都不出现连续两跳丢包才算这条线路可用。白天测出来的一路绿灯没有参考价值。

三、IO与CPU跑分：判断超售和虚标

配置标注只能证明标称值存在，证明不了实际性能。这一节测三样东西：磁盘 IO 性能、CPU 实际算力、以及最容易被忽视的 CPU 超售情况。

延伸对照：hostwinds 的公开机型与线路说明，可结合本节的判断标准自行核对。

磁盘 IO 用 fio 测，这是行业里最常用的工具。测试要在空闲时做，先卸载缓存影响，并且避免用可能损坏数据的参数：

# 安装 fio
apt update && apt install -y fio

# 顺序写测试（100MB 测试文件，只写不读，安全）
fio --name=seqwrite --filename=/tmp/test.fio --size=100M --bs=1M --rw=write --direct=1 --iodepth=1 --runtime=10 --group_reporting

# 随机 4K 读写，这项最能反映数据库类负载的实际表现
fio --name=randrw --filename=/tmp/test.fio --size=100M --bs=4k --rw=randrw --rwmixread=70 --direct=1 --iodepth=16 --runtime=15 --group_reporting

# 清理测试文件
rm -f /tmp/test.fio

判读方式：先看 bw（带宽，IOPS 和带宽二选一看），再等几十秒看 lat (usec) 这一列。按 Little's Law 估算，队列深度 16 时，1.0 毫秒的延迟对应约 16000 IOPS，而 4.0 毫秒的延迟只有约 4000 IOPS——延迟差 4 倍，有效吞吐差也是 4 倍。所以判断磁盘好坏不要只看带宽数字，延迟那一列更重要。用 4k 随机读写的延迟如果超过 5 毫秒，这个盘对数据库来说就是偏慢。

CPU 跑分可以用 sysbench 或简单的哈希压测，但更关键的是测「有没有被超售」。超售的本质是多个租户共享同一个物理核池，高峰期你的算力被别人抢走。

# sysbench 单线程与多线程 CPU 测试
apt install -y sysbench
sysbench cpu --cpu-max-time=20 --threads=1 run
sysbench cpu --cpu-max-time=20 --threads=4 run

# 采样 10 秒，重点看 st（steal）列，这是判断超售的关键
vmstat 1 10

# 长期采样 steal 时间，统计整晚的 P95
nohup vmstat 1 > /tmp/vmstat.log 2>&1 &

判读方式：steal 时间（st 列）持续为 0 是好的。如果 st 长期在 1 以上，说明有超过 1% 的 CPU 时间被 hypervisor 拿走；5 以上就是明显的超售。要得到可靠结论，别只跑一次，要在晚高峰连续采样一整晚，然后统计 st 的 P95：

# 从一整晚的采样里统计 steal 的 P95
awk '$13=="st"{print $13}' /tmp/vmstat.log | tr -d ' ' | sort -n | awk '{a[NR]=$1} END {print "样本数:", NR, " st P95:", a[int(NR*0.95)], " st 最大:", a[NR]}'

还有一个 CPU 型号的核对方法，对比商家标注的型号和实际暴露给虚拟机的型号：

# 查看更详细的 CPU 型号与 flags
lscpu | grep -E 'Model name|Flags' | head -2
grep -m1 'model name' /proc/cpuinfo

CPU 跑分的结果要和标称核数做交叉验证。2 核的机器在单线程测试里应该接近一颗现代桌面级核心的水平，如果明显偏慢，往往说明 CPU 频率被限制或者宿主机本身用了老旧的型号。核对方法是把实测的 BogoMIPS 或者 sysbench 分数和同型号机器做对比，或者直接看 /proc/cpuinfo 里暴露的 MHz 是否和标注一致。

# 看 CPU 的实时频率与最大频率，判断是否被降频限制
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 2>/dev/null
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 2>/dev/null
grep -m1 'cpu MHz' /proc/cpuinfo

判读方式：虚拟化环境里读不到 cpufreq 是正常的，这时候退回看 cpu MHz。更重要的是看 freq 目录下有没有 cpuinfo_max_freq 与 scaling_governor 两个文件，它们能告诉你这台机器用的是哪种频率调节策略——如果是 powersave 策略且性能明显偏低，这属于可以向商家确认的配置差异。

内存带宽和 CPU 缓存也是容易出问题的环节。内存标称的频率在虚拟化环境里往往读不出来，但可以用 memtester 做一轮快速校验，确认没有硬件错误：

# 测 512MB 内存，读写两遍，检测硬件错误
apt install -y memtester
memtester 512M 2

判读方式：输出如果是 ERROR 或者地址出现不一致，说明内存条本身有问题，这是可以直接要求更换的硬件故障。全部显示 ok 说明硬件层面没问题。注意 memtester 会占用较多内存，1 GB 机器上跑 512M 已经是上限，在 1 GB 机器上建议改用 256M。

四、带宽与流量实测：别把端口速率当可用带宽

带宽是商家最爱标的一项，也是最容易虚标的一项。端口速率是网卡的物理上限，而你实际能用到的速度取决于线路质量、协议开销和对端能力。实测带宽必须用 iperf3 做端到端测试，不能用测速网站（测速网站测的是你家宽带到某处的速度，和 VPS 无关）。

延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。

做 iperf3 测试需要两台机器：被测的 VPS 和你自己的电脑（或者另一台已知线路不错的服务器）。步骤是两边都装 iperf3，一台开服务端，另一台连过去。

# 在 VPS 上启动服务端，监听 5201 端口
iperf3 -s -p 5201

# 在你自己的电脑上连过去，测 3 条并行流（更接近真实的多连接场景）
iperf3 -c 服务器IP -p 5201 -P 3 -t 30

# 反向测一次，验证回程吞吐（-R 表示接收方向）
iperf3 -c 服务器IP -p 5201 -P 3 -t 30 -R

# 同时测延迟与抖动，UDP 模式
iperf3 -c 服务器IP -u -b 0 -t 30

判读方式：先看 Retr（TCP 重传次数），这个数字如果占传输包总数的 1% 以上，说明线路有明显丢包，此时带宽数字再好看也不可信，因为 TCP 在反复重传。-P 3 的多条并行流总带宽应该接近端口标称值的三分之一到一半（考虑到国际线路的实际损耗），如果只有标称值的十分之一，那基本可以判定带宽被限制或线路严重拥塞。

再算一个关键指标：端口标称速率能撑多久才能跑完月流量配额。500 Mbps 端口按 720 小时每月折算，理论月上限约 147 TB；100 Mbps 端口约 29.5 TB；10 Mbps 端口约 3 TB。而常见套餐的配额只有 1 TB 到 6 TB，所以端口根本不是瓶颈，配额才是。

# 用配额和端口算出跑满端口所需的小时数，判断该买哪一档
python3 - <<'PY'
for name, mbps, quota_tb in [("500Mbps/1TB", 500, 1), ("500Mbps/6TB", 500, 6),
                              ("100Mbps/500GB", 100, 0.5), ("10Mbps/1TB", 10, 1)]:
    hours = quota_tb * 1024 * 1024 / 8 / mbps / 60
    cap_gb = mbps * 125000 * 720 * 3600 / (1024**3)
    print(f"{name:16s} 端口月上限 {cap_gb:9,.0f} GB | 跑满端口仅需 {hours:6.1f} 小时")
PY

这个输出里，10 Mbps 配 1 TB 流量的套餐跑满端口只要 134 小时；500 Mbps 配 1 TB 的只要 4.9 小时。前者端口小得几乎没用，后者端口大得用不上——真正限制你的是配额。

五、IP查询与信誉检查：这一项决定能不能上线

IP 往往是一台 VPS 里最难更换的部分，也是「买来就不能用」的首要原因。新分配的 IP 之前可能已经被前一个用户用来做过某些事，导致它在特定网络里不可达、或者被主流平台标记为机房 IP 而限制功能。这一节要在收到机器后立刻做，因为被墙的 IP 通常换不回来。

延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。

先查 IP 的基础属性和归属：

# 本机实际使用的出口 IP
curl -s ifconfig.me; echo

# 查询归属地、ASN、类型
curl -s ipinfo.io/json
curl -s "http://ip-api.com/json/?fields=query,country,regionName,city,isp,org,as,proxy,hosting"

# 查询该 IP 段是否被列入各大封禁名单
curl -s "https://api.ipify.org"

判读方式：关注三个字段。proxy 和 hosting 如果为 true，说明这是一个被公开标记的机房 IP 或代理 IP，意味着它被主流平台的识别概率很高——用这类 IP 注册海外服务账号、跑支付网关、跑社交账号，验证码和风控概率会明显上升。as 字段如果显示的是某个小众或数据中心 ASN，说明不是本土运营商线路。country 和 city 是物理机房位置，注意它和你的实际访问体验无关，只决定合规定位。

再做可达性测试。ping 通不代表能用，必须测 TCP 连接和实际 HTTP 请求：

# TCP 端口连通性测试，超时 3 秒
nc -z -w 3 你的服务器IP 22 && echo "SSH 端口可达"

# 实际 HTTP 请求测试，看返回的 Server 头和响应时间
curl -s -o /dev/null -w "DNS: %{time_namelookup}s  连接: %{time_connect}s  首字节: %{time_starttransfer}s  总计: %{time_total}s\n" http://你的服务器IP/

# 用在线工具从多个网络验证可达性
# 建议同时用国内几个不同运营商的探测点和至少两个境外探测点

判读方式：如果本地 ping 通但多个运营商探测点显示不可达，这就是典型的 IP 被墙。这类问题的处理窗口非常短，通常在 24 小时之内就要求商家更换 IP 段。判断的依据不是「我这边能 ping」，而是「多网络探测结果一致」。

还要确认一个容易忽略的事：IP 是否被商家标注为「可更换」。在下单前就问清楚换 IP 的政策和费用，以及换不到怎么办。这一条问清楚比事后扯皮有效得多。

IP 信誉还有一个容易漏测的维度：反向 DNS 记录是否被设置。大量 VPS 默认没有 PTR 记录，这本身不算故障，但有些服务（邮件、部分平台的 API 回调）会因为缺失 PTR 而拒绝连接。如果你的机器需要发邮件或者承接第三方回调，开机后第一件事就该把 PTR 和对应的正反向解析配好：

# 查看当前的反向解析
dig -x $(curl -s ifconfig.me) +short

# 在提供商控制台把 PTR 指向你的主机名后，在本地正向验证
dig +short mail.你的域名
host -t mx 你的域名

判读方式：PTR 为空时，先确认你的主机名在提供商侧是否真的被登记了——多数提供商的 PTTL 生效需要几分钟到几十分钟，配置后立刻查不到不代表失败，等待十分钟再验一次。如果超过一小时仍然为空，就该开工单了。

另外有一个测试值得做但很少有人做：拿这个 IP 去查各大封禁名单。判断依据是「多名单一致命中」而不是「单个名单命中」——单个名单可能过时或有误判，多个独立名单同时命中同一个 IP 段，那基本可以确定这个段是有问题的。

# 逐个检查常见名单，注意返回码与内容
for list in fspamlist sorbs spamhaus; do
  echo "--- $list ---"
  host -t A $(curl -s ifconfig.me).$list 2>&1 | head -3
done

判读方式：127.0.0.2、127.0.0.3 之类的回环地址表示命中。命中后不要急着申请退款——先确认这个 IP 是不是只是「曾经被标记过」的旧记录，判断依据是看返回的具体地址后缀，不同后缀对应不同的名单类型和严重程度。这项检查的实际价值在于：它能在你部署业务之前就告诉你这个 IP 有黑历史，从而避免账号被封、支付被拒这类麻烦。

六、工单验证：花五分钟测一次商家的售后

工单测试是验收里成本最低、价值最高的一项。很多人从来不提工单，直到出故障才第一次联系客服，于是永远不知道对方响应速度如何、答复是否专业。主动提交一条包含真实技术细节的工单，能在买之前就测出售后水平。

延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。

测试工单不要问「你们服务器什么时候好」这种模糊问题，要问一个有技术含量、能看出对方专业度的问题。比如：询问某项套餐的 CPU 是否为独享、流量超额的降速阈值具体是多少、分配的 IP 段是否支持更换及费用。好的商家会给出明确答复，差的商家会发一段模板。

提工单的同时，在本机做一次端口与服务确认，让工单内容有据可查：

# 确认监听中的端口与对应服务
ss -tulnp | head -20

# 确认系统已更新且无残留的默认账号
sudo apt update && sudo apt list --upgradable 2>/dev/null | head -10
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd

判读方式：记录工单的首次响应时间和最终解决时间两个数字。首次响应超过两小时且答复里没有任何针对性内容的商家，之后遇到真问题时基本可以预期同样的响应水平。反过来，如果工单在半小时内回复且给出了具体数字（比如「超额后限速到 5 Mbps」「CPU 为共享，宿主机 16 核超售比 1:3」），那说明这家商家的运营至少是专业的。

顺便说一句，工单里还有一个必问项：这家商家的退款政策和试用窗口具体是什么。如果连这个都要绕三个弯才回答清楚，那真出事时你的处境只会更糟。

七、综合测试脚本：把上面所有项目串成一条命令

手动跑六七个测试很繁琐，也容易漏。这里给一个整合脚本，一次性把所有检查跑完并生成报告，直接复制到机器上执行即可。

延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。

#!/bin/bash
# VPS 验收测试脚本 v1.0
echo "===== VPS 验收报告 $(date '+%F %T') ====="

echo; echo "--- 1. 系统与硬件 ---"
cat /etc/os-release | grep PRETTY_NAME
lscpu | grep -E 'Model name|CPU\(s\)' | head -2
free -m | head -2
df -hT / | tail -1

echo; echo "--- 2. 磁盘 IO（4k 随机）---"
command -v fio >/dev/null || apt install -y fio >/dev/null 2>&1
fio --name=t --filename=/tmp/vt.fio --size=50M --bs=4k --rw=randrw --direct=1 --iodepth=16 --runtime=8 --group_reporting 2>/dev/null | grep -E 'IOPS|lat.*usec|BW' | head -6
rm -f /tmp/vt.fio

echo; echo "--- 3. CPU 与超售采样 ---"
vmstat 1 5 | tail -2

echo; echo "--- 4. 网络连通 ---"
ping -c 20 -i 0.2 $(curl -s ifconfig.me) 2>/dev/null | tail -2
curl -s -o /dev/null -w "本地回环 HTTP 响应: %{time_total}s\n" http://127.0.0.1/

echo; echo "--- 5. IP 归属 ---"
curl -s "http://ip-api.com/json/?fields=query,country,city,isp,as,proxy,hosting"

echo; echo "--- 6. 监听端口 ---"
ss -tulnp | head -10

echo; echo "--- 7. 磁盘剩余与 inode ---"
df -h / | tail -1
df -i / | tail -1
echo; echo "===== 报告结束 ====="

判读方式：脚本的输出不要只看有没有报错，要横向对照四个数——内存 total 是否等于标称值、vmstat 的 st 是否长期非零、fio 的延迟列是否在 5 毫秒以内、df -i 的 inode 使用率是否远低于磁盘使用率。inode 用满是一个隐蔽的坑：磁盘还剩很多空间，但创建新文件全部失败，典型症状是日志写不进去、数据库无法建表。

跑完记得把输出保存成文件，作为将来申请退款或工单申诉的证据：

# 把整份报告存档，并带上时间戳
bash vps-test.sh 2>&1 | tee "vps-report-$(date +%Y%m%d-%H%M).txt"

八、不达标怎么办：三条处置路径

测出问题不要立刻吵，先分类。不同的问题对应完全不同的处置路径，处理错了会白白损失退款窗口。

延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。

第一类是明确不符型：标称 2 GB 实际只有 1 GB、标称 SSD 实测是机械盘、分配的 IP 在多个运营商探测下不可达。这类问题的证据是客观的（命令输出 + 时间戳），直接提交工单要求更换或退款，同时附上完整测试记录。商家如果推诿，用你付款时使用的支付方式的争议功能处理。

第二类是性能不足型：磁盘延迟过高、CPU 超售严重、带宽只有标称的十分之一。这类问题的处理方式是先判断是「机器本身不行」还是「线路不行」。机器不行要求降级或退款；线路不行往往可以申请换一台同套餐的机器或换个 IP 段，因为不同机器的宿主机和不同 IP 段的网络质量可能差别很大。

第三类是主观不满型：延迟比你预期高、配置比你期望小但并没有违规。这类问题通常无法退款，因为商家确实兑现了标注。处置方式是把实测数据作为下次选型的输入，避免重复消费。

有一个关键的时间管理原则：所有问题都要在退款窗口内提出。窗口可能是 24 到 72 小时，也可能只有几小时。所以策略应该是「并行推进」——一边提工单一边测试，不要等工单回复了再测，那样窗口早就过了。

# 记录各次测试的时间戳，作为时间线证据
echo "[$(date '+%F %T')] 测试开始，目标 IP: $(curl -s ifconfig.me)" >> /tmp/vps-timeline.log
echo "[$(date '+%F %T')] 工单号: XXXXX，已附 fio/mtr 输出" >> /tmp/vps-timeline.log

另外有几个动作在发现问题的第一时间就该做，可以最大限度保护自己：立刻停止往这台机器上部署业务；做一份数据快照（虽然大概率是空的）；截图保存所有测试界面的原始输出，不要只保存自己整理过的结论。

九、验收通过之后：第一周该做什么

第一小时的验收通过，只能说明这台机器符合标注，不说明它适合你的业务。真正的确认需要跑一整周的业务负载。这周里重点盯三个指标：内存水位、晚高峰延迟、以及实际月流量消耗速率。

延伸对照：zenlayer 的公开机型与线路说明，可结合本节的判断标准自行核对。

内存水位的监控用一条简单而有效的规则：每天固定时间（比如凌晨四点）记录一次 available 内存，画出趋势线而不是只看单点。

# 每天记录一次内存与负载快照
cat > /tmp/memcheck.sh <<'EOF'
#!/bin/bash
echo "$(date '+%F %T') avail=$(free -m | awk '/Mem:/{print $7}')MB load=$(cat /proc/loadavg | cut -d' ' -f1) disk=$(df -h / | tail -1 | awk '{print $5}')"
EOF
chmod +x /tmp/memcheck.sh
echo "0 4 * * * /tmp/memcheck.sh >> /var/log/memtrend.log" | sudo tee -a /etc/cron.d/memcheck

判读方式：如果 available 内存每天下降超过 50 MB，说明存在内存泄漏，这个趋势比任何一次快照都有说服力。日志文件本身也会增长，记得配 logrotate，否则监控日志把磁盘写满是常见的翻车方式。

流量消耗速率要换算成「还能撑多久」。用 vnstat 记录日流量，然后和商家的配额对比：

# 安装并初始化 vnstat
apt install -y vnstat && vnstat --add eth0 && vnstat --set sw 0

# 查看每日流量
vnstat -i eth0 --days

# 按当前速率估算还能用多少天
vnstat -i eth0 --oneline b

判读方式：如果第一周的日流量是 30 GB，那么 1 TB 配额的机器能撑 34 天左右，这个数字明显偏紧，说明要么换更高配额的套餐，要么把静态资源挪到对象存储加上 CDN，把图片和视频从 VPS 上卸走。

晚高峰延迟要连续记录三天，用同样的时段、同样的探测点，这样三天之间的差值才有意义。把每小时的 mtr 结果存下来做趋势：

# 每天 20:00–23:00 每小时采一次 mtr 存档
cat > /tmp/peaktest.sh <<'EOF'
#!/bin/bash
for h in 20 21 22 23; do
  mtr --tcp --port 443 -c 60 -r 目标IP > /var/log/mtr-$(date +%F)-$h.txt
done
EOF
chmod +x /tmp/peaktest.sh

十、常见问题

VPS测试需要准备什么工具？ 一台本地电脑加这台 VPS 就够了。软件层面需要 fio 测磁盘、mtr 和 traceroute 测网络、iperf3 测带宽、vmstat 测 CPU 超售、vnstat 统计流量，这五个工具在主流 Linux 发行版上都能一条命令装完。做带宽实测需要第二台机器做 iperf3 服务端，没有的话可以先用免费公共 iperf3 服务器测一个粗略值。

ping 通就说明机器没问题吗？ 远远不是。ping 只验证了 ICMP 可达和基础延迟，它不检查 TCP 端口是否开放、不检查丢包在真实连接下的表现、不检查磁盘和 CPU、也不验证 IP 是否被列入封禁名单。完整的验收至少要覆盖硬件核对、网络路径、性能跑分、IP 信誉和工单响应五个部分。

测试发现性能不达标，商家一般会怎么处理？ 分三种情况：客观不符的通常会换机或降级退款；线路质量问题的通常会换个 IP 段或换一台机器，因为不同宿主机和 IP 段的网络质量差异可能很大；主观不满的（延迟比预期高但没违规）一般不给处理。处理速度取决于工单响应能力和你的证据是否充分，所以测试记录留档很重要。

多少分算测试通过？ 硬性指标：内存总量与标称一致、磁盘延迟 4k 随机读写在 5 毫秒以内、晚高峰连续两跳丢包为 0、IP 在多网络探测下可达且未被列入主流封禁名单、CPU steal 时间 P95 低于 1。软性指标：iperf3 多流总吞吐达到端口标称的三分之一以上、首次工单响应在两小时内、商家明确回答了流量超额规则。

测试数据会不会把机器跑挂？ 正常使用不会。fio 建议用 50 到 100 MB 的小文件并加上 --direct=1 绕过缓存，iperf3 测 30 秒就够，vmstat 是纯采样没有任何压力。真正要避免的是在生产机器上跑 fio 的默认参数（可能覆盖整个磁盘），以及用 --rw=randrw 测一个很大的文件——那会真的写入大量数据，占用你的流量配额。

晚高峰具体指哪个时间段？ 国内方向一般指 20:00 到 23:00，国际方向还要加上当地的工作日白天时段。这两个窗口各有各的问题：晚高峰是国内用户集中上网导致的出口拥塞，工作日白天是跨境链路的国际出口拥塞。如果你的业务主要在白天被访问，那就不能只测晚高峰，要按你自己用户的活跃时段来测。

如果错过了退款窗口才发现问题怎么办？ 还是要提工单，多数商家在超出窗口后仍然会处理明显的硬件不符或 IP 不可用问题，只是处理难度会显著上升。如果商家以「超出试用期」为由拒绝，而你的证据是明确的硬伤（内存对不上、IP 在多网络不可达），可以升级到支付平台发起争议，信用卡和 PayPal 都有相应的买家保护条款，前提是你保留了完整记录。

测试完是否需要重装系统？ 需要跑过 fio 之类写入测试的机器，建议重装一次系统以获得干净的磁盘状态。如果只是做了网络测试和配置核对，没有大量写入，可以不重装。另外重装系统之前一定要确认 SSH 密钥已经配置好，否则重装后可能登不进去。

多台机器要不要用同一套测试脚本？ 强烈建议做。同一套脚本、同一时段、同一批探测点，才能横向比较不同机器的差异。不同机器分别用不同工具测出来的数据是不可比的，因为工具版本、测试时段、参数设置的任何一项不同都会让结论失真。把脚本和参数固定下来存成版本管理的文件，是做长期对比最省事的办法。