VPS到手先跑这14条命令：从ping到mtr全流程排查

买了 VPS 之后，很多人只会做一件事：ping 一下，看到有回应就觉得没问题。然后部署上线，几天后发现慢得不能忍，却不知道该从哪查。这篇是一份可以直接照着执行的排查手册——从连通性、路由、带宽到磁盘性能，每一层都有对应的命令和判读标准。全文命令可在任何 Linux 服务器上直接运行，不需要装额外软件（少数会标注安装方式）。

一、第一步：先确认基础连通性

不要一上来就跑复杂的测试。先用最基础的工具确认服务器是活的，否则后面所有数据都不可信。

命令一：ping 测基础可达性与延迟。

ping -c 10 8.8.8.8

判读标准：看最后一行的统计。packet loss 必须接近 0%，如果出现 5% 以上丢包，说明链路有问题。rtt avg 是平均往返延迟，这是你后续所有判断的基线。

命令二：测 DNS 解析。很多「网站打不开」其实不是网络问题，而是 DNS。

dig +short example.com
nslookup example.com

如果 ping IP 通、但 ping 域名不通，那就是 DNS 配置问题，不是网络故障。这时该去检查 /etc/resolv.conf。

命令三：测端口连通性。有些服务能 ping 通但端口不通，这时候要单独测端口。

nc -zv example.com 443
curl -I https://example.com

判读：nc 返回 succeeded 说明端口开着；curl -I 返回 HTTP 状态码说明应用层正常。如果端口不通但 ping 通，通常是防火墙或安全组的问题。

二、第二步：路由追踪，看清数据走哪条路

这一步是判断「线路质量」的核心。ping 只能告诉你快不快，路由能告诉你为什么。

推荐工具：mtr，它结合了 ping 和 traceroute，会持续采样并统计每一跳的丢包率。

mtr -rw -c 100 8.8.8.8

参数含义：-r 生成报表模式（适合保存结果），-w 使用宽格式（避免内容被截断），-c 100 发送 100 个探测包。

如果 mtr 没装：

apt install mtr-tiny -y

怎么看结果？关键看两列：Loss%（丢包率）和 StDev（延迟标准差）。

这里有个关键判读技巧：丢包的位置比丢包的多少更重要。如果丢包从第 5 跳开始，一直延续到最后一跳，说明问题在第 5 跳；如果只有第 5 跳丢包、后面的跳都正常，那是这个节点懒得回应 ICMP 探测包，实际没有故障。这个区别能帮你避免把正常现象当成故障报上去。

三、第三步：识别线路类型

如果你的业务对国内访问速度敏感，这一步必须做。

核心判据：看路由里的 IP 段。

traceroute -n 8.8.8.8

国内电信骨干的识别特征：

59.43.x.x —— CN2 骨干段。
202.97.x.x —— 163 骨干段（公共互联网）。

三种典型结果的判读：

全程 59.43，无 202.97 → 真 CN2 GIA，从省级出口就走专线。

59.43 与连续两个以上 202.97 混现 → CN2 GT，国内段走公共骨干，出国才上专线。

全程只有 202.97 → 普通 163 骨干，和 CN2 无关。

必须记住的一点：去程和回程要分开测。在自己电脑上跑的是去程（国内→服务器），在服务器上跑指向国内 IP 的才是回程。

# 在服务器上执行，测回程
mtr -rw -c 50 114.114.114.114

「去程 GIA、回程 163」的情况真实存在。只测一个方向就下结论，很可能被误导。

四、第四步：测真实带宽，不要信标称

标称 1Gbps 不等于你能跑 1Gbps。实际带宽受端口限速、共享争用和上游拥塞三重影响。

测下载速度：

curl -o /dev/null -w "%{speed_download}\n" \
  http://speedtest.tele2.net/100MB.zip

返回值单位是字节/秒，除以 131072 就是 Mbps。比如返回 12500000，约等于 95Mbps。

测磁盘 IO：带宽够了但磁盘慢，一样会卡。

dd if=/dev/zero of=testfile bs=1M count=1024 conv=fdatasync
rm -f testfile

判读：最后一行会显示写入速度。SSD 通常应在数百 MB/s 量级；如果只有几十 MB/s，要么是机械盘，要么是 IO 被限制了。

测 CPU 性能：

sysbench cpu --cpu-max-prime=20000 run
或者简单点：
time sha256sum /dev/zero & sleep 5; kill %1

