TCP握手超时？老司机教你三步定位问题根源

上周排查一个诡异的网络问题时，我盯着Wireshark里满屏的SYN重传记录直挠头。TCP握手超时这种”经典问题”，在实际排查时却总让人有种无从下手的感觉。今天我就结合这次实战经历，分享一套快速定位问题的排查流程。

第一步：确认超时现象的特征

很多人一看到Connection timeout就急着查防火墙，但先搞清楚超时的具体特征往往能事半功倍。我习惯用这个命令组合快速确认：

# 查看TCP连接状态（注意SYN_SENT状态）
ss -antp | grep SYN
  
# 配合抓包观察SYN重传规律
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0'

有次我发现SYN包每隔1秒重传一次，总共重传5次——这明显是Linux默认配置。但如果看到重传间隔异常（比如3秒才重传），可能暗示着中间设备有问题。

第二步：绘制完整的网络路径

我吃过亏后才明白：光盯着两端机器是没用的。建议画出完整的通信路径：

1. 客户端所在的主机/容器/Pod
2. 客户端的网络命名空间（如果是容器）
3. 宿主机网卡和iptables规则
4. 中间经过的LB/NAT设备
5. 服务端的反向代理（如Nginx）

最近遇到个典型案例：K8s集群里某个服务的SYN包在离开Pod后神秘消失。最后发现是宿主机的iptables规则被某运维工具误删了。

第三步：分段验证关键节点

我常用的验证三板斧：

# 1. 检查本地路由
ip route get 目标IP

# 2. 测试网络层可达性（绕过防火墙）
ping -c 4 目标IP

# 3. 测试传输层连通性（带防火墙检测）
telnet 目标IP 端口
nc -zv 目标IP 端口

有个小技巧：如果telnet能连但应用连不上，大概率是应用层问题；如果telnet直接超时，就要重点排查网络层和传输层。

避坑指南

最后分享几个我踩过的坑：

• SYN Cookie陷阱：服务器开启syncookie后，抓包可能看不到SYN-ACK，但其实连接已建立
• 容器网络盲区：Docker的bridge网络下，tcpdump默认抓不到容器间的通信
• 云厂商的隐形墙：某些云的安全组会静默丢弃SYN包，控制台却显示规则正常

记住，TCP握手问题就像破案，现场痕迹（抓包）和作案路线（网络路径）同样重要。下次遇到超时问题，不妨按这个流程试试看？