worker_connections合理上限需按业务类型预留余量计算：短连≤0.9×ulimit、长连≤0.8×ulimit、https≤0.7×ulimit；并确保worker_rlimit_nofile≥worker_processes×worker_connections，且同步调优内核file-max、events参数及运行时监控。
worker_connections 不是拍脑袋填的数字，它的合理上限必须从系统资源出发，结合业务连接特性、Nginx 自身配置和运行时表现综合算出来。核心逻辑是：它受限于单个 worker 进程能打开的文件描述符数（ulimit -n），但不能用满，得留余量；同时要和 worker_processes、worker_rlimit_nofile、内核 file-max 四者对齐，缺一不可。
查清系统级文件描述符硬上限
这是所有计算的起点。Nginx 启动后，每个 worker 进程最多能用多少 fd，由操作系统决定：
- 执行 cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"，看 “Soft Limit” 值——这才是 Nginx 实际生效的上限
- 该值受三处共同影响：/etc/security/limits.conf（用户级）、systemd service 的 LimitNOFILE（若用 systemd）、以及启动时 shell 的 ulimit -n
- 如果显示是 1024 或 65536，就以这个数为基准往下推；改完配置后必须重启 Nginx 才生效
按业务类型预留余量再定值
不能直接把 worker_connections 设成 ulimit -n，因为日志、SSL 缓存、临时文件、上游连接等也要占 fd。推荐按连接类型打折扣：
- 短连接服务（如 API 网关、静态资源、CDN 回源）：≤ 0.9 × ulimit -n，例如 ulimit 是 65536，可设 58982 或更稳妥的 52428
- 长连接服务（如 WebSocket、HTTP/2 上报、直播流）：≤ 0.8 × ulimit -n，连接驻留久、fd 占用稳定，但需防内存累积
- HTTPS 反向代理：≤ 0.7 × ulimit -n，SSL session cache、OCSP stapling、证书读取额外消耗 fd
对齐 Nginx 内部声明与总能力
只设 worker_connections 不够，Nginx 必须“知道自己能用多少”，且整个系统要支撑得住：
- worker_rlimit_nofile 必须 ≥ worker_processes × worker_connections；推荐设为乘积的 1.2 倍（如 4 核 × 32768 = 131072，就设 144000）
- worker_processes 推荐 auto（等于 CPU 逻辑核数），超 16 核建议手动设为 8～12，避免调度开销
- 内核全局限制：cat /proc/sys/fs/file-max 应 ≥ 1.3～1.5 × (worker_processes × worker_connections)，否则大量 TIME_WAIT 或 SSL 缓存会挤占句柄
用运行时指标验证真实承载力
配置再合理，也得靠真实数据说话。上线后重点看这些：
- 启用 stub_status，访问 /nginx_status 查 Active connections；若长期 >90% 理论上限（worker_processes × worker_connections），说明连接池吃紧
- 执行 ss -s | grep "tcp:"，关注 inuse 和 orphans；大量 orphaned sockets 往往意味着异常断连或 TIME_WAIT 回收慢
- 检查 error.log 是否频繁出现 accept() failed (24: Too many open files)——这是 fd 耗尽的铁证
- 观察 Waiting / Active 比例：Waiting 长期 >90%，说明空闲长连接堆积，重点查 fd 和内存是否充足
