worker_connections是单个worker进程最大并发连接数，实际生效需满足ulimit -n ≥ worker_connections、worker_rlimit_nofile ≥ worker_connections，并协同epoll、multi_accept等events参数优化。
worker_connections 不是并发能力的“开关”，而是单个 worker 进程能同时管理的连接上限。它必须和系统资源、Nginx 运行机制、业务连接模式三者咬合，才能真正释放高并发潜力。
它到底管什么？
worker_connections 是每个 worker 进程最多能打开的文件描述符（fd）数量。这些 fd 既用于客户端连接，也用于 upstream 连接（比如 proxy_pass 到后端服务）、日志句柄等。一个短连接请求可能只占 1 个 fd，但一个反向代理请求通常至少占用 2 个（客户端 + 后端），某些场景下还可能更多（如重试、负载均衡多选）。
- 它不等于全站并发请求数——HTTP/1.1 keepalive 下，一个连接可处理多个请求
- 它也不等于 QPS，QPS 还受后端响应时间、网络延迟、CPU 和内存限制影响
- 它的实际生效值，永远受限于系统 ulimit -n，且不能超过 worker_rlimit_nofile 设置
为什么调高了还是报 “too many open files”？
因为 Nginx 启动时会按 worker_processes × worker_connections 预估所需 fd 总量，但操作系统不会自动给它开这么多。如果系统级限制没放开，Nginx 就会降级使用或直接失败。
- 先查当前限制：cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"
- 永久修改：/etc/security/limits.conf 中为 nginx 运行用户（如 www-data）添加两行：
www-data soft nofile 65536
www-data hard nofile 65536 - 确保 PAM 加载：检查 /etc/pam.d/common-session 是否含 session required pam_limits.so
- 重启 Nginx 或重新登录用户会话使配置生效
怎么配才真正撑得住瞬时高峰？
高频短连接（如秒杀、轮询 API）对连接吞吐率要求高，但连接生命周期极短。此时重点不是“保持多少连接”，而是“单位时间内能新建并释放多少连接”。需要协同调整：
- worker_rlimit_nofile 必须显式设置，推荐 ≥ worker_connections（不是总乘积），例如设为 65536
- use epoll; 显式指定 Linux 高效事件模型，避免回退到 select/poll 的 1024 硬限
- multi_accept on; 让 worker 在一次 epoll 循环中尽可能多地 accept 新连接，缓解突发排队
- keepalive_timeout 0; 强制关闭长连接，快速释放连接槽位（若业务确实无复用需求）
- accept_mutex on; 默认开启即可，防止惊群，不必盲目关闭
别忘了内核和网络层配合
Nginx 只是应用层，真正的连接入口在内核。如果 TCP 全连接队列（somaxconn）太小，连接在握手完成前就被丢弃；如果 TIME_WAIT 太多，端口耗尽，新连接就建不起来。
- 调整 /proc/sys/net/core/somaxconn 至 ≥ 65535
- 启用 net.ipv4.tcp_tw_reuse = 1，允许复用处于 TIME_WAIT 的端口
- 扩大临时端口范围：net.ipv4.ip_local_port_range = 1024 65000
- 监听指令可加 listen 80 backlog=4096;，与 somaxconn 对齐
