worker_connections不是并发上限而是配置起点，其实际效果取决于系统资源、内核参数与业务模式的协同；需同步调优ulimit、worker_rlimit_nofile、fs.file-max等，并关注端口、监听队列、内存及I/O瓶颈。
worker_connections 本身不直接决定高负载处理能力，它只是单个 worker 进程能“登记在册”的最大连接数。真正影响高负载表现的，是它与系统资源、业务模式、内核参数之间的协同关系——调大这个值，若其他环节没跟上，不仅无效，还可能加速崩溃。
它不是并发上限，而是配置起点
理论最大连接数 = worker_processes × worker_connections，比如 8 核机器设为 worker_processes auto（即 8）和 worker_connections 16384，得出 131072。但这只是纸面数字，必须同时满足：
- 每个 nginx worker 进程的 ulimit -n ≥ 该乘积（查 cat /proc/$(pgrep nginx)/limits | grep "Max open files"）
- Nginx 配置中 worker_rlimit_nofile ≥ 该乘积（建议设为相同或略高）
- 系统级 /proc/sys/fs/file-max ≥ 该乘积 × 1.2～1.5（预留 TIME_WAIT、日志、缓存等开销）
高负载时真正卡住你的，往往不是它
即使文件描述符全达标，Nginx 仍可能在高负载下响应迟缓或丢请求，常见真实瓶颈包括：
- 本地端口耗尽：反向代理场景下，每个 upstream 连接要占一个临时端口；默认 net.ipv4.ip_local_port_range = 32768–65535，仅约 32K 可用；高并发建议扩至 1024 65000
- 监听队列溢出：内核 net.core.somaxconn 默认常为 128，太小会导致新连接在 accept 前就被丢弃，表现为无响应而非 5xx
- 内存吃紧：每个空闲 keepalive 连接约占 128–256 KB；8GB 内存服务器若全给 Nginx，实际支撑的空闲连接可能仅 3 万左右
- I/O 卡顿：top 中 %wa > 30%、iotop 显示 php-fpm 或 nginx 狂刷磁盘、ps 查到大量 D 状态进程，说明磁盘已成瓶颈
靠运行时数据判断是否逼近极限
不要只看配置，要结合实时状态做决策：
- 启用 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) —— 这是文件描述符真正耗尽的直接证据
按业务类型动态估算真实承载力
静态资源（图片、JS）连接生命周期极短，理论值基本可用；但 API 或 WebSocket 类长连接服务，需加权折算：
- 短连接（CDN、页面资源）：worker_connections × worker_processes 接近实际吞吐能力
- 长连接（API、WebSocket）：每连接内存占用高、超时时间长，实际支撑数可能只有理论值的 1/3～1/2
- 反向代理场景：既要算客户端连接，也要算 upstream 连接，总连接数 ≈ client_conn + upstream_conn，容易翻倍消耗资源
