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"，若无警告，说明双队列协同通畅
