Komari 探针显示丢包率 100%？别慌，教你正确排查网络连通性

最近给自己的服务器配了个 Komari 探针，想着实时监控一下各地的网络连通性，结果刚设置好没多久，就发现了一个让人心慌的问题：列表里江浙联通的公共 DNS 居然显示“无法 Ping 通”，丢包率直接标红了 100%。

第一反应是不是我的服务器挂了？还是 Komari 的配置出错了？毕竟这节点是让 AI 随便给的一个，我也没太深究。仔细研究了一番后发现，遇到这种情况的朋友真不少，今天就借着这个问题和大家聊聊探针里的 ICMP 限制以及正确的排查姿势。

首先要明确一个概念：Ping 不通不代表你的服务器断网了。

目前国内绝大多数运营商（尤其是联通和电信的公共节点）为了自保，都有非常严格的防火墙策略。他们通常会对外部的 ICMP 请求（也就是 Ping 使用的协议）直接进行丢包处理，或者干脆不回响应。这就是为什么你在探针里看到丢包率 100%，但实际上你的业务访问完全没问题。

特别是像“江浙联通公共 DNS”这类公网基础设施节点，它们的优先级是保障 DNS 解析服务，而不是响应你“我是死是活”的 Ping 探测请求。所以，单纯看到 ICMP 丢包 100%，大多数情况下是运营商策略问题，并非你服务器网络故障。

既然 Ping 结果不可靠，那我们如何判断节点是真的挂了还是单纯被“拒之门外”呢？这里有几个进阶的验证方法，建议按顺序操作：

1. 使用 TCPing 替代 ICMP ICMP 被挡了，那我们就走 TCP 协议。大多数探针工具或者你本地的终端，都可以尝试对目标端口（比如 DNS 的 53 端口，或者 HTTP 的 80/443 端口）进行测试。如果 TCP 延迟正常，那就更证实了是 ICMP 策略屏蔽。

2. 路由追踪 光看结果不行，得看路是怎么走的。在服务器上执行 traceroute（Windows 是 tracert），看看数据包是在哪一跳断掉的。

3. 模拟真实业务请求 既然是 DNS 探测，那就直接用 nslookup 或者 dig 命令去解析个域名试试。如果 DNS 解析速度飞快，说明服务本身是好使的，探针的丢包报警可以忽略，或者去配置里把这个 ICMP 检测关掉。

如果你在使用 Komari 这类工具，遇到这种公共节点高丢包率，建议做以下调整：

混合检测模式： 不要只看 ICMP。增加 TCP 或 HTTP(S) 的检测任务，特别是针对 80、443 这种必须开放的端口，结果会更真实。
更换检测目标： 如果目的是监测自家服务器到用户骨干网的质量，可以避开运营商的核心 DNS，选择一些对 ICMP 友好的 CDN 节点或者第三方测速节点作为参照物。
关注趋势而非绝对值： 偶尔的 100% 丢包可能是瞬时的网络抖动或策略触发，只要不是持续长时间的不可达，通常不用焦虑。

看到 Komari 探针报错先别慌，江浙联通 DNS Ping 不通大概率是碰上了运营商的 ICMP 屏蔽墙。对于网络监控，我们要学会透过现象看本质，结合 TCPing 和业务请求来做综合判断，别被一个红色的 100% 吓到了。希望这篇排查思路能帮到同样遇到问题的朋友！