说明：本文根据当前常用工具重新整理，侧重故障定位方法，不再保留旧文中的工具罗列。
Linux 网络故障最容易被“工具越用越多”带偏。更有效的办法，是先判断问题位于哪一层，再选择能够验证假设的命令。下面是一套适合日常运维的最小排查路径。
一、先确定故障边界
- 只有一个进程异常，还是整台主机都无法通信？
- 只有一个目标地址异常，还是同网段、跨网段都异常？
- 故障发生在域名解析、建立连接、TLS 握手，还是应用响应阶段？
- 问题是否与近期的防火墙、路由、容器网络或发布变更有关？
先回答这些问题，可以避免一开始就抓取大量数据，却不知道要寻找什么。
二、从接口和路由开始
ip -br address
ip -s link
ip route
ip route get 目标IP这里主要确认接口是否启用、地址是否正确、收发错误是否持续增长，以及访问目标时实际选择了哪个出口和下一跳。多网卡、策略路由或容器环境中，最后一项尤其重要。
三、检查监听端口和连接状态
ss -lntup
ss -s
ss -ant state established
ss -ant state time-waitss 可以用来确认服务是否监听在预期地址、连接是否成功建立，以及是否存在异常堆积。发现大量连接时，还要结合应用日志、反向代理日志和系统资源判断，不能仅凭连接数量下结论。
四、按需验证 DNS 和路径
getent hosts example.com
dig example.com
ping -c 4 目标IP
traceroute 目标IP
mtr -rw 目标IP域名能否解析、目标是否响应 ICMP、路径中间节点是否回包，是三个不同问题。部分设备会限制 ICMP，因此一次 ping 失败并不能直接证明业务不可达。
五、最后才抓包
tcpdump -ni any host 目标IP
tcpdump -ni any port 443
tcpdump -ni any -w /tmp/network-check.pcap host 目标IP抓包前应先限定主机、端口和时间范围，并注意数据包可能包含账号、令牌或业务数据。生产环境中的抓包文件需要控制权限，分析完成后及时清理。
六、形成可复核的排障记录
一次完整记录至少包括：故障时间、影响范围、源和目标、执行过的检查、关键输出、近期变更、最终原因和恢复措施。工具只是取证手段，真正能降低重复故障的是可复核的过程。