真实并发能力取决于系统、用户、nginx三级文件句柄限制的最小值，并需结合连接类型（短/长连接、https）、运行时指标（active connections、ss统计、错误日志）及内存占用（20–1000kb/连接）综合评估。
真实容量不是简单相乘就能用的数字，它必须经过系统资源、连接模型和运行状态三重校验。直接拿 worker_processes × worker_connections 当并发能力上限，容易在压测或高峰时突然失败。
必须对齐的三层资源上限
这三项中最小的那个，才是你真正能用的连接总数：
-
系统级：内核允许的最大文件句柄数（
/proc/sys/fs/file-max），建议 ≥ 1.3～1.5 ×worker_processes × worker_connections，为 TIME_WAIT、日志、SSL 缓存等留余量 -
用户级：nginx 进程实际生效的 ulimit -n（查
/proc/$(pgrep nginx)/limits），必须 ≥worker_connections（注意是单进程，不是总和） -
Nginx 级：配置中的
worker_rlimit_nofile必须 ≥worker_connections；若设了worker_processes 8、worker_connections 8192，那它至少得是 8192，推荐设为 65536 或更高
按业务类型打折扣估算
理论值要结合连接生命周期打折，不能照搬：
-
短连接型（静态资源、API 接口、秒杀页）：连接快速建立又关闭，实际承载力接近理论值，可设
worker_connections 4096–16384 -
长连接型（WebSocket、HTTP/2 上报、直播信令）：连接长期驻留，fd 和内存占用稳定但总量大，建议
2048–8192，并配合keepalive_timeout 15–30控制空闲时长 -
HTTPS 反向代理：除 socket 外还要开 SSL session cache、OCSP stapling 等额外 fd，
worker_connections建议不超过单进程 ulimit 的 80%
靠运行时指标反推是否够用
配置再合理，也得看真实数据说话：
- 启用
stub_status，访问/nginx_status查 Active connections：若长期 > 80% ×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 是否充足，而非盲目调高
worker_connections
别忘了内存这个隐形天花板
每个连接实际占多少内存，差别极大：
- 纯静态服务：约 20–50 KB/连接
- 启用 HTTPS：约 100–250 KB/连接
- 反向代理 + 默认 buffer：约 300–600 KB/连接
- 若启用了大 header buffer 或自定义缓冲区，单连接可能突破 1 MB
比如一台 8 GB 内存服务器，Nginx 可用约 6 GB，若平均连接占 400 KB，则理论最大连接数 ≈ 15,360；若 worker_processes 设为 4，那 worker_connections 就该控制在 3840 左右，取整为 4096 更稳妥。
