nginx高并发依赖worker_connections与use epoll协同：必须显式配置use epoll以启用高效事件模型，否则回退select/poll将导致性能断崖；worker_connections需匹配系统fd限制并留余量，配合multi_accept和accept_mutex最大化epoll吞吐。
worker_connections 和 use epoll 不是两个孤立参数，它们共同构成 Nginx 高并发连接处理的底层骨架。真正发挥效能的关键，在于让每个 worker 进程在 epoll 事件驱动模型下，能稳定、高效地管理其声明数量的连接，而不是简单堆高数字。
epoll 是 worker_connections 发挥作用的前提
Linux 下若不显式配置 use epoll，Nginx 可能回退到 select 或 poll 模型——而 select 默认硬限 1024 个文件描述符，poll 虽无硬限但性能随连接数线性衰减。此时即使把 worker_connections 设为 65535，实际连接一过千就会出现延迟飙升或“connection refused”。epoll 则通过就绪队列实现 O(1) 事件通知，支撑单 worker 管理数万连接毫无压力。
- 必须在 nginx.conf 的 events 块中明确写入 use epoll;，不能依赖默认
- 验证是否生效：运行 nginx -t && nginx -V 2>&1 | grep -o epoll，有输出即表示已启用
- 旧内核（低于 2.6）不支持 epoll，需升级或改用 kqueue（BSD）等替代方案
worker_connections 必须与 epoll 的资源消耗特性匹配
epoll 本身不直接限制连接数，但它依赖系统 fd 资源。每个活跃连接至少占用 1 个 socket fd；HTTPS 场景下还额外消耗 SSL session cache、OCSP stapling、证书文件等 fd。因此 worker_connections 不是越大越好，而是要留出安全余量。
- 建议值范围：短连接业务（如 API 网关）设 16384～32768；长连接（如 MQTT 代理）可设 32768～65535
- 单 worker 的实际可用连接 ≈ min(worker_connections, ulimit -n × 0.8)，HTTPS 场景建议按 0.7 系数保守估算
- 若频繁出现 “accept() failed (24: Too many open files)” 错误，说明 fd 耗尽，需同步检查 ulimit、worker_rlimit_nofile 和 file-max
multi_accept + accept_mutex 构成 epoll 的协同加速器
epoll 告诉 worker “有新连接来了”，但如何高效收下这批连接，取决于后续策略。multi_accept 和 accept_mutex 就是专为 epoll 设计的配套机制。
- multi_accept on;：让 worker 在一次 epoll_wait 返回后，循环调用 accept() 直至无新连接可收，避免反复陷入内核态
- accept_mutex on;（默认开启）：防止多个 worker 同时争抢同一组就绪连接，减少“惊群”唤醒开销
- 二者配合，使 epoll 的高吞吐优势真正落地——尤其在突发流量（如秒杀、上报洪峰）时，连接建立延迟可降低 30% 以上
静态资源场景下的轻量级配置参考
纯静态文件服务对连接保持要求低、内存敏感度高，无需追求极致并发。过度调大 worker_connections 反而浪费内存（每连接约 2–4 KB）并增加内核调度负担。
- CPU 4 核服务器：worker_processes auto; → 实际为 4 个 worker
- events 块推荐配置：worker_connections 1024; use epoll; multi_accept on;
- 总理论并发 = 4 × 1024 = 4096，足够支撑万级 QPS 的静态资源分发，且系统 fd 压力极小
