排查TCP连接中断的核心是抓包定位断开位置、发起方及异常信号，优先在服务端抓包确认请求抵达与响应发出，结合tcpdump双向过滤和Wireshark分析RST、FIN、重传等关键迹象，并交叉验证dmesg与ss状态。
排查 TCP 连接中断，核心是捕获并验证连接生命周期中“断开”发生的具体位置和原因——不是看它有没有断，而是看它怎么断、谁发起的、有没有重传或异常信号。抓包是唯一能还原真实网络行为的方法。
明确抓包位置和目标通信对端
先确认哪两个节点之间发生了中断：比如 client（10.12.3.10:54322）调用 server（10.12.3.20:8080）。优先在 server 端抓包，可确认“请求是否抵达”“响应是否发出”；若怀疑 client 侧异常（如主动断连、NAT 超时），则在 client 侧抓。
- 用 ip a 查清实际走流量的网卡（注意容器环境可能为
cali*、veth*或docker0，别只盯eth0） - 用 ss -tinp | grep :8080 验证服务确实在监听且绑定到正确地址（
0.0.0.0:8080而非127.0.0.1:8080） - 若使用 Istio/Linkerd 等 Service Mesh，应在应用容器内或 Sidecar 容器中抓，而非宿主机网卡
用 tcpdump 抓取完整交互流
命令必须带关键参数，避免信息缺失或干扰：
-
-i 指定网卡：如
eth0或any（多网卡时慎用） - -nn：跳过 DNS 和端口名解析，防止延迟，显示纯 IP+数字端口
- -s 0：捕获完整包（尤其需要看 TCP 标志位、HTTP 头、RST 原因字段）
- -w file.pcap：保存为文件，便于后续分析或多人协作
-
过滤表达式要双向：用
host 10.12.3.10 and port 8080，而非仅src host或dst port，确保抓到 SYN、ACK、RST、FIN 全流程
推荐命令：
sudo tcpdump -i eth0 -nn -s 0 -w conn_drop.pcap host 10.12.3.10 and port 8080
抓包后重点识别四类中断迹象
用 tcpdump -r conn_drop.pcap -nn 快速扫读，或导入 Wireshark 按时间轴逐帧分析：
- 突兀的 RST 包：某一方在未完成数据传输时直接发 RST → 查是否被防火墙拦截、反向代理（Nginx/Envoy）配置了短超时、或服务进程崩溃后内核代为重置
- FIN 后无 ACK 或延迟 ACK：一端发 FIN，另一端迟迟不回 ACK，或 ACK 后再不发自己的 FIN → 对端僵死、线程卡住、或中间设备（如云 LB）静默丢弃 FIN/ACK
- 大量重传 + 最终 RST：同一序列号反复出现重传，最后以 RST 结束 → 网络层严重丢包，或接收方 TCP 缓冲区溢出、CPU 过载无法处理 ACK
- 只有 SYN，无任何响应：client 发 SYN，server 完全无 SYN-ACK → server 防火墙拦截、安全组未放行、服务未监听、或路由不可达
结合系统日志交叉验证
抓包看到现象后，需查内核线索佐证：
- dmesg -T | grep -i "reset\|drop\|oom\|nf_conntrack"：找 “TCP: too many orphaned sockets”、“nf_conntrack: table full” 等关键提示
-
ss -tinp | grep :8080：观察是否存在大量
CLOSE_WAIT（对端已关，本端未 close）或FIN_WAIT2（本端已发 FIN，对端不响应） -
检查 sysctl 参数：如
net.ipv4.tcp_fin_timeout是否过小导致 TIME_WAIT 提前释放，或net.ipv4.tcp_keepalive_time小于 LB 空闲超时引发单向断连
