linux网络故障排查需按物理层→路由层→端口层→协议层顺序验证，熟练组合使用ping、traceroute/mtr、tcpdump三类工具可快速定位90%以上问题。
Linux网络故障排查不是靠猜，而是按顺序验证每一层：物理连通性 → 路由可达性 → 端口服务性 → 协议行为细节。掌握 ping、traceroute（或 mtr）和 tcpdump 这三类工具的组合用法，能快速定位 90% 以上的常见问题。
第一步：用 ping 验证基础连通性
它是最轻量、最直接的链路探测手段，但需分层测试：
- 先测本地回环：
ping -c 4 127.0.0.1—— 排除本机协议栈异常 - 再测网关：
ping -c 4 $(ip route | awk '/default/ {print $3}')—— 确认局域网出口正常 - 接着测 DNS 可达性：
ping -c 4 8.8.8.8（绕过 DNS）和ping -c 4 baidu.com（依赖 DNS）—— 区分是网络问题还是解析失败
重点关注丢包率（＞5% 异常）和延迟波动（如 min/avg/max 差值过大，说明路径不稳定）。若 baidu.com 不通但 8.8.8.8 通，问题大概率出在 DNS 或域名本身。
第二步：用 traceroute/mtr 定位路径中断点
当 ping 通但业务卡顿或超时，说明数据包可能在某跳被限速、丢弃或响应延迟。traceroute 显示逐跳响应，mtr 则提供持续统计，更实用：
- 基础追踪：
traceroute -n baidu.com（-n禁用反向 DNS，提速且避免干扰） - 推荐替代：
mtr --report-cycles 10 baidu.com—— 输出含丢包率、延迟均值与抖动，一眼识别哪一跳开始异常 - 若某跳全为
*，不一定是故障：可能是中间设备禁 ICMP 回复，也可能是防火墙策略；但若后续跳恢复且延迟陡增，该节点就是瓶颈
注意：某些网络环境（如云厂商内网或企业防火墙后）会屏蔽 ICMP，此时可用 tcptraceroute -p 443 baidu.com 或 besttrace -q 3 baidu.com 尝试 TCP 模式穿透。
第三步：用 tcpdump 抓包分析协议行为
当 ping 和 traceroute 都“看起来正常”，但应用仍连接失败或传输异常，就需要深入协议层。tcpdump 是 Linux 下最可靠的抓包工具：
- 监听指定网卡的 TCP 握手：
tcpdump -i eth0 -nn 'tcp port 80 and host 1.1.1.1' - 只抓 SYN 包看是否发起连接：
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0' - 保存供后续分析：
tcpdump -i eth0 -w debug.pcap port 443，然后用 Wireshark 打开细查重传、RST、零窗口等异常
关键判断点：客户端发了 SYN 是否收到 SYN-ACK？有无大量重传？服务端是否返回 RST？这些在 tcpdump 输出中都有明确标志，比日志更真实可靠。
补充：配合 ss 和 netstat 快速查端口与连接状态
很多“连不上”本质是服务没起来或被拦截：
- 查本机监听端口：
ss -tuln | grep ':80'（比 netstat 更快，推荐） - 查某个端口被谁占用：
ss -tulpn | grep ':3306'（显示进程名和 PID） - 查到 ESTABLISHED 但无数据？可能是应用层阻塞，此时结合
strace -p PID观察系统调用更有效
不复杂但容易忽略：所有命令都建议加 -n（禁用 DNS 解析），避免排查过程自身引入延迟或失败。
