4. 网络故障排查：连通性、延迟、丢包、路由问题、常用命令
网络故障排查，说白了就是一场“有罪推定”。你得默认一定是某个环节断了、慢了或者丢了，然后用工具一个个去验证。我干了十几年运维，抓过最多的不是 bug，而是网络包。你想想看，一个请求往返要经过交换机、路由器、防火墙、负载均衡……中间任何一个环节出问题，用户感知到的就是“网页打不开”或“卡死了”。
这一章，我把自己平时排查的网络“四大件”——连通性、延迟、丢包、路由，连同那几条最常用的命令，掰开揉碎了讲。全是实战里反复用过的手艺。
▲ 网络故障排查知识体系与常用工具
4.1 连通性检查：先别慌，从 ping 开始
遇到网络问题，我习惯先问自己一个问题：“底层通不通？”
别急着分析应用层日志。先用 ping 看看目标 IP 能不能通。
ping 目标IP -c 4。如果通，再看端口和协议。如果不通，直接检查链路和防火墙。
ping 不通的原因，我总结过几个最常见的：
- 线路物理断开： 网线没插紧、光模块故障。我在机房遇到过一例，机柜里网线被理线架顶松了，灯还亮，但就是丢包严重。
- 防火墙/安全组拦截： 默认不允许 ICMP。这种情况最烦人——明明业务端口是通的，就是 ping 不通。
- 路由缺失： 目标网络在路由表里没有条目。用
ip route get重跑一下就能确认。
再看个实战场景：
# 检查到目标 IP 的连通性
ping -c 10 10.0.0.1如果返回 Destination Host Unreachable，说明本地没有路由。如果返回 Request timeout，说明 ICMP 包没回来，可能是防火墙或链路问题。
4.2 延迟分析：RTT 与 RTO，别傻傻分不清
连通性没问题，但用户喊“卡”。那就要看延迟了。
我个人习惯用 ping -c 100 来做长期采样，观察最小、最大、平均 RTT。你想想看，如果平均 RTT 是 2ms，但最大值跳到 500ms，那一定是有抖动。
延迟高的常见原因：
- 链路带宽打满： 比如出口带宽跑到了 95%。延迟会快速升高。
- 设备处理能力瓶颈： 老旧路由器的 CPU 冲到 100%，包排队了。
- 错误的重传： TCP 超时重传导致应用层感觉“卡”。
这里有个我自己的排查流程，做成表格方便你对照：
| 现象 | 可能原因 | 下一步命令 |
|---|---|---|
| RTT 稳定偏高（>100ms） | 物理距离远 / 链路质量差 | traceroute 看每一跳延迟 |
| RTT 忽高忽低（抖动） | 带宽竞争 / 队列拥塞 | iftop 看占用带宽的流量 |
| RTT 正常但业务卡 | 应用层或 TCP 参数问题 | tcpdump 抓握手包 |
4.3 丢包排查：别被表象迷惑
丢包是网络里最隐蔽的问题。有时候丢 1% 的业务包，表现就是“偶尔失败一次”。
我会怎么查？ 用 ping -f 做洪水测试，或者用 mtr 看每一跳的丢包率。
案例： 我记得有次一个金融客户的交易系统频繁超时。用 mtr 跑了几分钟，发现中间一台交换机在晚上 8 点准时丢包 5%。后来一查，是那条链路上的一个网卡固件有 bug，流量大到一定程度就开始丢。换个网卡就好了。
丢包的本质原因：
- 物理层： 光衰过大、网线质量差。用
ethtool看链路状态和错误计数。 - 数据链路层： MAC 地址冲突、ARP 表溢出。
- 网络层： 路由黑洞、TTL 超时。
- 传输层： 连接队列满、重传超时。
帮你记个快捷命令：
# mtr 同时展示连通性和丢包
mtr -r -c 100 10.0.0.1输出里，Loss% 列就是丢包率。如果只有最后一跳丢包，通常是目标主机防火墙拦截了 ICMP。如果中间跳丢包，那问题就在链路上。
4.4 路由问题：凭什么绕路？
路由问题最经典的表现是：“能通，但慢得要死。” 说白了，就是流量走了非最优路径。
我会先用 traceroute 看它实际走了哪些跳。
# 追踪到目标 IP 的路由路径
traceroute -n 172.16.0.1如果发现走了 10 多跳，但实际只有 3 跳的距离，那就是路由选路有问题。常见原因包括：动态路由协议收敛慢、静态路由配置错误、路由策略搞复杂了。
netstat -r 看本机路由表，确认默认网关和目标网络的路由。我遇到过本地配了多条默认路由，结果来回走不同路径，导致间歇性丢包。
路由排错的三个核心检查点：
- 源端路由表： 有没有去往目标的路由？
- 中间设备路由表： 每一跳路由器都有对应路由吗？
- 目标端路由表： 回包路径是否正确？
嗯，这里要注意。很多新手只查去程，不查回程。其实丢包和延迟，多数问题出在回程路径上。不对称路由在复杂网络里非常常见。
4.5 常用命令实战组合
光讲理论没用。我把几条命令的实战用法串一下。你遇到问题时，可以按这个顺序来：
| 顺序 | 命令 | 查什么 | 预期输出 |
|---|---|---|---|
| 1 | ping | 连通性和基础延迟 | 0% loss，RTT 稳定 |
| 2 | traceroute | 路径和每一跳延迟 | 跳数少，RTT 均匀 |
| 3 | netstat -r | 本机路由表 | 路由条目正确 |
| 4 | tcpdump | 抓包看重传和握手 | 无重传，SYN/SYN-ACK 正常 |
举个例子。如果你怀疑 TCP 握手有问题：
# 在客户端抓包
tcpdump -i eth0 -nn host 10.0.0.1 and port 80 -w handshake.pcap然后在 Wireshark 里看三次握手。如果只有 SYN 没有 SYN-ACK，要么是端口没开，要么是被防火墙拦截了。如果有 SYN-ACK 但没有最后的 ACK，可能是客户端连接队列满了。
讲一个真实的事故： 有一年双十一促销，服务器突然大面积连接超时。我抓包发现：客户端发 SYN，服务端回 SYN-ACK，但客户端就是不回最后的 ACK。一查，是因为临时改了一个内核参数 net.ipv4.tcp_max_syn_backlog 改小了，导致半连接队列溢出。调回去立刻恢复。嗯，从那以后我再也不敢在促销前随便改内核参数了。
4.6 避坑总结
最后，我把自己踩过的坑列成几条，你遇到类似情况可以直接对号入座：
- 不要只看 ping： ICMP 不通不等于服务死透了。用
telnet IP 端口验证七层服务。 - 注意 TTL 的影响： traceroute 时如果中间节点禁了 ICMP 超时报文，会显示为 * * *，别误判为断连。
- 抓包要抓对网卡： 很多容器和虚拟化环境，eth0 可能不是业务网卡。用
ip addr确认。 - 检查 ARP 缓存： 路由表对了，但 ARP 如果过期或冲突，也会不通。用
arp -n查看。
网络排查说难不难，说简单也不简单。说白了，就是一层一层往上剥，从物理到应用。你只要把本章这几个命令练熟了，再加上一点点耐心，大部分问题都能自己搞定。