什么时候该跑这三项？刚拿到服务器时跑一次，留作基线。以后觉得变慢了再跑一次对比，就能判断是「一直就这样」还是「后来退化了」。有基线数据，和客服沟通时才有底气。

五、第五步：系统层面的常见瓶颈

网络都没问题时，瓶颈往往在系统内部。这几个命令能快速定位。

看内存与交换分区使用：

free -h

重点看 available 这一列，不是 free。Linux 会把空闲内存用于缓存，free 显示很小是正常的。如果 swap 使用量持续增长，说明内存确实不够了。

看负载与 CPU：

uptime
top -bn1 | head -20

关键概念：负载值要对比核心数看。4 核机器的负载 4.0 意味着已经满载，而 8 核机器负载 4.0 只用了半满。很多人看到负载 2 就慌，其实是多虑了。

看磁盘空间与 inode：

df -h
df -i

df -h 看空间，df -i 看 inode 数量。有一种情况是空间还剩很多，但 inode 用完了，表现同样是「写不进文件」。这种情况在存了大量小文件的服务器上很常见。

看进程占用：

ps aux --sort=-%mem | head -10
ps aux --sort=-%cpu | head -10

这两条分别列出最占内存和最占 CPU 的进程。排查「不知道为什么变慢」时，先看这两个列表往往就能找到答案。

六、六家可纳入对比的渠道方向

在现有渠道里，以下几家在地区覆盖与线路配置上值得纳入对比。重点：它们的公开描述没有给出具体的线路规格与带宽额度，实测数据必须用前面五节的方法自己跑出来。

DigitalVirt：美国洛杉矶、香港、日本东京、德国法兰克福、英国伦敦五地，标注 CN2 GIA / 9929 / CMIN2 / 4837 四套线路。如果你的测试目的是对比不同线路，它能提供多个对照组。

Zorocloud：标注 CN2 GIA / 9929 / CMIN2，覆盖美国 CERA 高防、新加坡、香港、台湾、英国等地。它的特点是 GIA 与高防的组合。

恒创科技：标注 CN2 / GIA / BGP / HGC，具有自有 ASN 与 APNIC/ARIN 会员资质。自有 ASN 在这里有实际用途——用 whois 查 ASN 时能直接对上，验证线路更省事。

Backwaves 走 9929 / AS10099（CUG）联通精品网。用户以联通为主时，用它做对照组比 GIA 更合适。

vollcloud 提供香港 CMIN2 大带宽产品与原生 IP 精品线路。移动用户为主的场景可以对口测试。

CloudCone 提供多地区 VPS 产品线。做横向对比时可以作为普通线路的参照样本。

提醒一句：以上都是商家公开描述。本文所有命令都不依赖具体商家，拿着测试 IP 就能跑。先测再做决定，比看任何宣传都可靠。

七、结论：排查要按顺序来，不要跳步

一、先确认连通性，再谈性能。ping、DNS、端口三步走完，很多「网络问题」其实在这一步就能定位，不用往后查。

二、路由是判断线路的唯一硬证据。59.43 和 202.97 的分布决定线路类型，而且必须去程回程分开测。商家写什么都可以改，路由表不会撒谎。

三、带宽、磁盘、CPU 三项都要建基线。刚拿到就测一次存下来，以后变慢时才有对比依据。没有基线，和客服争论时你手里什么都没有。

四、系统瓶颈先看 available 内存、负载对照核心数、inode 用量。这三个反直觉的点最容易误判：free 小是正常的，负载 2 不一定高，空间够也可能写不进。

最后一句：排查的价值不在于「证明服务器有问题」，而在于「知道它现在的水平」。跑完这套流程，你会清楚地知道这台机器能做什么、瓶颈在哪、什么时候该升级。把这套命令存成一个脚本定期跑，你就有了一份自己的监控数据。

本文所涉 Linux 命令、mtr 与 traceroute 的判读方法、CN2 骨干网识别特征均整理自公开技术资料与官方文档，为 2026 年 11 月查询所得。命令语法以主流 Linux 发行版为准，不同版本可能存在参数差异，执行前请确认环境。运营商网络配置与路由策略会随时调整，文中路由特征与判读规则为一般性规律，不构成对任何具体线路的保证。文中对渠道的描述均来自其公开页面，未做实测验证。执行涉及系统配置与数据写入的命令前请自行评估风险并做好备份。本文内容仅供参考，不构成任何购买承诺或性能保证，亦不代表本站立场。读者应独立判断、自行决策，因执行命令或使用相关产品所产生的直接或间接损失，作者及本站不承担任何责任。