关键不是把数字设大，而是让worker_connections在系统资源、nginx架构和业务行为间真正跑通；它受单进程文件描述符限制（ulimit -n）硬约束，必须先调高limits.conf和worker_rlimit_nofile，再结合epoll、multi_accept等events参数协同验证生效。

调优 worker_connections 提升单进程并发能力，关键不是把数字设大，而是让这个值在系统资源、Nginx 架构和业务行为之间真正“跑得通”。它定义的是每个 worker 进程能同时管理的连接数，但实际生效受制于底层文件描述符（fd）上限。一旦不匹配，再高的配置也白搭。

必须先突破单进程文件描述符限制

Linux 默认单进程最多打开 1024 个文件，而每个 TCP 连接至少占用 1 个 fd。如果你设了 worker_connections 8192，但 ulimit -n 还是 1024，那实际就按 1024 生效。

• 查当前限制：ulimit -n（会话级），或 cat /proc/$(pgrep nginx)/limits | grep "Max open files"（已运行 worker 进程的实际值）
• 临时生效（测试用）：ulimit -n 65536，再启动 Nginx
• 永久生效：在 /etc/security/limits.conf 中添加（把 nginx 替换为实际运行用户，如 www-data）：
  nginx soft nofile 65536
nginx hard nofile 65536
• 确认 /etc/pam.d/common-session 包含 session required pam_limits.so

合理设置 worker_connections 数值

这个值要结合内存开销、连接模式和硬件来定，不是越大越好。每个连接约占 300–500 字节内存，过高会增加上下文切换压力或触发 OOM。

• 静态资源服务（短连接为主）：4096–8192 足够
• HTTP/2 或 WebSocket 长连接场景：建议 8192–16384，同时调低 keepalive_timeout（如 15–30 秒），避免空闲连接长期占位
• gRPC 流式传输：每个流绑定一个连接，推荐起步 8192；若后端响应慢，优先优化 proxy_read_timeout 和重试策略，而非盲目加连接数
• 避免一上来就设 65535——除非你已同步调高所有关联限制

配套 events 块参数协同生效

只改 worker_connections 效果有限，必须搭配事件模型和连接接收策略才能释放真实并发潜力。

• use epoll;：Linux 必须显式声明，防止回退到 select/poll（有 1024 硬上限）
• multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队
• accept_mutex on;：默认开启，防止多个 worker 同时争抢新连接导致“惊群”；百万级连接可考虑关掉（off），但需配合足够大的 somaxconn
• worker_rlimit_nofile 必须在全局块（http 外）设置，且 ≥ worker_connections，推荐设为相同值或略高（如 1.2 倍）

验证是否真正生效

改完别急着压测，先确认基础就位：

• 重启 Nginx 后执行：ps -eo pid,fdcount,comm | grep nginx，检查 worker 进程的 fdcount 是否接近设定值
• 启用 ngx_http_stub_status_module，访问 /nginx_status 查看 Active connections 实时值，以及 Waiting 是否长期堆积
• 错误日志里不再出现 accept() failed (24: Too many open files)