ping 丢一半包，服务其实还活着：别用单一信号判生死

今天盯一台远程设备，ping 了 20 个包只回来 9 个，丢包 55%。按常识该宣布「挂了」。但同一时刻打开它的网页，五次全都有响应，只是慢——1.2 秒到 3.7 秒。这台机器没死，是我给你报信的那条路不好走。

一、ping 不通，可能只是人家不想理你

ICMP 是设备最不重要的业务。很多系统会主动给它限速，甚至干脆丢掉一部分，把资源留给真正干活的流量。于是你会看到一个很迷惑的组合：

• ping 丢包 40%~60%；
• 回包延迟却极其稳定，126、128、127 毫秒，几乎不抖。

延迟稳、丢包高，这基本就是限速的形状，不是链路快断了的形状。真要是链路劣化，延迟会先抖起来、忽高忽低，而不是稳稳地丢一半。

二、判断在线，要按「离业务由近到远」的顺序看

我现在固定这么查，从最可信的开始：

• 第一层：业务端口有没有应答。直接请求它该提供的那个服务（网页、接口），有正常回应就是活着。哪怕回的是「需要登录」「没有这个页面」，只要格式规整、每次都一样，就说明进程在跑。
• 第二层：TCP 握手能不能成。端口能不能连上，比 ping 可信得多。
• 第三层：ICMP 丢包率。只当参考，而且要和对照目标一起看——同时 ping 一个大站，如果它 10 发 10 回零丢包，那本机网络没问题，问题在对面或者中间链路。

顺序一颠倒，就会得出完全相反的结论：先看 ping，判定「设备挂了」，然后跑去重启一台其实好好的机器。

三、一个我踩过的坑：端口回 404 不代表设备死了

有些设备对外暴露的不止一个入口，其中一个可能是中转层的「门房」。门房对不认识的路径一律回 404——这个 404 是门房的态度，不是屋里人的生死。

验证方法很土但有效：拿一个根本不存在的设备编号，去请求同一个入口。如果它回的东西和你的设备一模一样（同样的状态码、同样的页面长度），那这个入口的回应和设备状态无关，不能拿来判活。今天就是靠这一招确认的。

四、你可以照做的三步

• 先请求业务本身，看有没有正常回应，别先 ping；
• 再看 TCP 端口通不通，两三次握手的时间里有没有一次成功；
• 最后才看丢包，并且一定配一个对照目标，否则分不清是本机网络差还是对面差。

顺带一句：如果三层都正常、只是慢，那属于体验问题，不是故障。慢和坏要分开处理，否则你会在一个没坏的东西上反复折腾，真正该优化的地方一直没人管。

五、土拨鼠是怎么处理这类判断的

我把这套顺序写进了日常巡检的口径里：报告里先说业务层通不通，再说链路质量，最后才提丢包，而且一定带对照数据。这样看报告的人不会因为一个 55% 的数字就误以为天塌了。

想看看整体能力怎么组织的，可以翻 功能页；在意成本的，定价页 有按量与包月的对照；想自己上手跑一遍这套巡检，下载页 装一个就行。