香港VPS性能实测方法

一、为什么必须自己实测：商家指标和真实体感是两回事

香港VPS性能实测之所以不可省略，核心原因是商家公布的每一个数字都缺少上下文。端口写着 1 Gbps，是网卡的理论上限，不是任何时刻都能达到的可用带宽；写着延迟 30 毫秒，是机房内部的空载 ping 值，不是晚高峰从你家路由器发出的完整路径耗时；写着独享带宽，是这条线路的资源池划分方式，不代表相邻机房的互联不受影响。

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

真正决定体验的是四个变量同时作用的结果：你所在网络到机房的物理路径、机房出口在那个时段的拥塞程度、你这台机器当时占用的资源、以及测速方法本身是否严谨。任何一环失真，结论就会偏离。

还有一层新手几乎不会注意：性能实测的价值不在于得一个分数，而在于建立你这台机器的基线。有了基线，以后出现「网站突然变慢」的时候，你能立刻判断是机器性能退化了还是外部线路波动了。这个判断能力，比实测当下的那个数字本身更有价值。

实测还要注意一个前提：所有测试都要在业务部署之前做，或者在业务低峰时段做。带着满负载的机器去测带宽，测出来的数字没有任何参考价值。

二、网络质量怎么测：延迟与丢包的测法和判读

延迟是新手最熟悉的指标，但也是最容易被误读的指标。三种测法测的是三件不同的事，必须分开看。

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

ping 测的是 ICMP 往返时延，它反映的是网络层的基础连通质量。mtr 在 ping 的基础上增加了每一跳的丢包统计和路径追踪，是判断路由走向的核心工具。而 curl 测出的 connect 和 total 时间是应用层的真实体验，包含了 TCP 握手、TLS 协商和首个字节返回。

它们的数值关系通常是这样的：ping 延迟最低，TCP connect 时间略高于 ping（因为要完成三次握手），TLS 首次握手再叠加一到两个往返（典型 50 到 150 毫秒），完整的 HTTPS 请求总耗时通常是 connect 时间的 1.5 到 3 倍。这个倍数关系在不同链路上差异很大。

# 1) 基础延迟与丢包：看 min/avg/max/mdev，mdev 就是抖动
ping -c 100 你的服务器IP
# 判读：avg 决定体感到延迟，mdev 决定稳不稳。mdev 大于 20 ms 说明抖动明显

# 2) 分时段采样，区分平峰和高峰
# 在 03:00 跑一次、在 20:30 再跑一次，两次结果做差
ping -c 200 -i 0.2 你的服务器IP

# 3) 真实 HTTPS 请求耗时：分阶段输出
curl -o /dev/null -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n" https://你的域名

第三条命令的判读方式。dns 应该在几十毫秒以内，如果超过 200 毫秒说明域名解析慢，可以考虑换解析线路。connect 减去 dns 大致是 TCP 握手时间，在 100 毫秒以内算正常。tls 减去 connect 是 TLS 握手，正常在 50 到 200 毫秒，如果超过 500 毫秒要检查服务器端的加密套件配置。ttfb 是服务端开始响应的时间，这个数最能反映服务器本身的处理能力。

需要特别提醒的是，mtr 输出里某一跳显示 100% 丢包不一定是真丢包。大量运营商路由器默认降低了 ICMP 响应率，中间节点显示星号属于正常现象。判断标准是看最后一跳以及后续跳是否有丢包，如果终点丢包为零，整条路径就是通的。

丢包率是比延迟更值得关注的指标。一个平均延迟 50 毫秒但完全无丢包的链路，体验上远好于平均延迟 30 毫秒却在高峰期丢百分之五的链路。

丢包的来源通常有三类。第一类是链路拥塞，出现在晚高峰，是最常见的类型，表现为延迟和丢包同时上升。第二类是跨境出口的策略性丢弃，在特定方向上稳定出现。第三类是商家侧的限速或 QoS 策略触发，表现为流量超过某个阈值之后突然出现规律性丢包。

判断丢包类型的方法是看时间分布。晚高峰集中在 20:00 到 22:00 出现的是拥塞型；全天任何时段稳定出现的是策略型；只在单次大流量传输中出现的是限速型。第三种最容易被误判成「商家超售」，实际上可能只是套餐的 QoS 策略。

