worker_connections是配置参数而非实时指标，单看无意义；理论最大并发数=worker_processes×worker_connections，但必须同时满足ulimit -n、worker_rlimit_nofile和/proc/sys/fs/file-max三重约束，并结合业务类型（短/长连接、HTTPS代理）及运行时指标（Active connections、ss -s、error.log）动态评估真实承载力。
worker_connections 本身不是实时指标，而是配置参数；容量预估的关键，是把它和系统资源、业务行为、运行时状态三者联动起来看——单看这个数字毫无意义。
先算理论上限，再验证是否“跑得通”
理论最大并发连接数 = worker_processes × worker_connections。比如 4 个 worker 进程 × 每个支持 8192 连接，理论值是 32768。
但这只是纸面数字，必须同时满足三个硬条件才能成立：
- 每个 Nginx worker 进程的 ulimit -n ≥ 该乘积（查 cat /proc/$(pgrep nginx)/limits | grep "Max open files"）
- Nginx 主配置中设置了 worker_rlimit_nofile ≥ 该乘积（推荐设为相同值或略高）
- 系统全局句柄上限 /proc/sys/fs/file-max ≥ 该乘积 × 1.3～1.5（预留 TIME_WAIT、日志、SSL 缓存等开销）
按业务连接类型加权估算真实承载力
不同业务对连接资源的消耗差异极大，不能直接套用理论值：
- 短连接型（如静态资源、H5 秒杀页）：连接生命周期短，实际并发常接近理论值，可设 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。若长期 >90% 理论上限，说明连接池吃紧
- 执行 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 是否充足
别忘了配套瓶颈排查
即使文件描述符全够，其他环节也可能卡住并发：
- 监听队列溢出：net.core.somaxconn 过低（默认常为 128），会导致新连接在内核层就被丢弃，表现为请求无响应
- 临时端口耗尽：反向代理场景下，每个 upstream 连接占一个本地端口；检查 net.ipv4.ip_local_port_range，默认 32768–65535 仅约 32K 可用
- 内存压力：每个空闲 keepalive 连接约占用 128–256 KB 内存；8GB 服务器若全给 Nginx，实际支撑的空闲连接可能仅 3 万左右
