连通性测试工具怎么组合
连不通的问题靠工具组合定位，每件工具解决一个层面：先看本机有没有监听，再测目标端口能否连上，然后看链路每一跳的丢包与延迟，最后看应用层返回什么。按层次递进，结论才不会互相矛盾。
基本信息
| 本机监听 | 用 ss 看端口与进程，第一现场 |
|---|---|
| 端口可达 | 用 nc 或 telnet 测 TCP 端口 |
| 链路质量 | 用 mtr 看逐跳丢包与延迟 |
| 应用层 | 用 curl 看状态码与响应头 |
| 抓包 | 用 tcpdump 确认包方向与丢弃点 |
| 原则 | 客户端与服务端两端都要看 |
工具与层次
| 工具 | 回答的问题 | 典型现象 |
|---|---|---|
| ss | 本机是否在监听 | 没有输出说明没监听 |
| nc | 目标端口能否建立连接 | 拒绝与超时含义不同 |
| mtr | 链路在哪一跳开始丢包 | 观察丢包出现的跳数 |
| curl | 应用是否正常响应 | 关注状态码与耗时拆分 |
| tcpdump | 包是否发出与到达 | 判断丢在哪一侧 |
常用命令合集
常用命令合集
ss -lntp | head -n 20 # 本机监听
nc -zv 10.10.0.5 443 # 端口可达性
mtr -r -c 20 10.10.0.5 # 逐跳丢包与延迟
curl -sv https://example.com/health --max-time 5 # 应用层
tcpdump -i eth0 -nn port 443 -c 20 # 抓包确认典型使用场景
- 服务访问不通，需要按层次逐项排除
- 偶发丢包与超时，需要看链路质量
- 应用响应慢，需要拆分连接与响应耗时
- 变更后做连通性验证，确认放行规则生效
云上排查记住两端都要看：客户端与服务端各跑一遍监听与抓包，定位效率会明显提升。
路径上有多层网络设备与策略时，先确认目标端口能否建立连接，再谈应用层问题；层次错位会让结论跑偏。
只测 ping 不测端口会漏判：ICMP 被禁或禁止回显的场景下 ping 不通但 TCP 正常，反之也可能出现。
工具要在两端都有：很多精简镜像里没有 nc 或 mtr，排查容器问题时先用带工具的临时容器跑一遍，比在业务容器里临时装包快得多。
记下每类现象的首选工具能少走弯路：出现拒绝先看监听，出现超时先看策略与链路，响应慢再看应用层耗时，三类现象对应的第一件工具并不相同。