worker_connections必须与系统ulimit -n对齐，否则无效；高频短连接场景易触发“too many open files”，需先调高ulimit（如65536）并配置worker_rlimit_nofile，再结合epoll、multi_accept等events参数协同优化。
worker_connections 不是单独调大的数字，它必须和系统级文件描述符限制（ulimit -n）对齐，否则再高的配置也无效。高频短连接场景下，连接建立快、关闭快，更吃总吞吐能力，也更容易因 fd 耗尽触发 “too many open files” 错误。
先确认并突破系统 ulimit 限制
Linux 默认单进程最多打开 1024 个文件描述符，而 Nginx 每个 worker 进程需要为每个连接分配至少 1 个 fd（还可能额外用于日志、上游等）。若你设了 worker_connections 8192，但 ulimit -n 只有 1024，实际生效值就是 1024。
- 临时生效：启动 Nginx 前执行 ulimit -n 65536（需 root 或对应权限）
- 永久生效：编辑 /etc/security/limits.conf，添加两行（注意把 nginx 替换为实际运行用户，如 www-data）：
nginx soft nofile 65536
nginx hard nofile 65536 - 验证方式：运行 ulimit -n 查当前会话值；或用 cat /proc/$(pgrep nginx)/limits | grep "Max open files" 查已运行 worker 进程的实际限制
合理设置 worker_processes × worker_connections
理论最大并发连接数 = worker_processes × worker_connections，但这只是上限。高频短连接不依赖长连接复用，所以重点是让这个乘积能稳定跑满，而不是堆高单个值。
- 推荐 worker_processes auto，多数物理机或虚拟机适用；容器环境建议显式设为 CPU 可用核数（如 cpus: 2 就设为 2）
- worker_connections 建议从 4096 或 8192 起步，不要一上来就设 65535——需同步确保 worker_rlimit_nofile ≥ 该乘积，且系统 ulimit -n ≥ 同值
- 例如 4 核机器配 auto + 8192，理论支持约 32768 连接，则需保证：
worker_rlimit_nofile 32768;
ulimit -n ≥ 32768（对 nginx 用户）
配套 events 块关键参数协同
只调 worker_connections 不够，还要匹配事件模型和连接接收策略，才能真正释放并发潜力。
- use epoll;：Linux 下必须显式指定，避免回退到低效的 select/poll（有 1024 连接硬限）
- multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量下的排队压力
- accept_mutex on;（默认开启）：防止多个 worker 同时争抢新连接导致“惊群”，与 multi_accept 协同工作
- 禁用 keepalive（keepalive_timeout 0;）可释放连接槽位，适合纯短连接场景；若需保留，建议设为 15–30 秒，避免空闲连接长期占位
验证是否真正生效
调完不能只看配置文件，要观察运行态和压测结果。
- 检查 Nginx 状态页：location /nginx_status { stub_status on; }，关注 Active connections 和 accepts / handled / requests 的比值
- 用 lsof -p $(pgrep nginx) | wc -l 或 ss -s 观察实际打开的 socket 数量
- 配合 ab 或 wrk 做阶梯压测，观察错误率突增点是否与预期并发值吻合；若在远低于理论值时就报错，大概率是 ulimit 或 worker_rlimit_nofile 没对齐
