真正限制 nginx 并发连接能力的是内核 net.core.somaxconn 与 nginx listen backlog 未对齐导致的全连接队列溢出；需将两者均设为 65535（或更高），并同步调优 tcp_max_syn_backlog、netdev_max_backlog、file-max 及 tcp_tw_reuse 等参数，验证 listen overflows 为 0 且 ss -lnt 中 send-q 匹配设置值。
真正限制 Nginx 并发连接能力的，往往不是配置里的 worker_connections，而是系统内核的连接队列容量。其中 net.core.somaxconn 是最关键的一环——它决定了每个监听端口能暂存多少“已完成三次握手、等待被 Nginx 接收”的连接。默认值仅 128，稍有并发压力就会溢出，客户端表现为 Connection refused 或 SYN 超时，而 Nginx 日志里却查不到任何错误。
必须对齐 somaxconn 与 Nginx listen backlog
内核实际生效的全连接队列长度 = min(net.core.somaxconn, Nginx listen backlog)。只调高内核参数却不改 Nginx 配置，等于白做。
- 在
/etc/sysctl.conf中写入：net.core.somaxconn = 65535
内存 ≥16GB 可设为262144或524288 - 在 Nginx 的
server{}块中显式声明：listen 80 reuseport backlog=65535;listen 443 ssl reuseport backlog=65535; - 验证是否生效：
sysctl net.core.somaxconn查内核值ss -lnt | grep ':80'看 Send-Q 列是否匹配设置值
补全半连接队列：tcp_max_syn_backlog + syncookies
当大量客户端同时发起连接（如秒杀、爬虫），SYN 包会先堆积在“半连接队列”。这个队列满后，合法请求也会被静默丢弃。
- 设为与
somaxconn同量级或略高：net.ipv4.tcp_max_syn_backlog = 65535 - 启用防御机制：
net.ipv4.tcp_syncookies = 1
队列满时自动启用 Cookie 验证，不干扰正常流量，但能兜住突发峰值
同步加固 TCP 全链路缓冲环节
accept 队列只是最后一关，前面还有三道关键缓冲区可能先卡死：
-
net.core.netdev_max_backlog = 262144：网卡软中断收包队列，防突发流量在进协议栈前就被丢弃 -
fs.file-max = 2097152且配合ulimit -n设置：
在/etc/security/limits.conf中加：* soft nofile 1048576* hard nofile 1048576
确保系统文件描述符足够支撑所有 worker 进程 -
net.ipv4.tcp_tw_reuse = 1：允许复用处于 TIME-WAIT 状态的套接字（需tcp_timestamps=1，现代内核默认开启）
压测与验证要点
调优后务必验证效果，不能只看配置是否写上：
- 检查溢出计数：
netstat -s | grep "listen overflows"—— 应为 0 - 确认 Nginx 进程实际打开数上限：
cat /proc/$(pidof nginx)/limits | grep "Max open files" - 观察连接状态分布：
ss -s关注estab（已建立）、tw（TIME-WAIT）等数值是否合理增长
