worker_connections必须与ulimit -n对齐，否则无效；高频短连接易触发“too many open files”，需同步调高ulimit、worker_rlimit_nofile，并配置epoll、multi_accept等events参数协同优化。
worker_connections 不是单独调大的数字，它必须和系统级文件描述符限制（ulimit -n）对齐，否则再高的配置也无效。高频短连接场景下，连接建立快、关闭快，更吃总吞吐能力，也更容易因 fd 耗尽触发 “too many open files” 错误。
先突破单进程文件描述符上限
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 进程的实际限制
同步设置 Nginx 进程级句柄上限
仅靠系统 limits 不够，Nginx 主配置中还需显式声明进程能申请的文件描述符上限：
- 在 nginx.conf 的主上下文（http 块之外）添加：worker_rlimit_nofile 65536;
- 该值应 ≥ worker_connections，推荐设为相同数值或略高（如 1.2 倍），确保 Nginx 有足够余量处理日志、上游连接等额外开销
匹配硬件与业务特征设值
数值不是越大越好，要结合 CPU 核心数、内存和业务连接模式来定：
- 推荐起步值：4096 或 8192；API 或短连接密集型服务可设 16384～65535
- worker_processes 建议设为 auto（多数物理机/虚拟机适用），容器环境建议显式设为可用 CPU 核数（如 cpus: 2 就设为 2）
- 理论最大并发数 = worker_processes × worker_connections，例如 4 核机器配 auto + 8192 → 约 32768 连接，此时需保证 ulimit -n ≥ 32768 且 worker_rlimit_nofile ≥ 32768
配套 events 块关键参数协同
只调 worker_connections 不够，还要匹配事件模型和连接接收策略，才能真正释放并发潜力：
- use epoll;：Linux 下必须显式指定，避免回退到低效的 select/poll（有 1024 连接硬限）
- multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量下的排队压力
- accept_mutex on;（默认开启）：防止多个 worker 同时争抢新连接导致“惊群”，与 multi_accept 协同工作
