worker_connections需根据系统文件描述符上限（ulimit -n）并按业务类型预留余量计算：短连≤0.9×ulimit、长连≤0.8×ulimit、HTTPS≤0.7×ulimit；再确保worker_rlimit_nofile≥worker_processes×worker_connections，且配套use epoll;、multi_accept on;等events参数。
worker_connections 不是拍脑袋填个大数字，它得算出来——核心是看单个 worker 进程能用多少文件描述符（fd），再结合业务类型留出真实余量。
先确认系统允许的上限
这是硬门槛。每个连接至少占 1 个 fd，Nginx 自身还要开日志、临时文件、SSL 缓存等。别跳过这步：
- 查当前生效值：cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files" —— 看 “Soft Limit” 和 “Hard Limit”
- 这个值由三处共同决定：/etc/security/limits.conf（用户级）、systemd service 的 LimitNOFILE、启动时的 ulimit -n
- 若显示是 1024 或 65536，就按这个数往下推；不是随便改完配置就生效，必须重启 nginx 才能加载新限制
再算出能安全设的 worker_connections
不能直接等于 ulimit -n，得预留 10%～30% 给系统开销：
- 短连接（API、CDN 回源）：建议 ≤ 0.9 × ulimit -n
- 长连接（WebSocket、HTTP/2 上报）：建议 ≤ 0.8 × ulimit -n
- HTTPS 反向代理：建议 ≤ 0.7 × ulimit -n（SSL session cache、OCSP stapling 额外吃 fd）
- 举例：ulimit -n 是 65536，做 HTTPS 服务，65536 × 0.7 ≈ 45875，取整为 40960 或 32768 更稳妥
最后对齐 Nginx 内部声明和总连接能力
光设 worker_connections 没用，还得让 Nginx “知道自己能用多少”，并匹配进程数：
- worker_rlimit_nofile 必须 ≥ worker_processes × worker_connections，推荐设为乘积的 1.2 倍（如 4 核 × 32768 = 131072，就设 144000）
- worker_processes 一般设 auto（等于 CPU 核心数），不建议手动超配；4 核机器配 8 个进程反而可能加剧上下文切换
- 理论最大并发 = worker_processes × worker_connections，但实际活跃连接通常只有它的 60%～80%，压测时重点看 Active connections 和系统负载是否平稳
别漏掉配套参数
只调 worker_connections 是半套操作：
- events 块里加 use epoll;（Linux 必显式写，否则可能 fallback 到 select/poll 的 1024 限制）
- 加 multi_accept on;，让一个 worker 一次收多个连接，应对突发流量
- 内核参数 net.core.somaxconn 建议同步设为 65535，避免监听队列满导致 Connection refused
