调优worker_connections的核心是匹配系统资源与业务特征，而非盲目提高数值；需先突破文件描述符限制，合理设为4096–16384，搭配use epoll、multi_accept on等参数协同优化，并通过错误日志和/nginx_status验证实效。
调优 events { worker_connections } 的核心，是让单个 worker 进程能稳定、高效地处理更多连接，而不是盲目堆高数值。它必须与系统资源、Nginx 架构和业务特征匹配，否则容易失效甚至引发错误。
先确认并突破系统文件描述符限制
worker_connections 不是独立生效的数字，它直接受 Linux 单进程最大打开文件数（file descriptor, fd）限制。默认值通常只有 1024，若你设了 8192 却不调系统限制，实际就按 1024 生效。
- 检查当前限制：
ulimit -n（查看当前 shell 会话限制）；cat /proc/$(pgrep nginx)/limits | grep "Max open files"（查已运行 worker 进程的实际限制） - 临时提升（测试用）：
ulimit -n 65536，再启动 Nginx - 永久生效：在
/etc/security/limits.conf中添加两行（把nginx替换为实际运行用户，如www-data）：nginx soft nofile 65536nginx hard nofile 65536
并确认/etc/pam.d/common-session包含session required pam_limits.so
合理设置 worker_connections 数值
这个值不是越大越好。每个连接占用几 KB 内存，过高会导致内存压力或上下文切换开销上升。应结合业务类型起步并验证：
- 静态资源服务（图片、JS/CSS）：连接短、复用少，可设 4096–16384
- HTTP/2 或 WebSocket 长连接场景：需预留更多槽位，同时建议调低
keepalive_timeout（如 15–30 秒），避免空闲连接长期占位 - 反向代理后端响应慢：连接会在 Nginx 中等待，更容易耗尽——此时应优化
proxy_timeout和重试策略，而非只加worker_connections - 推荐起点：4096 或 8192；避免一上来就设 65535，除非你已同步调高所有关联限制
配套 events 块关键参数协同
只改 worker_connections 效果有限，必须搭配事件模型和连接接收策略才能释放真实并发能力：
-
use epoll;：Linux 必须显式声明，避免回退到 select/poll（有 1024 硬上限） -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队 -
accept_mutex on;：默认开启，防止多个 worker 同时争抢新连接造成“惊群”，与multi_accept协同工作 -
worker_rlimit_nofile：应在 events 外层主配置中显式设置，且值 ≥worker_processes × worker_connections，这是 Nginx 自身对 fd 上限的强制约束
验证是否真正生效
配置改完不等于调优完成，要通过实际指标判断效果：
- 观察错误日志：出现
accept() failed (24: Too many open files)表明系统 fd 仍不足；出现connect() failed (24: Too many open files)可能是 upstream 连接也耗尽 - 用
ss -s或netstat -an | grep :80 | wc -l查看 ESTABLISHED 连接数趋势 - 启用
ngx_http_stub_status_module，通过/nginx_status实时查看 Active connections、accepts、handled 等关键指标 - 压力测试时关注响应时间拐点和错误率突增点，而非单纯追求连接数峰值
