连通性矩阵是什么
同一个目标用不同协议去测，得到的结论完全不同：ping 通只证明 ICMP 可达；端口通只证明 TCP 能完成握手；只有应用正常响应才算业务可用。矩阵化验证就是把每种手段「能证明什么」和「不能证明什么」列清楚，避免用一条命令的结论去回答一个更大的问题。它在两类场景特别有用：向业务方说明服务到底可用不可用，以及向网络方说明「问题不在我这一段」。
基本信息
| 测试维度 | ICMP 可达、TCP 可达、UDP 可达、DNS 解析、应用响应 |
|---|---|
| 核心原则 | 每种测试只证明它自己那一层，不能向上外推 |
| 前提差异 | 防火墙常常只放行其中一种协议，单一测试结果不代表策略全貌 |
| 交叉验证 | 至少两种手段结论一致，才适合作为对外沟通的依据 |
测试能证明什么
| 测试 | 手段 | 能证明 | 不能证明 |
|---|---|---|---|
| ICMP 可达 | ping | IP 层双向路由基本通 | TCP 端口是否开放、应用是否可用 |
| TCP 可达 | nc -zv、telnet | 能完成三次握手 | 应用是否会正常响应 |
| UDP 可达 | nc -u、iperf3 -u | 报文发得出去、可能收到回复 | 回包路径是否通（UDP 无握手） |
| 应用可用 | curl、业务命令 | 完整业务链路可用 | 高峰期的表现与容量余量 |
| DNS 正确 | dig +short | 解析结果符合预期 | 目标是否真的可达 |
矩阵化连测
矩阵化连测
ping -c2 -W2 <目标IP> || echo ICMP-FAIL # ICMP 层
nc -zv -w3 <目标IP> 443 || echo TCP-FAIL # TCP 层
dig +short <域名> && echo DNS-OK # 解析层
curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' --connect-timeout 3 <URL> # 应用层
nc -u -w3 <目标IP> <端口> && echo UDP-SENT # UDP：只证明发得出去
ss -tan | grep <目标IP> | head # 本机与目标的连接是否真的建立很多防火墙只放行 ICMP，或只放行某个业务端口：ping 不通但业务正常、ping 通但端口被拦，都是常见组合。任何一层失败都不足以判定「整个网络坏了」，要继续换协议验证。
UDP 没有握手，判读只能依赖业务级回包或 UDP 吞吐测试的丢包统计；DNS 解析正确与目标可达也是两件独立的事，解析成功不代表能连上。