worker_connections必须与系统文件描述符限制、Nginx进程级限制及业务连接模式严格匹配：单连接实际耗1.5～2.5个fd，需对齐ulimit -n、worker_rlimit_nofile和/proc/sys/fs/file-max三层上限，并按业务类型预留30%～40%余量。
worker_connections 不是随便填个数字就能用的参数，它背后对应的是实实在在的文件描述符（fd）消耗。科学计算 fd 需求，关键在于理清“谁在用 fd”和“每层限制在哪”，而不是直接套公式。
明确每个连接实际占用多少 fd
一个活跃的客户端连接，通常不止占 1 个 fd：
- 客户端 socket 至少 1 个 fd
- 如果启用了 upstream 代理，每个后端连接再加 1 个 fd（HTTP/1.1 默认不复用时更明显）
- SSL/TLS 握手、会话缓存、OCSP stapling 等会额外开 fd
- 日志文件句柄（access_log、error_log）、临时文件、shared memory zone（如 limit_req、ssl_session_cache）也持续占用 fd
所以单个活跃连接平均消耗 1.5～2.5 个 fd 更贴近真实场景，短连接服务偏下限，HTTPS + 长连接 + 多 upstream 场景偏上限。
三层 fd 限制必须全部对齐
实际能撑住的并发连接数，由以下三者的最小值决定：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 系统级总上限：/proc/sys/fs/file-max，建议设为 worker_processes × worker_connections × 1.3～1.5，预留 TIME_WAIT、SSL 缓存、监控 agent 等开销
- 用户级进程上限：ulimit -n（即 nginx worker 进程能打开的最大 fd 数），可通过 /etc/security/limits.conf 或 systemd LimitNOFILE 设置；worker_connections 必须 ≤ 这个值
- Nginx 主动声明上限：worker_rlimit_nofile，必须显式配置且 ≥ worker_connections × 2（保守建议 × 2.5），否则 Nginx 启动时会静默截断或警告
例如：8 核机器设 worker_processes auto、worker_connections 32768，则 ulimit -n 和 worker_rlimit_nofile 均需 ≥ 65536，file-max 建议 ≥ 100000。
查当前生效值，别信配置文件里的数字
配置写得再全，没生效等于白搭。上线前务必验证：
- 查 worker 进程实际限制：cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"
- 查系统全局上限：cat /proc/sys/fs/file-max
- 查 Nginx 是否加载了 worker_rlimit_nofile：nginx -t 会提示 warning，或看 error.log 启动日志
- 压测中观察是否报 "accept() failed (24: Too many open files)"——这是最直接的信号
按业务类型留合理余量
worker_connections 不建议顶格设到 ulimit -n，要为非连接类 fd 留空间：
- 常规 HTTP 服务：设为 ulimit -n 的 70%～80%
- HTTPS + HTTP/2 + 多 upstream 网关：建议 60%～70%，因 SSL 缓存、ALPN、HPACK 解压等隐性开销更大
- 若机器还跑日志采集（Filebeat）、指标上报（Prometheus exporter）等，余量再加 5%～10%
比如 ulimit -n 是 65536，纯 HTTP 可设 worker_connections 52428；如果是 API 网关，建议设 45000 并配好 upstream keepalive 32。
