用tcpdump过滤RST报文可高效定位连接异常中断，关键在于结合上下文判断RST来源（本机/对端）与原因（拒连、乱序、超窗、进程强退等），并辅以ss、netstat等命令交叉验证。
直接用 tcpdump 过滤 RST 报文，是定位连接被强行切断最有效的方式。关键不在“能不能抓”，而在于“怎么判断 RST 是谁发的、为什么发”。
快速捕获带 RST 标志的报文
执行以下命令即可实时看到所有含 RST 标志的 TCP 包：
- sudo tcpdump -i any 'tcp[tcpflags] & (tcp-rst) != 0' -nn -vv：监听所有网卡，显示详细信息，不解析主机名和端口名
- 加 -c 20 可限制只抓 20 个，避免刷屏；加 -w rst.pcap 可保存为文件供后续用 Wireshark 分析
- 若只关心某端口（如 8080），可追加条件：and port 8080
区分 RST 的来源和含义
RST 报文本身不带错误码，但它的上下文能说明问题：
- 不带 ACK 的 RST：通常是服务端拒连，比如目标端口没进程监听（SYN 到了无人响应的端口，内核直接回 RST+ACK，但抓包里显示为 RST）
- 带 ACK 的 RST：说明它是对某个具体报文的响应，常见于收到乱序包、超窗口数据或已关闭连接上又来了数据
- 源 IP 是本机：说明是本机内核或本地应用主动发出的 RST，需查本机服务状态或应用日志
- 源 IP 是对端：说明对方终止了连接，要排查对方是否崩溃、重启、防火墙策略变更或设置了 SO_LINGER=0
结合前后报文确认异常模式
单看一个 RST 往往不够，需往前追溯几秒内的通信行为：
- RST 前是否有大量重传（Retransmission）？可能网络丢包严重，导致对方超时断连
- 是否紧接在 FIN 之后？可能是四次挥手未完成就被强制中断（如进程 kill -9）
- 是否有零窗口通告（win 0）后长时间无进展？接收方卡死，发送方最终发 RST 放弃
- 是否出现在 close() 调用后仍有数据到达？说明应用层未等对方确认就退出，内核代为发 RST 清理
辅助验证当前连接状态
抓包同时，用系统命令交叉验证：
- ss -tn state established '( dport = :8080 )'：确认目标端口是否真有 ESTABLISHED 连接（排除“以为连着，其实早就断了”）
- ss -tn state time-wait | head -10：检查是否存在大量 TIME_WAIT，可能端口耗尽导致新连接被 RST
- netstat -s | grep -i "reset"：查看内核统计中 RST 发送/接收总数，判断是否属于偶发还是高频事件