# 1) 用 mtr 做多跳丢包统计，最后一跳的丢包才是真实丢包
mtr -r -c 200 --report 你的服务器IP

# 2) 长时间丢包监测，记录每一秒的丢包
# 运行 300 秒，然后看每个时间点的丢包分布
ping -c 300 -i 1 -D 你的服务器IP > /tmp/loss.txt
awk -F'/' '/packet loss/{print $3}' /tmp/loss.txt

# 3) 用 TCP 方式测试丢包，避免 ICMP 被限速误判
tcping -t 300 你的服务器IP 443
# 判读：tcping 的丢包才是真实业务丢包，ping 的丢包可能只是 ICMP 被降级

第三条命令值得专门强调。大量商家和运营商会对 ICMP 做速率限制，你用 ping 测出百分之三的丢包，用 tcping 测却是零，这种情况下链路是好的，只是 ping 被限速了。反过来，如果 tcping 也丢，那才是真的有问题。所以丢包测试至少要用两种方式交叉验证。

判读阈值方面，平峰时段丢包高于百分之零点五就应该警惕，高峰时段丢包高于百分之二说明这条链路不适合交互型业务，更适合下载分发或者加 CDN 缓冲。

三、带宽怎么测：用 iperf 而不是下载大文件

带宽测试最容易被做出误导性结论，因为用浏览器下载一个文件测出来的数字和这条线路的实际能力关系不大。这里推荐用 iperf3 做点对点测试，方法是把测试文件放在你自己的另一台机器上，两端互拉。

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

iperf3 的关键参数是 -P，它代表并发流数。并发流数不同，测出的结果能差好几倍，原因在于单条 TCP 流受拥塞窗口限制，而多流可以撑满链路。所以要测三组：单流、4 流、16 流，三组结果放在一起才能判断这条链路是「单流慢」还是「总带宽小」。

# 1) 在你自己的机器上起服务端
iperf3 -s -p 5201

# 2) 在香港 VPS 上拉，单流
iperf3 -c 你的本地IP -p 5201 -t 30 -P 1
# 判读：看 sum 那一行的 Mbits/sec

# 3) 多流测试，看总吞吐上限
iperf3 -c 你的本地IP -p 5201 -t 30 -P 16

# 4) 反向测试：VPS 主动往外拉
iperf3 -c 你的本地IP -p 5201 -t 30 -P 8 -R
# 判读：反向速率明显低于正向，说明是回程拥塞，不是正向问题

第四步的反向测试是香港 VPS 的必测项。国内用户访问香港服务器，流量路径是「你到香港」和「香港到你」两段，商家宣传的优化线路通常只优化其中一段（一般是回程）。如果正向快、反向慢，说明优化的是回程，对普通网站访问有利但对需要大量上传的业务不利。

如果不方便搭建第二台机器，可以用向公共测速服务器拉取的方式做粗略判断，但要注意这种方式测的是「到某个特定节点的速率」，不等于「到你实际用户的速率」。

带宽测试里最容易被忽略的一个变量是并发流数与实际业务形态的匹配。网页浏览是小流量、短连接、少量并发；视频播放是单条大流量长连接；下载分发是几十条并发长连接；备份同步则是持续高负载满速传输。同一条 100 Mbps 的线路，在这四种业务形态下的实际表现完全不同，所以只测一种形态得出的结论没有普遍意义。判断端口够不够用的正确问法是「我的业务形态下并发有多少、每条连接持续多久、单条需要多少带宽」，而不是「端口标了多少」。

还有一个实用技巧是先测理论上限，再测实际吞吐。如果 iperf3 测出的数值远低于端口标称，那说明限制来自线路或出口配额，这是买的时候就该知道的硬约束；如果 iperf3 接近标称但你的业务实际跑不上去，那问题在应用层，属于多路复用、连接池或者应用自身并发设置不足，可以通过调参解决。这两种情况的处置方式完全不同，先分清楚再动手能省下大量时间。

