反向代理模式下worker_connections需≥2+2×并发用户数，因每个请求占用1个客户端入向连接和1个后端出向连接，二者共享同一worker进程连接池。
反向代理模式下，worker_connections 的实际消耗是“翻倍”的，这不是 bug，而是由 HTTP 协议和 Nginx 工作机制共同决定的——每个客户端请求，Nginx 不仅要维持一个与客户端的连接，还要建立一个与后端服务器（upstream）的连接。这两个连接都计入同一 worker 进程的 worker_connections 配额中。
为什么是“2 倍”而不是“1 倍”？
关键在于连接角色分离：
- 客户端 → Nginx：入向连接（inbound），用于接收请求、发送响应
- Nginx → 后端服务（如 Tomcat、Node.js）：出向连接（outbound），用于转发请求、读取响应
这两类连接共享同一个 worker 进程的连接池。因此，1 个活跃的代理请求，至少占用 2 个连接槽位（理想无复用情况下）。若开启 keepalive 或 pipeline，单连接可承载多个请求，但连接本身仍需长期保活，资源占用逻辑不变。
如何按用户量合理估算最小值？
公式：worker_connections ≥ 2 + 2 × 并发用户数
说明：
- “2” 是基础开销：master 进程通信、定时器、日志句柄等常驻 fd
- “2 × 并发用户数”：每个并发用户平均对应 1 个客户端连接 + 1 个上游连接
- 注意：这里的“并发用户数”指瞬时活跃连接数（非注册用户总数），可通过
ss -tan | grep :80 | wc -l或 stub_status 的Active connections实时观察
避免配置失衡的两个硬性前提
仅调高 worker_connections 不起作用，必须同步满足：
-
系统级文件描述符足够：运行
ulimit -n查看当前限制；若低于worker_processes × worker_connections，需在/etc/security/limits.conf中为 nginx 用户设置soft nofile和hard nofile -
worker_rlimit_nofile ≥ worker_connections：该指令在 nginx.conf 全局块中声明，它才是 worker 进程真正能打开的最大 fd 数；若它小于
worker_connections，Nginx 会拒绝分配连接，报错accept() failed (24: Too many open files)
验证是否真正撑住“双连接”压力
不能只看配置数字，重点看运行态表现：
- 启用
stub_status模块，访问/nginx_status，关注Reading/Writing/Waiting三态分布——若Writing长期高位，说明上游响应慢，连接堆积；若Waiting接近worker_connections，说明连接池已近饱和 - 检查 error.log 是否频繁出现
upstream timed out或connect() failed (111: Connection refused)，这往往意味着 upstream 无法及时响应，导致连接滞留 - 压测时对比 ab/wrk 的
Failed requests和 Nginx worker CPU：若失败率高但 CPU 很低，大概率是 upstream 瓶颈，而非 Nginx 连接不足
