SYN_RECV连接堆积表明服务正承受异常TCP握手压力，主要源于SYN Flood攻击、后端服务响应缓慢或网络设备/客户端异常三类场景，需分层排查并针对性优化。
SYN_RECV 连接堆积说明服务正承受异常 TCP 握手压力
SYN_RECV 状态表示服务器已收到客户端的 SYN 包并回复了 SYN-ACK，但尚未收到对方的 ACK（三次握手未完成）。该状态本应短暂存在，若 ss -ant | grep SYN\_RECV 显示数十甚至上百条记录，通常意味着连接卡在第二步，背后大概率存在异常——不是攻击就是配置或服务问题。
典型场景一：SYN Flood 攻击
攻击者伪造大量不同源 IP 发送 SYN 包，服务器为每个请求分配内存并等待 ACK，但因源地址虚假，ACK 永远不会到达，导致半连接队列（syn queue）快速占满。此时真正用户的连接可能被丢弃，表现为服务不可用或响应极慢。
- 确认方式：netstat -s | grep -i "SYNs to LISTEN" 查看“SYNs to LISTEN sockets dropped”是否持续增长；同时观察源 IP 高度离散、无规律、TTL 异常
- 缓解建议：启用内核防护（net.ipv4.tcp_syncookies = 1），限制半连接队列长度（net.ipv4.tcp_max_syn_backlog），配合 iptables 或 nftables 限速/封禁异常源段
- 注意：syncookies 在高并发下可能影响部分合法连接（如带时间戳选项的连接），建议作为应急手段而非长期依赖
典型场景二：后端服务响应缓慢或崩溃
应用进程忙于处理旧请求、卡死、GC 停顿过长，或 accept() 调用被阻塞（例如监听套接字未设非阻塞、accept 队列溢出），会导致已完成三次握手的连接无法及时从 syn queue 移入 accept queue，使得连接长时间滞留在 SYN_RECV 状态（实际是内核认为“已握手完成”，但用户态没取走）。
- 确认方式：检查对应端口的应用进程 CPU/内存/线程数；用 ss -lnt 查看 Recv-Q 是否持续非零（即 accept queue 拥塞）；strace -p 进程 PID 观察是否卡在 accept() 系统调用
- 缓解建议：优化应用逻辑（避免同步阻塞 I/O）、增加 worker 进程/线程、调整 net.core.somaxconn 和应用 listen() 的 backlog 参数（需两者匹配）
- 补充：某些语言运行时（如早期 Node.js、Golang net/http 默认配置）默认 backlog 较小，易成瓶颈
典型场景三：网络中间设备干扰或客户端异常
防火墙、NAT 设备策略不当（如拦截 ACK 或修改 TTL 导致包丢失）、客户端网络不稳定（无线断连、移动网络切换）、或客户端协议栈缺陷（如未重传 ACK、发送 ACK 后立即断电），都可能导致服务器发出去的 SYN-ACK “石沉大海”。
- 确认方式：抓包分析（tcpdump -i any port XXXX and 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0'），重点比对服务器发出的 SYN-ACK 是否有对应 ACK 回来；检查客户端侧日志或网络质量
- 缓解建议：缩短半连接超时时间（net.ipv4.tcp_synack_retries 默认 5 次，可减至 2~3）加快资源回收；对可信内网服务，可关闭 syncookies 降低开销
- 注意：公网服务需谨慎调低 retries，避免误伤弱网用户；企业内网可结合客户端健康检查做主动剔除
排查与清理的基本思路
不要直接 kill 进程或重启服务。先定位源头：用 ss -ant state syn-recv sport = :端口号 锁定具体端口；再结合 ss -tunap 查归属进程；然后分层验证——网络层（丢包？路由？）、传输层（参数是否合理？）、应用层（进程是否存活？负载是否过高？）。
- 临时清理：SYN_RECV 是内核维护的状态，无法手动清除；唯一办法是让超时自动释放（默认约 1~2 分钟），或通过调小 tcp_synack_retries 加速
- 监控建议：将 ss -ant | grep -c SYN\_RECV 加入基础监控项，阈值设为 5~10（视业务规模而定），触发告警后联动查看应用指标和网络指标
- 预防关键点：合理设置内核参数、应用做好连接管理、关键服务前置四层负载均衡（自带 SYN proxy 能有效隔离攻击）