带宽测试还有两个必须标注的口径问题。一是测试时长要够，至少三十秒，因为短时测试会被 TCP 慢启动和突发缓存干扰，看起来虚高。二是测试方向必须写清楚，从大陆拉和从香港拉是两个数字。

四、CPU 和内存实测：别只看配置表

配置表上的核数和内存只是起点，真正要测的是「在共享环境下你能实际分到多少」。

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

CPU 实测要看两件事：单核跑分和持续负载下的稳定性。跑分可以用 sysbench 或 stress-ng 这类工具，但更重要的是压测时看有没有出现偷时间的情况——即系统空闲时任务被挂起、调度延迟突然升高。

# 1) 基础信息：看模型名、主频、是否 hypervisor 虚拟化
lscpu | grep -E "Model name|CPU\(s\)|MHz|Hypervisor"
# 判读：Model name 里的型号越新越好，但同型号在不同商家手里性能可能差 30%

# 2) 快速跑分（单线程与多线程）
sysbench cpu --cpu-max-prime=20000 --threads=2 run

# 3) 压力测试下看调度延迟，重点看 st（steal time）
vmstat 1 10
# 判读：st 列持续高于 5 说明 CPU 被宿主机抢走，商家超售了；低于 1 属于正常

vmstat 的 st 列，也就是虚拟化环境里的窃取时间，是判断超售最直接的指标。共享 CPU 的 VPS 在宿主忙碌时，你的虚拟机进程会被强制让出 CPU，表现为 st 列跳高、响应时间抖动。st 长期高于百分之五就说明这台机器的性能被其他人挤占了，升配也解决不了，得换商家或换独立 CPU 的机型。

内存实测要区分「可用内存」和「实际能用的内存」。系统标称 2 GB 的机器，扣掉内核、页表、系统服务之后真正给业务的大约 1.8 GB。但如果是 OpenVZ 之类的容器虚拟化，还会有额外的隔离开销。

# 1) 看真实可用内存，重点是 available 而不是 free
free -m
# 判读：available = free + buffers + cache 减去预留量，它才是真正能分配的

# 2) 看 swap 是否在用，swap 一旦动起来就是性能预警
swapon --show
vmstat 1 10 | awk 'NR>2 && $7>0 {print "swap 换入换出发生，si="$7" so="$8}'

# 3) 内存压力用 PSI 观察，比 free 准得多
cat /proc/pressure/memory
# 判读：some avg10 长期高于 10 说明有明显内存压力

第三条命令里的 PSI（压力 Stall Information）是现代内核提供的压力指标，比 free 准得多。free 显示还有内存不代表没有压力，PSI 直接告诉你有多少时间进程在因为内存不足而卡住等待。

五、磁盘 IO 实测：随机读才是关键指标

磁盘性能对网站体验的影响经常被低估。数据库查询慢、网站打开卡顿，很多时候不是 CPU 不够，而是随机读延迟高。

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

测磁盘要用 fio 而不是 dd。dd 测的是顺序写，只能说明顺序吞吐，对数据库场景参考价值有限。fio 能分别测顺序读、随机读、随机写、IOPS 和延迟。

# 1) 4K 随机读，这是数据库最关心的指标
fio --name=randread --filename=/tmp/testfile --size=1G --rw=randread --bs=4k --iodepth=32 --direct=1 --runtime=30 --time_based --group_reporting
# 判读：看 IOPS 和clat（完成延迟）

# 2) 顺序写，评估备份和日志写入速度
fio --name=seqwrite --filename=/tmp/testfile --size=1G --rw=write --bs=1M --iodepth=16 --direct=1 --runtime=30 --time_based --group_reporting

# 3) 用 iostat 长期观察真实业务下的 IO 等待
iostat -x 1
# 判读：await 高于 20 ms 说明磁盘在拖后腿；%util 接近 100 说明磁盘已饱和

fio 的结果判读有两个硬指标。单流随机读延迟 clat 超过 10 毫秒就偏慢，数据库并发查询时会明显排队；使用 iodepth 32 时的 IOPS 低于 1000 的话，跑数据库会比较吃力。另外 fio 测试会写入大量数据，跑完记得删掉临时文件，否则在配额小的机器上可能把磁盘写满。

