第四章 网络故障排查：ping/traceroute/nslookup/tcpdump 实战手册
网络出问题，最怕的就是 “不知道哪里断了”。
你ping不通应用，是底层链路断了？防火墙拦了？还是域名没解出来？我干了这么多年运维，发现八成以上的故障其实用四个工具就能定位：ping、traceroute、nslookup 和 tcpdump。
这章我们不谈玄学，只讲怎么用它们一步步把问题掐死。
1. ping – 最朴素的连通性探针
ping 用的是 ICMP Echo Request/Reply。它只告诉你一件事：对端主机是否活着，以及 RTT 有多长。
| 常用参数 | 作用 |
|---|---|
-c 5 | 发送 5 个包后停止 |
-i 0.2 | 间隔 0.2 秒发包（快速检测用） |
-s 1472 | 指定数据包大小（绕过 MTU 测试） |
-M do | 禁止分片，用于 MTU 探测 |
我的一个习惯：先 ping 网关确认本地链路，再 ping 远端 IP。一步到位跳太远反而不好排查。
有一次线上服务间歇性超时，我加上了 -i 0.2 连续 ping 了 200 个包，发现每第 5 个包就掉 1% 的丢包率。果然，是交换机的出接口队列满了。
避坑关键：如果 ping 不通，先检查本机防火墙是不是把 ICMP 禁了。很多云主机的安全组默认只放行 TCP，ICMP 是关着的。
2. traceroute – 把路径上的每一跳揪出来
traceroute 利用了 TTL（跳数限制）。每次发一个包，TTL 从 1 开始递增，路由器收到 TTL=0 就会回 ICMP Time Exceeded。这样每一跳的 IP 和延迟就全暴露了。
我记得有一次跨地区访问很慢，用 traceroute 看到第 5 跳延迟从 10ms 跳到了 300ms，直接定位到某运营商的互联点 —— 跟网络组吵架都有了铁证。
注意：很多节点会配置不响应 ICMP 超时报文，这时 traceroute 会显示 * * *。别慌，这不一定代表链路断了，可能是路由器主动丢弃了探测包。
我习惯一次跑两条：traceroute -n（直接显示 IP，不反解域名）和 traceroute -I（用 ICMP 而非 UDP，穿透性更好）。
3. nslookup & dig – DNS 解码器
网络通了但应用报错 “域名解析失败”？先别怀疑业务代码，用 nslookup 敲一敲。
nslookup 有两种模式：交互模式和非交互模式。我平时用非交互的快速查询：
nslookup api.example.com 8.8.8.8上面这条指定了 8.8.8.8 作为 DNS 服务器，能绕开本机的 resolver 缓存，直接看到权威的解析结果。
如果 nslookup 给出的结果跟你预期不符，比如 CNAME 没展开、TTL 值异常，那就是 DNS 记录配置出了问题。我曾经碰到过 CNAME 链里有死循环，导致解析超时，业务大面积挂掉。
要用更多细节，我推荐 dig +trace api.example.com，它能展示完整的递归过程。哪一级权威服务器响应慢，一目了然。
4. tcpdump – 网络侦探
前面的工具都是“黑盒”，tcpdump 能让你看到裸的报文。说白了，它就是网络界的 Wireshark 命令行版。
常用的套路：
# 抓取 eth0 上发往 10.0.0.5 的 80 端口包，只抓前 3 个
tcpdump -i eth0 host 10.0.0.5 and port 80 -c 3 -nn-i eth0：指定网卡-nn：不反解主机名和端口名（更快更清晰）-c 3：抓到 3 个包就停-X：打印十六进制及 ASCII，查应用层数据时很好用
我遇到过最经典的场景：两台机器 ping 通但业务连不上。TCP 三次握手花了 5 秒才完成，抓包一看，客户端发了 SYN，服务器回了 SYN-ACK，但客户端没回 ACK —— 查到最后发现客户端的 tcp_tw_reuse 和 tcp_tw_recycle 内核参数在 NAT 环境下冲突了。
生产环境用 tcpdump 要节制。-s 0 会抓满整个包（默认 65535 字节），流量大的时候磁盘瞬间写爆。我一般用 -s 128 抓头部，够看 TCP 头就行。
5. 综合排查流程：一次真实案例复盘
有一次同事反馈 “网站加载非常慢，有时候直接白屏”。按照步骤来：
- ping 域名：显示能解析到 IP，延迟 200ms，正常。
- traceroute：路径没问题，没有突然增大的跳。
- nslookup：域名解析 OK，但 TTL 只剩 10 秒 —— 太短了，导致客户端频繁递归查询。
- tcpdump：在应用服务器上抓包，发现 70% 的请求都被重传了。
最后定位到原因：后端 DNS 记录 TTL 设为 10 秒，DNS 解析服务器负载过高，偶尔超时。客户端等不到解析结果，重试又把服务器压垮了。
解决方案很简单：把 TTL 改成 300 秒，问题迎刃而解。
6. 工具对比速查表
| 工具 | 用途 | 协议 | OSI 层 | 典型场景 |
|---|---|---|---|---|
| ping | 连通性 + 延迟 + 丢包 | ICMP | 网络层 (L3) | 判断主机是否在线 |
| traceroute | 路径追踪 + 逐跳延迟 | UDP/ICMP | 网络层 (L3) | 定位链路瓶颈 |
| nslookup | DNS 解析查询 | TCP/UDP 53 | 应用层 (L7) | 域名无法解析 / 记录错误 |
| tcpdump | 全流量抓包分析 | 任意 | L2~L7 | TCP 重传 / 丢包 / 协议异常 |
7. 知识体系：工具对应故障层次
这张图把四个工具按 OSI 层次摆开了。你回想一下刚才的案例：DNS 解析失败 → 应用层，抓包确认重传 → 传输层。每次故障排查，先判断问题出在哪一层，再去拿对应的工具，才不会像无头苍蝇。
8. 一些零散但管用的经验
- ping 不通先用
arping看看链路层能不能通，我经常用这招绕开 IP 问题。 - traceroute 碰到
* * *时试试-T（TCP SYN 模式），很多网络只放行 TCP。 - nslookup 的时候记得检查
server设置，我曾经因为本地配置了错误的 DNS 服务器，查了半天都以为是远端问题。 - tcpdump 配合
tcpstat或tshark做后分析，比肉眼盯着屏幕强百倍。
一句话总结：先分层，再选工具，最后看数据。 别一上来就抓包，先 ping 一下，不过三秒就知道网络层有没有死。