worker_connections 是每个 worker 进程的连接上限，实际并发能力 = worker_processes × worker_connections，但受系统 fd 限制、worker_rlimit_nofile 和 CPU 核数制约，且必须置于 events 块内。
worker_connections 不是“总并发数”，而是每个 worker 进程能同时处理的连接上限。真正决定 Nginx 并发能力的，是它和 worker_processes 的乘积，再叠加系统级资源限制——单独调高这个值，不配套调整，几乎没用。
worker_connections 必须放在 events 块里
它不是全局指令，不能写在 http、server 或 main（顶层）上下文中。Nginx 启动时会直接报错拒绝加载配置。正确位置只有一处：
- 必须嵌套在 events { ... } 块内部
- 常见写法：events { worker_connections 4096; use epoll; }
- 缩进不强制，但块结构必须清晰，否则解析失败
实际并发能力 = worker_processes × worker_connections
这个公式是理论峰值，但受三个硬性制约：
- 系统文件描述符限制：每个连接占用至少 1 个 fd，ulimit -n 必须 ≥ worker_processes × worker_connections
- worker_rlimit_nofile：建议设为与 ulimit -n 一致（如 65535），让 Nginx 明确申请足够 fd 资源
- CPU 核心数匹配：worker_processes 设为 auto 或显式等于 CPU 核数（nproc），避免进程过多争抢或过少闲置
高并发场景下的典型配置组合
仅改 worker_connections 不足以撑起万级并发。需同步落地以下几项：
- 系统层：/etc/security/limits.conf 加 * soft/hard nofile 65535；sysctl 设置 net.core.somaxconn=65535
- Nginx 层：events 块启用 multi_accept on 和 accept_mutex on，减少惊群和连接排队损耗
- 连接复用：keepalive_timeout 设为 30–75s，配合 keepalive_requests 控制单连接请求数，平衡复用与资源释放
反向代理场景要留足连接余量
当 Nginx 作反向代理时，一个客户端请求会占用两个连接：一个连客户端，一个连 upstream。所以实际可用的客户端并发数 ≈ (worker_processes × worker_connections) ÷ 2。若后端服务也走长连接或有重试逻辑，建议按 ÷ 3～÷ 4 估算更稳妥。