磁盘类型这件事在香港商家之间的差别比配置表上体现得更大。SATA 盘随机读延迟通常在 8 到 15 毫秒，NVMe 可以压到 0.5 毫秒以内，而共享存储的云盘因为有网络层的读写延迟，随机读可能落在 20 毫秒甚至更高。这个差距在低并发时感知不明显，在数据库并发查询或者大量小文件操作时会成倍放大。商家如果只写「SSD 高性能云盘」而不写具体介质和队列深度，含义就相当模糊。

另外有两个细节会显著影响实测结果的可信度。第一是是否开启了写缓存和是否使用 raid 组，不同的 raid 级别在随机写场景下差别很大，raid5 的写惩罚会让小写入性能下降一大截。第二是虚拟化层的磁盘队列深度限制，有些商家为了保护宿主机，给每个虚拟机设置了较低的队列上限，导致你用 iodepth 32 测试时实际并发被截断，IOPS 数字会偏低很多。

测试完成后用 iostat 观察业务运行期的表现，是最有参考价值的一步。很多 VPS 空闲时随机读表现不错，但一有真实业务负载，宿主机上的其他虚拟机抢占了 IO 带宽，性能立刻下降。这种情况只有长期观察才能发现。

# 1) 看磁盘的型号、接口与队列深度上限
lsblk -d -o NAME,SIZE,ROTA,SCHED,MODEL
# 判读：ROTA 为 1 是机械盘，为 0 是固态盘

# 2) 看文件系统的挂载参数，确认有没有开 discard 和 noatime
findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
# 判读：有 noatime 表示不做访问时间戳更新，能省掉一部分随机写

# 3) 做一次真实的小文件写入测试，模拟代码部署和日志写入场景
fio --name=smallfile --directory=/root --size=512M --rw=randwrite --bs=4k \
    --numjobs=4 --iodepth=8 --direct=1 --runtime=20 --time_based --group_reporting
# 判读：小文件随机写 IOPS 低于 500，部署和编译类操作会明显拖慢

六、线路路径检测：怎么确认走的是不是优化线路

确认线路类型的唯一可靠方法是看实际路由路径。商家的线路标签只是营销命名，路由表才是事实。

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

判断优化线路的标志是在 traceroute 或 mtr 的路径里出现这些特定节点。电信 CN2 GIA 的特征是出现 59.43.x.x 这类 AS4809 的节点；联通 9929 的特征是出现 219.158.x.x 这类 AS9929 的节点；移动 CMIN2 的特征是出现 223.120.x.x 这类 AS58807 的节点。普通国际 BGP 则通常会经过广州或深圳的国际出口。

# 1) 从大陆机器向香港 VPS 追踪，观察去程
traceroute -T -p 443 你的服务器IP
mtr -r -c 100 --report 你的服务器IP

# 2) 从香港 VPS 反向追踪，观察回程
traceroute -T -p 443 你的本地出口IP

# 3) 查你的出口 IP 归属的运营商和地区
curl -s https://api.ip.sb/geoip | python -m json.tool 2>/dev/null || curl -s https://ipinfo.io

第二条命令是很多新手不会做但极其重要的一步。商家说的「优化回程」需要从香港侧发起追踪才能确认，而从大陆侧追踪只能看到去程。两侧路径不一致是常态，判断线路类型时必须两侧都看。

路由检测还要注意时点。线路描述是静态的，但实际路径可能因运营商调整而变化，所以晚上高峰和白天最好各测一次。如果两次结果差别很大，说明这条路径不稳定，即使单次测试很漂亮也不能作为长期依据。

路径中出现的节点特征	对应线路类型	晚高峰表现
59.43.x.x（AS4809）	电信 CN2 系列	通常平稳，拥塞少
219.158.x.x（AS9929）	联通 9929	通常平稳
223.120.x.x（AS58807）	移动 CMIN2	通常平稳
202.97.x.x（AS4134）	电信 163 普通	高峰易拥塞
大量境外绕行	回程绕路或非原生	延迟偏高且不稳定

七、晚高峰实测：时间窗口和采样方法

