真正卡住Nginx并发上限的是内核网络栈，必须调优net.core.somaxconn（建议65535或262144）并与其listen backlog对齐，同时配套tcp_max_syn_backlog、tcp_tw_reuse、ulimit及worker_rlimit_nofile等参数协同优化。
直接调高 Nginx 的 worker_processes 和 worker_connections 不等于并发能力真上去了。真正卡住上限的，往往是内核网络栈——连接还没进 Nginx，就在系统层被丢弃或排队超时。优化 net.core.somaxconn 不是“配合”Nginx，而是让它能收得到连接。
必须对齐：somaxconn 与 listen backlog
net.core.somaxconn 是内核为每个监听端口维护的“已完成三次握手、等待 accept”的连接队列最大长度。默认值 128，在千级并发下就会溢出，客户端看到的是 Connection refused 或 SYN 超时，Nginx 日志里却查不到错误。
- 写入
/etc/sysctl.conf并生效：net.core.somaxconn = 65535
内存 ≥16G 可设为262144 - Nginx 配置中必须显式匹配：
listen 80 reuseport backlog=65535;
不写backlog=时，默认仅 511，再高的somaxconn也白设 - 验证是否生效：
sysctl net.core.somaxconn
压测时用netstat -s | grep "listen overflows"查溢出计数，应为 0
补全半连接队列：tcp_max_syn_backlog + tcp_syncookies
当大量 SYN 包突袭（比如秒杀、爬虫、轻量攻击），tcp_max_syn_backlog 决定内核能暂存多少“只发了 SYN、还没完成握手”的请求。它满后，合法连接也会被静默丢弃。
- 设为与
somaxconn同量级：net.ipv4.tcp_max_syn_backlog = 65535 - 配套启用防御机制：
net.ipv4.tcp_syncookies = 1
队列满时自动启用 Cookie 验证，避免硬丢包 - 注意：
tcp_syncookies不影响正常流量，但能兜住突发峰值
释放端口资源：tw_reuse + ip_local_port_range
短连接业务（如 API 网关）容易耗尽本地端口，表现为 connect() failed (99: Cannot assign requested address)。这不是 Nginx 问题，是系统没端口可用了。
- 允许复用 TIME_WAIT 状态的端口：
net.ipv4.tcp_tw_reuse = 1
（注意：tcp_tw_recycle已废弃，勿用） - 扩大可用端口范围：
net.ipv4.ip_local_port_range = 1024 65535 - 若服务端主动发起大量 outbound 连接（如反向代理到多个 upstream），此两项尤为关键
打通资源链路：ulimit、worker_rlimit_nofile、multi_accept
队列调再大，底层文件描述符（fd）不够，照样报 Too many open files。Nginx worker 能打开多少 socket，取决于系统限制和自身配置的双重约束。
- 全局限制：
echo "* soft nofile 65535" >> /etc/security/limits.confecho "* hard nofile 65535" >> /etc/security/limits.conf - Nginx 内部限制：
worker_rlimit_nofile 65535;（放在 events 块外） - 提升单次事件处理效率：
multi_accept on;
让一个 worker 在一次 epoll_wait 返回后尽可能 accept 多个就绪连接，减少调度开销
