ICMP 与 ping 的关系
很多安全组默认不放行 ICMP，于是出现「ping 不通但业务其实正常」的现象；反过来，ping 通也不代表业务端口可用。ICMP 是独立于 TCP、UDP 的协议，放行它需要单独加规则。排查时把 ping 当作快速筛查手段而不是结论，生产环境的入方向通常只按需放行内网来源的 ICMP，公网侧保持默认拒绝。
ICMP 放行规则
ICMP 放行规则
入方向：协议 ICMP 类型 -1（全部） 授权对象 10.10.0.0/16
出方向：协议 ICMP 类型 -1 授权对象 10.10.0.0/16
说明：仅内网可 ping，公网保持默认拒绝
注意：类型 -1 表示所有 ICMP 类型，也可只放行 8（回显请求）用业务端口验证更可靠
用业务端口验证更可靠
ping -c 3 10.10.3.20 || echo 'ICMP 被拦或地址不可达'
nc -zv -w 3 10.10.3.20 80 # 业务端口结果更接近真实链路
curl -s -o /dev/null -w '%{http_code}\n' http://10.10.3.20/ # 应用层验证
# 内网全段巡检：结合 nmap 的 ping 扫描快速定位哪些主机不回显基本信息
| 协议 | ICMP（独立于 TCP、UDP） |
|---|---|
| 默认状态 | 安全组多数默认不放行入方向 ICMP |
| 放行建议 | 仅内网来源，公网保持拒绝 |
| 判断优先级 | 业务端口探测优于 ICMP 探测 |
典型使用场景
- 内网巡检：放行内网 ICMP 后可用 ping 批量确认主机存活
- 排查误判：确认「网络不通」是否只是 ICMP 被安全组拦截
- 链路质量观察：结合 ping 的时延与丢包判断链路是否抖动
- 路径排查：配合 traceroute 观察中间跳点的响应情况
判断连通性优先使用业务端口的 TCP 探测：ICMP 结果好或坏都不等于业务可达。
ICMP 不等于可达性
ICMP 走的路径与业务端口未必一致：中间设备可能对 ICMP 单独限速或丢弃，但完全放行 TCP；也可能反过来，ping 通而目标端口被策略挡住。因此巡检顺序建议是「先 ping 判断主机是否存在，再用 nc 或 curl 验证端口与应用」，两层都通过才认为链路可用。若批量巡检发现部分主机不回显，先确认是安全组策略差异还是主机本身休眠或关机，不要直接判定为网络故障。