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 解析），避免排查过程自身引入延迟或失败。