worker_connections 是单个 worker 进程可维持的并发连接数上限，受限于系统文件描述符限制，实际并发能力还受 CPU、内存、事件模型等协同影响，需结合业务场景合理配置。
worker_connections 直接决定单个 worker 进程能同时维持多少连接，它不是“每秒处理请求数”，而是“同时在线连接数上限”。这个值和连接处理效率高度相关，但不等于效率本身——效率还取决于系统资源、事件模型、连接复用策略等协同因素。
worker_connections 的真实作用范围
它限制的是每个 worker 进程可打开的文件描述符（fd）总数，包括：
- 客户端发起的 HTTP/HTTPS 连接（浏览器、App、API 调用）
- 反向代理时与后端服务（如 PHP-FPM、Node.js、上游 API）建立的连接
- 部分长连接场景下的 WebSocket、gRPC 流式连接
注意：一个 keepalive 的 HTTP 连接可能承载多个请求，但它只占用 1 个连接计数；而每次短连接都会经历三次握手 + 四次挥手，实际开销远高于连接数本身。
数值设置不能脱离系统限制
worker_connections 再高，若系统级文件描述符不足，Nginx 启动会失败或运行中报错 “too many open files”。关键检查与调整步骤：
- 查看当前限制：
ulimit -n - 临时提升（仅当前会话）：
ulimit -n 65535 - 永久生效：在
/etc/security/limits.conf中添加* soft nofile 65535* hard nofile 65535 - Nginx 配置中同步声明：
worker_rlimit_nofile 65535;（放在 events 外、http 上层）
与 worker_processes 协同影响吞吐表现
理论最大并发连接 = worker_processes × worker_connections，但实际有效并发受以下制约：
- CPU 核心数：worker 进程过多会导致调度竞争，建议设为 CPU 核心数或其 1–2 倍
- 内存容量：每个连接约消耗 2–4 KB 内存，万级连接需预留数百 MB 内存
- 事件驱动模型：Linux 下必须配
use epoll;，否则高连接数下性能急剧下降 - 连接接受方式：启用
multi_accept on;可让 worker 一次收多个新连接，减少空转等待
典型场景参考值
不追求“越大越好”，按业务特征选合理区间：
- 静态资源服务（CDN/图片站）：worker_connections 8192–16384，配合 keepalive_timeout 15–30s
- API 网关（中等并发）：worker_connections 4096，keepalive_timeout 60–75s，keepalive_requests 1000
- WebSocket 或长连接服务：worker_connections ≥ 10240，同时调大
client_header_timeout和client_body_timeout
