tcp连接中tcpdump能抓到syn但收不到syn-ack，首要排查中间防火墙（尤其是企业级状态防火墙或云安全组）是否静默丢弃syn包——因其可能因策略限制、连接队列满、acl规则或tcp_tw_recycle等内核参数异常导致syn-ack未发出或被拦截。
tcpdump 能抓到 SYN 但收不到 SYN-ACK？先盯住防火墙
中间防火墙（尤其是企业级状态防火墙或云厂商安全组）常默认丢弃“空闲太久”的 TCP 连接上后续的 keepalive 探测包，导致连接被单向切断。现象是：客户端发了 TCP keepalive 包（ACK 标志位置位、无 payload），但服务端没响应，tcpdump 在服务端抓不到该包 —— 它早在防火墙就没了。
这不是内核行为异常，而是防火墙策略主动拦截。排查第一步不是调 /proc/sys/net/ipv4/tcp_keepalive_*，而是确认防火墙是否在 silently drop 探测包：
- 检查 iptables raw 表是否对
ACK包有DROP或REJECT规则：iptables -t raw -vnL PREROUTING - 重点看匹配条件含
--tcp-flags ACK ACK且无 payload（length 0）的规则 - 用
iptables -t raw -A PREROUTING -p tcp --tcp-flags ACK ACK --sport 1024:65535 -m length --length 40 -j LOG --log-prefix "keepalive-dropped: "临时加日志规则，再等探测触发后查/var/log/kern.log
如何让 tcpdump 显式捕获 keepalive 探测包
tcpdump 默认会过滤掉内核认为“无关”的纯 ACK 包（尤其当窗口未变化、无数据时），容易误判为“没发”。必须显式指定过滤条件才能看到真实保活流量：
- 抓本机发出的 keepalive：
tcpdump -i any 'tcp[tcpflags] & (tcp-ack) != 0 and tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) == 0 and tcp len == 0' - 抓对端发来的 keepalive（服务端视角）：
tcpdump -i eth0 'tcp[tcpflags] & (tcp-ack) != 0 and src host CLIENT_IP and tcp len == 0' - 注意：某些网卡 offload 功能（如 TSO/GSO）可能导致抓包看到分段后的 ACK，此时需加
-nn -vvv看原始 flag 和 len 字段
防火墙丢 keepalive 的典型表现与绕过方式
很多防火墙（如 AWS Security Group、阿里云 ECS 安全组、FortiGate 默认策略）对“无业务数据的长连接”极不友好，典型表现是：
- 连接空闲 300–600 秒后，客户端发 keepalive，服务端无响应，
ss -i显示retrans次数上升，最终ESTABLISHED → FIN_WAIT1或直接断开 - 同一连接上 HTTP 请求仍能通（因为带 payload，触发防火墙状态刷新），但纯心跳失败
- 解决不能只靠调大
tcp_keepalive_time（比如设成 60s），因为防火墙超时阈值往往固定且不可配
更实际的做法是应用层主动保活：
- HTTP 场景：强制客户端发
Connection: keep-alive+ 定期发OPTIONS /health等轻量请求（带 payload，能刷新防火墙 conntrack 状态） - TCP 自定义协议：在应用协议里设计 ping/pong 帧（非 TCP 层 keepalive），确保每 240 秒内至少有一个带 payload 的包
- 避免依赖纯内核
TCP keepalive作为唯一保活手段 —— 它太“安静”，防火墙听不见
为什么 netstat/ss 看不到丢包，但连接就是断？
netstat -s | grep -i "segments retransmitted" 或 ss -i 中的 retrans 字段只统计内核重传行为，不反映防火墙侧丢包。如果防火墙在 SYN-ACK 后就不再转发 keepalive 包，服务端根本收不到，自然不会触发重传 —— 它连“对方失联”的判定都来不及做。
真正关键的指标藏在防火墙自身日志或 conntrack 表里：
- 查 conntrack 老化：
conntrack -L | grep "timeout.*established" | head -5，常见值是 432000 秒（5 天），但某些防火墙对“无数据连接”单独设为 300 秒 - 云平台需查控制台里的“连接跟踪超时设置”，不是 Linux 内核参数
- 最狠一招：在客户端和服务端同时抓包比对，若客户端发了 keepalive、服务端没收到，且中间节点（如跳转网关）也无该包 —— 铁证是防火墙拦截
防火墙丢 keepalive 不报错、不返回 RST、不记录 DROP 日志（除非你显式配置了 LOG 规则），它只是静默吞掉。这种“无声丢弃”是最难定位的，也是线上长连接故障里最常被忽略的一环。
