VPS ping 不通怎么排查：双源实测拆开 ICMP 层
VPS ping 不通怎么排查，先别急着重启机器。上周有张工单：网站能打开，后台也能登，ping 却全红，20 个包一个没回，提单人怀疑 IP 被封，问要不要换机房。VPS ping 不通怎么排查，多半不是宕机，而是 ICMP 被单独丢掉了，网站走的 TCP/TLS 没受影响。把两个中国大陆不同运营商出口对同一批公开目标的真实读数摊开，这件事就看得很清楚。
ping 不通，先别急着重启机器
VPS ping 不通怎么排查，动作其实很短：先确认是不是只有 ICMP 这一层没回，再决定要不要往下查。ping 不通给人的第一反应常是机器没了，可 ICMP Echo 只是网络里最容易被单独关掉的一种报文，把它和网站访问划等号，是这类工单里最常见的拐错弯。看到 ping 不通就重启、就提工单换 IP，往往白忙一轮。
直接答案放这里：ping 不通不等于宕机，ping 通也不等于网站能开，两者测的不是同一件事。后面每一节都拿两个出口的真实读数把这句话拆开。
只处理 ICMP 这一层，端口是另一回事
ping 不通归 ICMP 这一层管。TCP 端口不通是另一码事，安全组、系统防火墙、服务有没有监听、上游有没有拦，那一套拆法在 端口不通怎么排查 里已经按四层写过，这里不重复。两篇标题都带不通怎么排查，但一个查 Echo 回显，一个查端口握手，命令别混着用。ping 不通的时候先跑 ping，端口不通的时候先跑端口探测，第一步就不一样。
看到这里如果只是想挑台机器，可以先去 选机器前先学会看网络这一层 翻翻按层归过的实测记录，心里有个底再回来敲命令，比一上来就换 IP 省事。
先分层：ping 不通测的是 ICMP，网站走 TCP/TLS
VPS ping 不通怎么排查，绕不开一件事：ping 和网站根本不在同一层。把协议分层摆清楚，后面那些反常的读数才不会看拧。
ping 到底测了什么
ping 发的是 ICMP Echo Request，对端愿意回就回一个 Echo Reply，这一来一回拿到一个耗时。它不建 TCP 连接，不做 TLS 握手，不取网页内容。很多主机、很多中间设备会把 ICMP 单独限速或者直接不回，业务端口照常开着。所以 ping 不通只能说明这一来一回没成，说明不了网站能不能开，也说明不了机器还在不在。反过来，ping 通只证明 Echo 有人回，跟 443 端口有没有人应答、证书能不能验过、页面吐不吐得出来，一点关系都没有。
网站打开要过哪几段
网站这一侧要过好几段：域名解析到 IP、TCP 建连、TLS 握手、等到首字节、把响应收完。curl 用 -w 能把这几个累计时间点一次打出来，变量怎么写可以翻 curl 官方手册 和 writeout 变量清单。DNS 段怎么拆见 DNS 解析慢怎么排查，握手与首字节那几段见 网站打开慢按五段拆。ping 不通的时候，这几段可能一段都没受影响。
表 1 把两个出口对三个公开 HTTPS 目标的 curl -w 读数摊开，单位是秒，code 是 HTTP 状态码，全丢或没建连的行不往里塞。
表 1 curl -w 五段累计计时双源读数（秒）
| 目标 | 探测源 | code | dns | tcp | tls | ttfb | total |
|---|---|---|---|---|---|---|---|
| www.baidu.com | 广东 cn-probe-1 | 200 | 0.000916 | 0.031019 | 0.159992 | 0.191253 | 0.191487 |
| www.baidu.com | 北京 cn-probe-2 | 200 | 0.004000 | 0.007000 | 0.099000 | 0.103000 | 0.103000 |
| www.tkvps.com | 广东 cn-probe-1 | 200 | 0.064946 | 0.067900 | 0.181362 | 0.198438 | 0.368767 |
| www.tkvps.com | 北京 cn-probe-2 | 200 | 0.509000 | 0.547000 | 0.704000 | 0.788000 | 0.985000 |
| ipinfo.io | 广东 cn-probe-1 | 200 | 0.031562 | 0.282145 | 0.543769 | 0.909062 | 0.909299 |
要留意这几列是 curl -w 打出来的累计时间点，从请求发起算起，一路只增不减。相邻两列相减才是各段净耗时，把 time_starttransfer 直接当成首字节耗时、把 time_total 当成传输耗时，都是常见的读错法。ping 不通的场合拿这张表看服务还在不在，比盯着一个 Echo 有用得多。看 www.baidu.com 广东那行，dns 0.000916、tcp 0.031019、tls 0.159992、ttfb 0.191253、total 0.191487，code 200；北京那行 dns 0.004000、tcp 0.007000、tls 0.099000、ttfb 0.103000、total 0.103000，也是 200。再看 www.tkvps.com，广东 tls 0.181362、total 0.368767，北京 tls 0.704000、total 0.985000，同一个域名两源在握手这一格的累计读数差得很明显。ipinfo.io 广东那行 total 0.909299，code 仍是 200，后面还会用到。
双源实测：ping 不通的那个 IP，服务照常
VPS ping 不通怎么排查，最好用一组能把两层同时照出来的数据。选的是 114.114.114.114，两个中国大陆不同运营商出口、同一批 20 包、同一条命令。
表 2 是这次 20 包 ICMP 的双源全表，发 20 包，丢包列写百分比，avg 列写平均回显耗时，全丢的格子照实写未取得。
表 2 两台探测源 20 包 ICMP 双源读数
| 目标 | 广东电信 cn-probe-1 丢包 / avg ms | 北京阿里云 cn-probe-2 丢包 / avg ms |
|---|---|---|
| 114.114.114.114 | 100.0% / 未取得 | 100.0% / 未取得 |
| 223.5.5.5 | 0.0% / 4.792 | 0.0% / 2.394 |
| 119.29.29.29 | 0.0% / 9.740 | 0.0% / 6.731 |
| 1.1.1.1 | 0.0% / 52.181 | 0.0% / 202.057 |
| 8.8.8.8 | 0.0% / 161.265 | 0.0% / 176.003 |
| www.baidu.com | 0.0% / 27.140 | 0.0% / 2.653 |
| www.tkvps.com | 0.0% / 1.907 | 0.0% / 38.901 |
| ipinfo.io | 15.0% / 251.729 | 0.0% / 193.478 |
| hnd-jp-ping.vultr.com | 0.0% / 234.123 | 5.0% / 110.333 |
| lax-ca-us-ping.vultr.com | 0.0% / 274.475 | 0.0% / 168.654 |
| one.one.one.one | 0.0% / 51.996 | 100.0% / 未取得 |
| lg-lin1.justhost.asia | 100.0% / 未取得 | 100.0% / 未取得 |
114.114.114.114：两台源都 100% 丢包
两台源对 114.114.114.114 都是 20 发 0 收、100.0% 丢包，输出里没有 rtt 那一行，min、avg、mdev、max 四格全是未取得。这里写清楚：未取得延迟，未做任何估算。不拿 223.5.5.5 的 4.792 或 2.394 去反推它的延迟，也不写大概几百毫秒这类没影的数。ping 不通到 100.0% 丢包，能记的只有这一个出口这一刻没收到 Echo Reply。
同一个 IP 仍能解析域名
同一个 114.114.114.114，广东这台源用 53 端口问了一次 www.baidu.com，拿到了完整应答。下面是从原始回显里逐字节选的几行。
Server: 114.114.114.114
Address: 114.114.114.114#53
Non-authoritative answer:
www.baidu.com canonical name = www.a.shifen.com.
Name: www.a.shifen.com
Address: 180.101.51.73
Name: www.a.shifen.com
Address: 180.101.49.44
Server 和 Address 都指向 114.114.114.114 的 53 端口，www.baidu.com 先转到 www.a.shifen.com，再给出 A 记录 180.101.51.73 与 180.101.49.44。有人把 114.114.114.114 填进 resolver，顺手 ping 了一下，看到 ping 不通就以为 DNS 配错了，回头改了半天配置。其实解析一直正常，ICMP 全丢和 53 端口能答是两件事，114DNS 丢包照样解析那篇 的标题早就埋过这个伏笔。北京这台源没装 nslookup，DNS 侧就以广东这台的应答为准，不替它补一段解析结果。
对照组 223.5.5.5：ICMP 通、有 RTT
对照组挑 223.5.5.5：广东 20 发 20 收、0.0% 丢包、avg 4.792 ms，北京 20 发 20 收、0.0% 丢包、avg 2.394 ms。同一个出口，一个目标 ping 不通、一个目标有回显，说明这台源本身会不会发 ICMP、命令对不对都没问题。ping 不通的那个目标只是不回 Echo，不是这台源坏了。看到这里可以顺手去 换个出口复测差多少 对照一下同类记录，延迟怎么测才准 那篇把回显耗时的读法写得更细。
两个源的标签写死，方便逐条回溯。cn-probe-1 是 103.39.226.31，中国广东电信 AS4816 单线，采样 2026-11-15 09:21:36 CST；cn-probe-2 是 8.140.30.240，中国北京阿里云 AS37963 BGP 多线，采样 2026-11-15 09:24:54 CST。两台都在中国大陆，命令统一 ping -c 20 -i 0.2 -W 2，curl 走 curl -4 -s -o /dev/null -w 五段变量、带 --max-time 12。表 1 表 2 里每个数都能在这两个时间点、这两台源上逐条对上，别把它读成更多出口的结论。
换个出口，快慢会翻过来
VPS ping 不通怎么排查，还有一格最容易被忽略：同一个目标换个出口，读数会整个翻过来。表 2 横着读就能看到。
1.1.1.1 广东 avg 52.181 ms，北京 avg 202.057 ms，差 149.876 ms，北京这一侧明显偏大。8.8.8.8 反过来更接近，广东 161.265 ms、北京 176.003 ms。www.tkvps.com 差得更开，广东 1.907 ms，北京 38.901 ms。Vultr 东京的 hnd-jp-ping.vultr.com 是另一个方向：广东 234.123 ms，北京 110.333 ms，这一回广东偏大，而且北京这一源 20 发 19 收、5.0% 丢包。同一个目标，广东快还是北京快，没有统一答案。ping 不通也一样，one.one.one.one 广东 0.0% 丢包、北京 100.0% 丢包，换个出口结论就反了。只看一个出口就下判断，很容易把出口差异当成目标的问题。去程路由怎么查 里按路径拆过这一类差异。
逐跳看丢在哪：tracepath -n 怎么读
VPS ping 不通怎么排查，光看终点丢不丢还不够，逐跳能看出回显停在哪一段。tracepath -n 这两个出口都能跑，下面贴的是原始行，不补跳数、不猜中间设备是谁。
1?: [LOCALHOST] pmtu 1500
1: 192.168.247.30 13.722ms
1: 192.168.247.30 3.418ms
2: no reply
3: no reply
4: 103.45.0.53 2.053ms
5: no reply
6: no reply
7: 219.133.32.133 2.610ms
8: 119.147.223.157 5.013ms
9: no reply
10: 202.102.69.50 27.964ms
11: no reply
12: 58.217.192.202 29.908ms
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
广东这台对 114.114.114.114，头几跳有回显，4 跳 103.45.0.53 是 2.053ms，10 跳 202.102.69.50 跳到 27.964ms，12 跳 58.217.192.202 是 29.908ms，从 13 跳起一路 no reply 到 20 跳，末尾 Too many hops: pmtu 1500。北京那台对同一目标，5 跳 10.216.130.94 是 30.333ms，7 跳 183.207.67.109 是 22.798ms asymm 6，10 跳之后同样全是 no reply，也是 Too many hops: pmtu 1500。20 跳上限内没走到终点，逐跳回显里这种孤立偏大的单点，多见于中间设备对 ICMP 限速排队，不能拿它判定那一跳拥塞，更不能拿它给目标补一个延迟。ping 不通到全丢包时，逐跳没回显的那一段同样未取得延迟，未做任何估算。分片与 MTU 该在哪一步核对，见 MTU 检查那一篇。
两个反例：ping 通照样打不开，ping 不通照样服务在
VPS ping 不通怎么排查，还有两个反例得摆上来，它们把通和能打开彻底拆开。
反例 A：one.one.one.one
表 2 里 one.one.one.one 广东 0.0% 丢包、avg 51.996 ms，按 ping 的标准算通得很正常；北京 100.0% 丢包，算 ping 不通。可两台源对它的 HTTPS 请求都是 code=000：广东这台 dns 0.031350，tcp、tls、ttfb 全是 0.000000，total 卡在 12.002542；北京这台 dns 0.012000，total 8.010000，remote_ip 解析到 1.1.1.1 也没建成连接。广东这边 ping 通，网站照样打不开。ping 通不等于网站能打开，这一组是最直接的证据。
反例 B：ipinfo.io
ipinfo.io 广东 15.0% 丢包、avg 251.729 ms，20 发只收回 17 个，按很多人的习惯已经该判链路不行了。可同一台源对它的 HTTPS 请求 code=200，dns 0.031562、tcp 0.282145、tls 0.543769、ttfb 0.909062、total 0.909299 s，一次页面事务完整跑完。部分丢包不等于服务不可用。ping 不通或者丢一部分包，跟业务能不能用，中间还隔着好几层。
什么时候 ping 不通是真的坏了
VPS ping 不通怎么排查，真正要警惕的是 ICMP 和 HTTPS 同时没回响的那种。单看 ping 全丢就慌，往往慌早了。
反例 C：lg-lin1.justhost.asia
lg-lin1.justhost.asia 是商家官方的 LG 域名，两台源对它都是 20 发 0 收、100.0% 丢包，HTTPS 也都是 code=000，广东 total 12.001843、北京 total 12.000000，后者 remote_ip 还解析到了 132.243.255.166 却没建成连接。从这两个出口看过去，这个域名既没有 ICMP 回显，也没有一次成功的 HTTPS 事务。能写的就到这一句为止：这是本次实测里两个出口的读数，不能据此说机房出了故障，也不能说这家服务整体不可用。
我第一次拉到这组数，差点照着两源全红去给商家提工单，说它 LG 挂了。回头看才明白，官方 LG 域名禁掉 ICMP 是常见做法，两个出口既 ping 不通、又拿不到 200，只能说明这两个出口到这个域名这一段没通，撑不起机房层面的判断。
改用 TCP 端口验证
ping 不通的时候换个层验证更实在：直接对业务端口建连，或者跑一次带状态码的 curl，看的是真正承载业务的那条路通不通。ICMP 被安全组或系统防火墙单独丢掉，是很多机器的默认状态，不影响网站、不影响 SSH。安全组要放行什么、端口那套怎么拆，归 四层拦截那篇的用法。真要按商家核对 LG 入口和 ICMP 策略，按商家查 LG 与安全组策略 里按家归过，比对着一次 ping 全红猜省事。
一步到位的 ping 不通排查顺序
VPS ping 不通怎么排查，把上面的动作串成一条顺序，照着走一遍基本能定位到层。
表 3 把每一步的命令、正常长什么样、异常该往哪一层走列在一起，编号只是顺序，不是重要性排名。
表 3 ping 不通按层排查的动作顺序
| 步骤 | 敲什么 | 正常长什么样 | 异常往哪走 |
|---|---|---|---|
| 1 | 对 223.5.5.5 跑 ping -c 20 -i 0.2 -W 2 | 20 发 20 收、0.0% 丢包、有 rtt 行 | 本机出站或命令写法，先自查 |
| 2 | 对目标跑同一条 ping | 有回显、有 avg ms | 全丢包先记未取得延迟，未做任何估算 |
| 3 | nslookup 或 dig 问目标域名的 53 端口 | 拿到 A 记录 | 解析链路，见 DNS 层 |
| 4 | curl -4 -w 带状态码请求目标 | code 200、五段有读数 | 业务层，按五段拆耗时 |
| 5 | 对业务端口建连或 tcping | 端口握手成功 | 安全组与端口那层 |
| 6 | tracepath -n 逐跳看回显 | 20 跳内有逐跳读数 | 结合去程路径，孤立大值别当拥塞 |
| 7 | 换第二个出口对同一目标复测 | 两源结论对得上才下判断 | 出口差异，不当成目标故障 |
顺序的关键是别跳步。先在同一台源上换个已知会回 Echo 的目标，确认命令和本机出站没问题；再看目标是不是只有 ICMP 全丢、业务端口还活着；然后才轮到逐跳和商家策略。ping 不通就改 DNS、就换 IP、就重启，三步都跳过了业务层还在不在这一问。时间对不对、MTU 合不合适，会分别影响证书校验和分片，时间不准怎么排查 与 MTU 检查那一篇各管一格，跟 ICMP 层不是一回事，这里只点一句。
常见问题
VPS ping 不通怎么排查，网站能打开是不是就没宕机？
不能只凭 ping 下结论。ping 不通测的是 ICMP Echo 这一来一回，网站要过 DNS、TCP、TLS、首字节好几段。表 2 里 114.114.114.114 两源 100.0% 丢包，同一个 IP 在 53 端口照样解析出域名，就是分开的证据。全丢包只写未取得延迟，未做任何估算，再拿带状态码的 curl 验一次业务路。
为什么 114.114.114.114 ping 不通，却还能拿来解析域名？
ICMP 和 DNS 是两套协议、两个端口。广东这台源对它 ping -c 20 -i 0.2 -W 2 是 20 发 0 收，可 nslookup www.baidu.com 114.114.114.114 拿到了 114.114.114.114#53 的应答和 A 记录 180.101.51.73、180.101.49.44。不回 Echo 不等于 53 端口不服务，把 ping 不通当成 DNS 配错是最常见的误判。
云厂商默认禁 ICMP 吗，安全组要放行什么？
各家策略不一样，别按记忆里的一句默认来。能验证的动作是两步：先看业务端口和 HTTPS 状态码正不正常，再看 ICMP 是不是单独被丢。生意不受影响时，ping 不通不一定要放行任何东西；真要放，是安全组和系统防火墙里针对 ICMP Echo 的那条规则，不是把端口全开。
两台探测源都 100% 丢包，能算出延迟大概多少吗？
算不了。114.114.114.114 两源输出里没有 rtt 行，min、avg、mdev、max 四格全是未取得，这里写清楚：未取得延迟，未做任何估算。不拿 223.5.5.5 的 4.792 或 2.394 反推，也不写大概几百毫秒。ping 不通到全丢，能记的只有没收到 Echo Reply。
ping 通了但 SSH 连不上，该查哪一层？
查 TCP 端口那一层。ping 通只说明 Echo 有人回，SSH 的 22 端口有没有监听、安全组放没放、系统防火墙拦没拦，ping 一概照不见。one.one.one.one 广东 0.0% 丢包、avg 51.996 ms，ping 通得很正常，HTTPS 却是 code=000，就是同一类分离。端口那套怎么拆，归端口不通那一篇。
用 tcping 或 curl 代替 ping 判断通不通靠谱吗？
看要答什么。想验业务路通不通，tcping 对业务端口握手、curl 带状态码取一次页面事务，比 ping 贴题得多，表 1 的五段读数就是这么来的。想看 ICMP 这一层本身丢不丢，还得回到 ping。两者不是替代关系，ping 不通的时候换一层验，正好把问题分开。
tracepath 全是星号，是不是说明链路断了？
不说明。tracepath 里 no reply 常常只是那一跳的设备不回 ICMP，20 跳上限内的输出末尾写着 Too many hops: pmtu 1500，意思是没在 20 跳内走到终点，不是链路断了。广东那台 10 跳 27.964ms、12 跳 29.908ms 这种孤立偏大的单点，多见于中间设备对 ICMP 限速排队，别拿它判定拥塞，更别拿它补目标的延迟。
结语：把 VPS ping 不通怎么排查收成一句话
回到开头那张工单。把 114.114.114.114 填进 resolver 的那位，后来只改了一处：不再拿 ping 全红当配错，改看 53 端口有没有应答，解析一直好好的。VPS ping 不通怎么排查，说到底就一句：先把 ICMP 这一层和 DNS、TCP、TLS 分开，再用带状态码的请求去验真正承载业务的那条路，两源都测过才下结论。ping 不通不代表宕机，ping 通也不代表网站能开，这两句能记住，多数工单不用提。
真到排障无果、想换台机器重测那一步，优惠券与在售套餐 按预算挑就行，别急着按某一次 ping 全红下单；按层归好的实测归档 和 按网络与机房归的商家清单 可以顺着找同一层的其它记录。