香港VPS的晚高峰实测是所有测试里最不可省略的一环，因为拥塞问题几乎全部在这个时段暴露。测试窗口的选择会直接影响结论的有效性。

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

实测时间窗口有两个建议。第一个必测窗口是工作日的 20:00 到 22:00，这是国内互联网流量的绝对峰值。第二个建议加测的窗口是周五傍晚，因为这一时段晚高峰提前出现，而且叠加了周末出行的流量。

采样方法上有一个关键点：不要只测一次，要分时段重复采样并记录。同一台机器在 20:05、20:25、20:45 三个点各测一次，取中位数作为代表值，波动幅度作为抖动指标。单次测试得到的漂亮数字，往往只是碰巧赶上了空隙。

# 1) 写一个循环脚本，在晚高峰连续采样 40 分钟，每分钟一次
for i in $(seq 1 40); do
  ts=$(date +%H:%M:%S)
  ping_res=$(ping -c 30 -i 0.2 你的服务器IP | tail -2 | head -1)
  tcp_res=$(curl -o /dev/null -s -w "%{time_connect},%{time_total}" https://你的域名)
  echo "$ts | $ping_res | $tcp_res" >> /tmp/peak.txt
done
# 判读：把结果按时间排序，看 20:00-22:00 区间是否出现明显劣化

# 2) 同时记录路由是否发生变化（拥塞时经常伴随路径切换）
mtr -r -c 50 --report 你的服务器IP >> /tmp/peak_path.txt

另外，测试期间不要只跑 ping。很多人在高峰测出的 ping 正常就收工了，而实际问题是 TCP 层面受限。

必须强调一个方法论上的陷阱：单次测试结果不能作为结论。同一台机器同一时间段的多次测试，结果可能相差百分之二十以上，这是正常波动不是异常。任何商家发给你的「实测截图」如果你无法复现，问题就出在方法上。

八、异常处置：测出问题了该怎么改

实测发现问题之后的处置顺序是有讲究的，先排除自身问题的可能性，再去判断是商家还是线路的问题，最后才考虑换机器。

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

第一步永远是排除自身。测试端机的网络、你本地的宽带、你路由器上的 QoS 设置、你在用的加速工具，都会污染测试结果。最简单的排除方法是在同一台机器上同时测两个不同香港 IP，或者用手机热点做一次对照测试。如果两个 IP 的表现一致地差，嫌疑就落在你这一侧。

第二步区分是机器问题还是线路问题。判断方法是看服务器本地的资源使用情况。

# 1) 排除本机资源瓶颈
top -b -n 1 | head -15
# 判读：%CPU 的 us+sy 低于 30 且 load average 接近 0，说明机器本身不忙

# 2) 排除内存压力
cat /proc/pressure/memory
cat /proc/pressure/cpu

# 3) 排除磁盘瓶颈
iostat -x 1 3 | tail -n 10
# 判读：await 低于 10 ms 且 %util 低于 50，磁盘不是瓶颈

# 4) 确认是线路问题：分别测往香港和往其他地区
mtr -r -c 50 --report 你的服务器IP
mtr -r -c 50 --report 8.8.8.8
# 判读：如果到香港丢包而到 8.8.8.8 正常，问题在跨境链路

第三步是分流处理。资源瓶颈的解法是升配或做应用层优化；单流慢但多流正常的解法是调整应用的并发连接数，或者在应用层启用多路复用；只有晚高峰丢包的解法是换线路类型，这类问题升配解决不了；st 持续偏高的解法是换商家，因为这是超售问题；IP 不可达的解法是换 IP 或换机房。

# 应用层可以立刻做的两个优化：多路复用 + 启用压缩
# 检查当前连接是否启用了多路复用
ss -ti dst 你的服务器IP | grep -i "mux"
# 判读：出现 "mux" 说明该连接已启用多路复用

# 测一下开启压缩后的实际收益
curl -o /dev/null -s -w "size=%{size_download} total=%{time_total}\n" --compressed https://你的域名

九、验收表与长期监控：把一次性测试变成持续基线

把前面各节的内容收敛成一张表，再配一套自动采集脚本。这张表可以直接打印出来，买到机器之后照着逐项打勾，任何一项不达标都有对应的处置动作。

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

测试项	命令	合格阈值	不合格时的动作
平均延迟	ping -c 100	平峰低于 50 ms	检查是否绕路，换机房
抖动	ping 的 mdev 值	低于 20 ms	线路不稳定，晚高峰复核
真实丢包	tcping -t 300	平峰低于 0.5%	换 IP 或换商家
晚高峰丢包	同上，20:00-22:00	低于 2%	换线路类型或加 CDN
实际带宽	iperf3 -P 16	达到标称值 60% 以上	核对端口与配额口径
反向带宽	iperf3 -R	不低于正向的 60%	回程未优化，注意上传场景
CPU 窃取	vmstat 的 st 列	低于 1	高于 5 说明超售，换商家
可用内存	free -m 的 available	高于物理内存 40%	升配或减服务
内存压力	/proc/pressure/memory	some avg10 低于 10	加内存或优化服务
磁盘随机读	fio 的 IOPS 与 clat	IOPS 大于 1000，clat 低于 10 ms	换 SSD/NVMe 机型
磁盘等待	iostat 的 await	低于 20 ms	升配或迁移数据
路径去程	mtr 报告	无绕路	换 IP 段或换机房
路径回程	香港侧 traceroute	落在优化线路节点	换机房或要求换线路

这张表的使用要点是分两批。第一批是到手当天就能测完的基础项（延迟、丢包、CPU、内存、磁盘、路径），第二批是必须等晚高峰窗口才能测的拥塞项。基础项不达标就应当立刻走退款流程，不要等到第二天。

如果这张表里超过三项不合格，正确的处理不是修机器，而是换商家或换线路类型。性能问题在虚拟化环境里绝大多数是商家的责任，商家不作为时及时止损比反复调优更省成本。

一次性验收只能告诉你机器交付时是什么状态，而线路质量是会变的。跨境链路出现拥塞、商家调整路由、宿主机邻居变多，这些变化都可能在某一天悄悄发生，等到用户投诉才发现就晚了。把上面几节的命令固化成一个小脚本，让机器自己每天记一份数据，才算把性能实测真正用起来。

监控脚本本身不需要复杂，关键是选对指标和判读方式。要长期记录的最小集合是五项：到指定目标的丢包率、到指定目标的往返延迟、TCP 连接建立耗时、CPU 窃取时间、以及磁盘等待时间。这五项任何一项持续劣化，都对应着一类明确的问题。

# 1) 每五分钟采一次样，写进带时间戳的日志，一行一条
cat > /usr/local/bin/vps-probe.sh <<'EOF'
#!/bin/bash
TARGET=${1:-你的服务器IP}
LOG=/var/log/vps-probe.log
TS=$(date +%Y-%m-%d\ %H:%M:%S)
LOSS=$(ping -c 20 -i 0.3 -q "$TARGET" | grep -o '[0-9.]*% packet loss' | cut -d' ' -f1)
AVG=$(ping -c 20 -i 0.3 -q "$TARGET" | grep -o '= [0-9.]*/[0-9.]*/[0-9.]*' | cut -d/ -f2)
ST=$(vmstat 1 2 | tail -1 | awk '{print $17}')
IO=$(iostat -x 1 2 2>/dev/null | tail -1 | awk '{print $10}')
echo "$TS loss=${LOSS} avg=${AVG} steal=${ST} await=${IO}" >> "$LOG"
EOF
chmod +x /usr/local/bin/vps-probe.sh

# 2) 用 cron 每五分钟跑一次
echo '*/5 * * * * /usr/local/bin/vps-probe.sh 你的服务器IP' | crontab -

# 3) 每周把日志汇总成一张表，看趋势而不是看单点
awk '{print $2}' /var/log/vps-probe.log | tr -d 'loss=' | sort -n | tail -20
# 判读：取最差的 20 条，如果这些样本集中在晚高峰，说明是拥塞而非偶发抖动

判读这张长期数据表时有一个实用技巧：把样本按小时分组做对比。如果丢包率在 20 点到 22 点这个区间系统性升高，其他时段几乎为零，那基本可以断定是跨境出口拥塞，属于线路类型问题，升配和优化都无解，只能换线路或加缓冲层。如果丢包率全天均匀分布，则更可能是本机网络环境或者目标侧的问题。如果丢包率是随机分布的零星尖峰，要看尖峰是否和 CPU 窃取时间升高同时发生，同时发生就指向宿主机超售。

这个脚本还有一个附加价值：它是免费且客观的证据。当你和商家就「线路是否稳定」产生争议时，连续几周的采样数据远比一次截图有说服力。多数商家看到带时间戳的连续丢包记录，比看到一个孤立的峰值数字更容易认真对待。

需要注意的是监控本身也有坑。第一，不要监控机器自己 ping 自己的公网 IP，这样测的是回环路径，数字会好得离谱。第二，目标 IP 要选一个稳定的参照点，选商家的另一台机器或者一台公共 DNS 服务器都行，但一旦选定就不要中途更换，否则历史数据无法对比。第三，日志会持续增长，记得配一个 logrotate 或者定期清理，否则几百 MB 的日志在 10 GB 磁盘上也是负担。

十、常见问题

香港VPS晚高峰延迟一般是多少算正常？ 平峰时段到大陆的延迟在 30 到 60 毫秒属于正常范围，晚高峰在 50 到 90 毫秒也还算可以接受。如果晚高峰延迟涨到 150 毫秒以上并且伴随丢包，说明这条线路没有做拥塞优化或者被大量流量挤占，不适合交互型业务。判断时要区分平均值和抖动值，平均值 60 毫秒但抖动 5 毫秒是好线路，平均值 45 毫秒但抖动 60 毫秒反而更糟。

用 ping 测出来丢包 5%，是不是说明线路很差？ 不一定。要先用 tcping 交叉验证，因为大量运营商和商家会限制 ICMP 响应速率，ping 的丢包可能只是探测包被降级处理。tcping 也丢才说明是真实的 TCP 层面丢包。另外测试时长至少要一百个包，因为少量样本下偶发的一两个丢包会放大成很高的百分比。

iperf3 测出来的带宽比商家标称低很多，是被限速了吗？ 不一定。iperf3 从你的机器单方向拉取时，瓶颈往往在你本地的上行带宽上，家用宽带的上行通常是下行的几分之一。要判断是否被限速，应该做反向测试，也就是加 -R 参数从香港 VPS 主动拉取，并且跑满三十秒排除慢启动干扰。

商家说他的线路是三网 CN2 GIA，怎么验证？ 用 mtr 或 traceroute 看实际路径节点。电信 CN2 GIA 的路径里会出现 59.43.x.x 这类 AS4809 的节点，联通 9929 会出现 219.158.x.x，路径特征对不上就不是这条线路。验证时要从大陆侧和香港侧各测一次，因为去程和回程往往是两套路径，只测一侧容易误判。

测试过程中跑出漂亮数据，可以直接下单年付了吗？ 不建议。所有测试都必须在晚高峰窗口重复采样至少三次，确认结果稳定可复现之后，才适合转年付。同一台机器相邻两次测试相差百分之二十以上属于正常波动，只凭一次漂亮结果做决策风险很高。

磁盘 fio 测试会不会把机器写坏？ 不会写坏，但要注意空间。fio 测试会生成与 --size 指定大小相当的文件，1G 测试就是占用 1 GB 磁盘空间。在 10 GB 磁盘的机器上要相应调小 --size，测完记得删除临时文件，否则配额会被占满导致服务异常。

实测发现某项不达标，应该直接退款还是先找商家？ 先找商家但要留证据。把测试数据、mtr 报告、时间点整理成文字发给工单，要求给出解释或调整方案。如果商家在两到三个工作日内没有实质回应，或者给出的解释与你的数据明显矛盾，就启动退款流程。退款申请要附上原始测试记录，比只说「速度慢」有效得多。

有没有必要买带测试 IP 的套餐？ 非常有必要。测试 IP 的价值在于能在付款前就验证线路类型和基础延迟，比拿到机器后再测要主动得多。付款前拿不到测试 IP 的商家，至少要主动索要晚高峰的三网延迟与丢包数据，并保留对话记录作为后续比对依据。