worker_connections 表示每个 worker 进程可同时管理的最大文件描述符数，涵盖客户端连接、日志句柄、缓存文件等，并非仅限活跃请求；其实际效能受系统 ulimit、worker_processes 及业务模型（如 HTTP/1.1 复用或 HTTP/2 多路复用）共同制约。
直接看 worker_connections 本身不能预判极限，必须结合当前运行状态、系统资源和业务特征综合分析。它只是一个理论上限参数，真实瓶颈往往出现在它被“吃满”之前。
明确 worker_connections 的实际含义
它表示每个 worker 进程最多能同时管理的文件描述符（fd）数量，包括：
- 客户端 HTTP/HTTPS 连接（含 keepalive 空闲连接）
- 日志文件句柄（如 access.log、error.log）
- 临时缓存文件、SSL 会话缓存等内部资源
也就是说，不是每个连接都只对应一个请求。静态服务中，一个 keepalive 连接可能复用处理多个请求，但只要没关闭，就持续占用一个 fd。
关键监控指标要联动看
仅查配置里的 worker_connections 10240 没用，得看运行时是否逼近该值：
-
活跃连接数：用
ss -tan state established | grep :80 | wc -l或通过stub_status查Active connections:值 - 最大连接使用率：Active / (worker_processes × worker_connections)，持续 > 85% 就需警惕
-
错误日志频次：关注
accept() failed (24: Too many open files)是否出现——这说明已触达系统级限制，不是 Nginx 配置问题，而是 ulimit 或 fs.file-max 不足 -
TIME_WAIT 连接堆积：用
ss -tan state time-wait | wc -l，若远超活跃连接数，说明短连接频繁释放，端口和 fd 消耗快，需调优内核参数（如net.ipv4.tcp_tw_reuse）
按静态服务特征估算安全并发量
静态资源（JS/CSS/图片）生命周期短、响应快，但并发模型仍受连接复用影响：
- HTTP/1.1 + keepalive：平均每个客户端维持 1～2 个长连接，理论并发 ≈
worker_processes × worker_connections × 0.7（留 30% 缓冲） - HTTP/2 或 HTTPS：多路复用显著降低连接数，同样配置下可支撑更高请求数，但单连接内存开销略增
- 大量小图请求 + 短超时（如
keepalive_timeout 5s）：连接周转快，fd 压力集中在新建阶段，此时更要看Accept queue是否溢出（netstat -s | grep "listen overflows"）
提前发现瓶颈的操作建议
- 在压测中逐步提升 QPS，同步记录
stub_status中的Reading/Writing/Waiting三态分布；Waiting 持续升高且 Active 接近上限，说明连接池即将饱和 - 检查
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认 worker 进程实际可用 fd 数 ≥ 配置的worker_connections - 如果
worker_connections设为 16384，但ulimit -n只有 4096，Nginx 启动时虽不报错，但会静默降级到 4096，必须验证运行态而非配置态
