TCP半连接队列溢出会导致SYN_RECV堆积、新连接缓慢或拒绝，需通过netstat -s检查listen overflows、ss统计syn-recv数量、dmesg查看SYN flooding日志确认；调整tcp_max_syn_backlog、somaxconn、tcp_syncookies参数，并结合反向代理、限速、防火墙等架构优化降低SYN压力。
当Linux系统出现大量SYN_RECV连接、新连接建立缓慢或被拒绝时，大概率是TCP半连接队列（SYN Queue）已满导致的。这不是应用层问题，而是内核网络栈在三次握手第一阶段就丢弃了SYN包，必须从协议栈参数和负载特征两方面入手排查与优化。
确认半连接队列是否溢出
直接查看内核统计信息最可靠：
- 执行 netstat -s | grep -i "listen overflows"，若输出中“listen overflows”或“SYNs to LISTEN sockets dropped”数值持续增长，说明队列已溢出丢包
- 检查当前监听端口的半连接数量：ss -n state syn-recv | wc -l，对比 cat /proc/sys/net/ipv4/tcp_max_syn_backlog（默认值通常为128或根据内存自动计算）
- 配合dmesg观察内核日志：dmesg | grep -i "possible SYN flooding"，该提示表示内核触发了SYN Flood防护机制，常因队列满且未启用syncookies而产生
调整关键内核参数以缓解溢出
参数调整需结合业务并发模型，避免盲目调大：
- tcp_max_syn_backlog：控制每个监听套接字的半连接队列长度。建议设为实际峰值SYN请求数的1.5~2倍，例如突发场景下每秒收到200个SYN，则可设为300～500（需root权限写入 /proc/sys/net/ipv4/tcp_max_syn_backlog）
- net.core.somaxconn：限制所有监听socket的全连接队列（accept queue）上限，但部分内核版本中它也隐式约束半连接队列最大值。应 ≥ tcp_max_syn_backlog，常见设为1024或2048
- net.ipv4.tcp_syncookies：设为1开启SYN Cookie机制。在队列满时临时启用该机制可避免丢包，代价是略微增加CPU开销且不支持部分TCP选项（如SACK）。生产环境建议始终开启
从应用与架构侧降低半连接压力
参数调优只是兜底手段，真正治本需减少无效或慢速SYN请求：
- 前端部署反向代理（如Nginx）并启用连接复用（keepalive），将大量短连接合并为长连接，显著降低后端服务的SYN到达速率
- 检查客户端行为：是否存在扫描器、健康检查过于频繁（如每秒多次TCP探活）、移动端弱网重试风暴等情况；可通过iptables限速初步识别：iptables -A INPUT -p tcp --dport 80 --syn -m limit --limit 10/sec --limit-burst 30 -j ACCEPT
- 对非核心端口关闭监听，或使用防火墙屏蔽非法源IP段，减少无效SYN进入协议栈
验证优化效果与长期监控建议
每次调整后必须实测验证，而非仅看参数生效：
- 使用工具模拟SYN洪峰（如hping3）观察丢包率变化：hping3 -S -p 80 -i u10000 -c 1000 target_ip，再比对前后 listen overflows 增量
- 将 netstat -s 中相关计数器接入Prometheus+Grafana，设置阈值告警（如SYN drop rate > 0.1% 持续1分钟）
- 记录每次变更的时间点与参数值，便于回溯分析性能拐点
