要让单个nginx worker进程真正承载更多连接，必须打通系统级ulimit、nginx进程级worker_rlimit_nofile和内核somaxconn三道限制，并配套use epoll、multi_accept on等events优化，否则仅调高worker_connections无效。
要让单个 Nginx worker 进程真正承载更多连接，worker_connections 不能单独调高——它只是“上限标尺”，实际能力由系统文件描述符限制、Nginx 进程级声明和事件模型共同决定。设得再大，若底层资源没放开，就会卡在 accept() failed (24: Too many open files)。
突破单进程连接瓶颈的三道关卡
每个 worker 进程能打开多少连接，取决于三个层层嵌套的限制，必须全部打通：
-
系统级单进程限制（ulimit -n）：Linux 默认为 1024，必须永久提升。编辑
/etc/security/limits.conf，加入（以 nginx 用户为例）：nginx soft nofile 65536nginx hard nofile 65536
注意：systemd 管理的服务还需在/etc/systemd/system/nginx.service中添加LimitNOFILE=65536并执行systemctl daemon-reload -
Nginx 进程级声明（worker_rlimit_nofile）：必须写在
events块外的全局上下文，且值 ≥ 你打算设的worker_connections：worker_rlimit_nofile 65536;
若该值超过 ulimit -Hn，Nginx 启动会失败或静默降级 -
内核网络队列深度（somaxconn）：防止新连接在进入 Nginx 前就被内核丢弃。修改
/etc/sysctl.conf：net.core.somaxconn = 65535
执行sysctl -p生效
合理设置 worker_connections 数值
这个值不是越大越好，需兼顾内存占用、连接类型和系统余量：
- 静态资源或短连接密集型服务（如 API）：可设
16384～65535，但前提是上述三道关卡已调通 - 长连接场景（如 WebSocket、HTTP/2）：连接驻留时间长，建议配合降低
keepalive_timeout（如设为 15–30 秒），避免槽位被空闲连接长期占满 - 内存估算：每个连接约消耗 2–4 KB 内存。8 GB 内存服务器，单 worker 不建议超过
65535；16 GB 可考虑131072，但必须同步调高fs.file-max（建议 ≥ 总连接目标 × 1.3）
配套 events 块关键参数
只改 worker_connections 效果有限，必须搭配事件驱动行为优化：
-
use epoll;：Linux 下必须显式声明，避免回退到有 1024 硬限制的select/poll -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地接收新连接，缓解突发流量排队 -
accept_mutex off;：高并发下（尤其是多 IP + reuseport 场景），关闭该锁可减少争抢，提升吞吐（注意：与reuseport搭配效果更佳）
验证是否真正生效
别只信配置文件，要看运行时真实限制：
- 查任一 worker 进程 PID：
ps -eo pid,comm | grep 'nginx: worker' - 查看其实际打开文件上限：
cat /proc/<pid>/limits | grep "Max open files"</pid>，输出应显示软硬限制均为你设定的数值（如 65536） - 压测时用
ss -s或netstat -ant | grep ESTABLISHED | wc -l观察活跃连接数是否接近理论值（worker_processes × worker_connections） - 持续观察错误日志：
grep "Too many open files" /var/log/nginx/error.log，无报错才说明调优到位
