somaxconn是全连接队列上限关键卡点,控制已完成三次握手但未accept的连接数,溢出导致syn-ack被内核静默丢弃,连接无法进入nginx事件循环;需与tcp_max_syn_backlog、nginx backlog及syn cookies协同调优。

单调大 somaxconn 不能防 SYN Flood,必须和 tcp_max_syn_backlog、Nginx listen backlog、SYN Cookies 及事件模型联动,否则队列卡点前移或后移,防护形同虚设。
为什么 somaxconn 是关键卡点之一
SYN Flood 攻击会快速填满两个队列:前端的「半连接队列」(SYN_RECV)和后端的「全连接队列」(已完成三次握手、等待 accept)。somaxconn 控制后者上限。一旦溢出,内核静默丢弃新到达的 SYN-ACK,客户端表现为 Connection refused 或反复超时重试——此时连接根本没进 Nginx 的事件循环,worker 进程再强也无用。
默认值 128 在千级并发下即告失守;静态资源或 CDN 回源高峰等短连接密集场景,极易触发队列打满。
三参数必须严格对齐
这三个值不匹配,调优就白做:
-
net.core.somaxconn:系统级全连接队列上限,建议设为 65535(常规)或 262144(16GB+ 内存、百万连接目标) -
net.ipv4.tcp_max_syn_backlog:半连接队列上限,建议 ≥somaxconn,例如设为 262144 - Nginx
listen中的backlog参数:如listen 80 backlog=262144;,必须显式声明且不小于内核值;未配置时旧版 Nginx 默认截断为 511
三者生效依赖监听 socket 初始化时一次性分配,运行中不伸缩,改完需重载 Nginx 配置。
配套加固 TCP 栈与事件处理
仅扩队列不够,还需堵住其他丢包环节:
- 启用
net.ipv4.tcp_syncookies = 1:队列满时自动启用 Cookie 验证,抵御纯 SYN 洪水 - 降低
net.ipv4.tcp_synack_retries = 3:减少无效重传,加快异常连接释放 - 在
events块中开启multi_accept on;:让每个 epoll 事件循环尽可能多地从全连接队列中取走连接,避免积压 - 增大
net.core.netdev_max_backlog = 5000:防止网卡收包过快导致底层丢包,影响上层队列吞吐
验证是否真正生效
别只看配置,要实测确认:
- 运行
ss -lnt,检查Recv-Q是否长期低于你设的 backlog 值(接近即说明仍可能溢出) - 执行
netstat -s | grep -i "listen\|overflow",关注ListenOverflows和ListenDrops计数是否归零或稳定不增 - 查内核日志:
dmesg | grep -i "syn.*flood\|somaxconn",若无警告,说明双队列协同通畅











