tcpdump是网络运维故障应急的首选现场取证工具，而非最后手段；它绕过日志与监控，直接捕获协议层真实流量，将模糊问题转化为可验证的时间线和数据证据，并强调抓包前须明确问题端点、影响范围及协议端口，再选用三类优化命令快速定位连接失败、请求未达或异常中断等典型问题。
tcpdump 在网络运维的故障应急中，不是“最后手段”，而是第一时间该动用的“现场取证工具”。它不依赖服务日志、不等待监控告警确认，直接从网络协议层捕获真实流量，把“连不上”“响应慢”“请求没到”这些模糊描述，变成可验证的时间线和数据证据。
明确目标：先问三个问题再敲命令
抓包前停两秒，避免盲目运行导致海量无效数据：
- 问题发生在哪一端？是客户端发不出请求，还是服务端收不到/不响应？需要在对应机器上抓包
- 影响范围是全局还是局部？是所有用户都失败，还是仅某IP、某区域、某App版本？据此决定是否加 host/src/dst 过滤
- 协议和端口是否确定？HTTP/HTTPS、gRPC、MySQL、Redis？端口是80、443、3306还是自定义？不确定时先抓 tcp + port，再逐步收敛
快速抓包：三类典型命令组合
应急讲究“快而准”，以下命令已按场景优化，复制即用（注意替换接口名和IP/端口）：
-
确认请求是否抵达服务端：
sudo tcpdump -i eth0 -s 0 -w inbound.pcap 'host 10.1.2.3 and port 8080' -
排查TCP连接建立失败：
sudo tcpdump -i eth0 -s 0 -w syn_check.pcap 'tcp[tcpflags] & (tcp-syn) != 0 and port 8080' -
捕获异常重传或RST中断：
sudo tcpdump -i eth0 -s 0 -w error_flow.pcap 'tcp[tcpflags] & (tcp-rst|tcp-fin) != 0 or ip[6:2] > 1400'
关键参数说明：-s 0 确保不截断包内容；-w 直接落盘避免终端刷屏丢失；过滤表达式前置能大幅减少写入量，提升抓包稳定性。
现场初筛：不用Wireshark也能快速判断
应急时未必能立刻导出pcap文件，可在服务器本地用 tcpdump -r 快速查看关键线索：
- 看SYN有没有回SYN-ACK：
tcpdump -r inbound.pcap -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' | head -20 - 查是否有大量重传（Retransmission）：
tcpdump -r inbound.pcap -nn 'tcp[tcpflags] & tcp-push != 0' | grep -i retransmit | wc -l - 确认是否收到RST强制断连：
tcpdump -r inbound.pcap -nn 'tcp[tcpflags] & tcp-rst != 0'
若发现SYN发出但无SYN-ACK、重传数突增、或大量RST包，基本可锁定为防火墙拦截、安全组误配、服务未监听、或中间设备（如SLB、WAF）主动干预。
协同定位：比对两端抓包结果
单点抓包常有盲区。真正高效的做法是同步在客户端和服务端抓包，然后比对时间线：
- 客户端抓到SYN → 服务端没抓到 → 问题在链路前半段（客户端出口、DNS、路由、ACL）
- 客户端抓到SYN、服务端也抓到但没回SYN-ACK → 问题在服务端（端口未监听、进程崩溃、iptables DROP）
- 两端都看到SYN/SYN-ACK，但后续ACK或数据包缺失 → 问题在传输过程（丢包、MTU不匹配、中间设备限速）
比对时用 -tttt 参数输出完整时间戳，误差控制在毫秒级，就能清晰还原故障路径。
