真实并发能力取决于系统、用户、Nginx三级文件句柄限制的最小值，并需结合连接类型、运行时指标及内存占用综合评估，不能直接套用worker_processes×worker_connections。
理论上限是 worker_processes × worker_connections，但这个数字只是配置层面的起点，不是服务器真能撑住的并发数。它必须通过系统资源、进程限制、Nginx自身配置三层校验，缺一不可。
必须对齐的三个硬性上限
真实可用的最大连接数，取决于以下三者中的最小值：
-
系统级文件句柄总数：由
/proc/sys/fs/file-max控制，建议设为1.3～1.5 × worker_processes × worker_connections，给 TIME_WAIT、日志、SSL 缓存等留余量 -
nginx 进程级 ulimit：查
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，其中Soft Limit必须 ≥worker_connections（注意是单个 worker 进程，不是所有 worker 总和） -
Nginx 配置中的 worker_rlimit_nofile：必须 ≥
worker_connections；例如设了worker_processes 8和worker_connections 8192，那worker_rlimit_nofile至少要 8192，推荐设为 65536 或更高
业务类型决定实际承载力
理论值要按连接行为打折扣，不能直接照搬：
-
短连接型（静态资源、REST API、秒杀页）：连接建立快、关闭快，fd 复用率高，可接近理论值，
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%
别被“65535”误导
端口号上限 65535 是客户端发起连接时的本地端口限制，和服务端并发能力无关。Nginx 作为服务端，连接由四元组 {客户端IP, 客户端端口, 服务端IP, 服务端端口} 唯一标识。IPv4 下仅客户端 IP 就有 2³² 种可能，理论连接空间达 2⁴⁸，远超 65535 —— 真正瓶颈从来不在协议层，而在内存、fd、CPU 和带宽。
