Nginx worker_connections 实际压力需通过 stub_status 实时指标分析：Active=Reading+Writing+Waiting，反映总TCP连接；Reading/Writing高表明接收或响应瓶颈；Waiting高通常健康但需防异常；Accepts≠Handled提示系统级资源或进程异常。
理解 Nginx 的 worker_connections 实际使用情况，关键不在于配置值本身，而在于通过 stub_status 输出的实时状态指标反推连接在各环节的分布和压力点。这些数字不是孤立的计数，而是反映工作线程当前“忙什么”的快照。
Active connections 是总连接数，不是并发请求数
它等于 Reading + Writing + Waiting 三者之和，代表 Nginx 当前维持的所有 TCP 连接总数。注意：这包括 keep-alive 空闲连接，不等于正在处理的 HTTP 请求个数。比如一个浏览器打开页面后保持长连接但没发新请求，它就计入 Active，但属于 Waiting 状态。
Reading 和 Writing 揭示实时处理瓶颈
这两个值直接体现 worker 正在执行的动作：
- Reading 高：说明大量连接卡在接收请求头或请求体阶段。常见原因有客户端网络差、上传大文件、SSL 握手慢、或上游服务响应不规范导致 Nginx 无法及时判断请求边界
- Writing 高：说明响应发送受阻。可能是后端响应慢、客户端弱网、TCP 缓冲区满、或启用 Gzip 后压缩耗时高
- 若 Reading + Writing 持续接近甚至等于
worker_connections设置值，且 Active 也高，说明单个 worker 承载压力已近极限，需考虑增加worker_processes或优化后端
Waiting 是健康长连接的标志，但过高也需留意
Waiting = Active − (Reading + Writing)，本质是 keep-alive 空闲连接数。它长期占 Active 的 80% 以上，通常说明：
- 客户端多为现代浏览器，习惯性复用连接
- worker 处理能力有余量，没有排队积压
- 当前
worker_processes数量可能已足够，加进程未必提升性能，反而增加调度开销
Accepts 与 Handled 不等，提示底层异常
这两个是累计值，正常情况下应始终相等。如果 Handled < Accepts 且差值持续扩大，说明部分连接被异常中断，不是单纯靠调高 worker_connections 能解决的。常见原因包括：
- 系统级资源不足（如文件描述符耗尽，查
ulimit -n） - worker 进程崩溃或被 OOM killer 杀掉（查 error.log 和系统日志）
- upstream 响应超时或拒绝连接，导致 Nginx 主动断开
