worker_connections 不直接加速单个请求，而是决定并发承载能力；设过低导致连接拒绝、TTFB升高、503增多，设过高则引发资源争抢、CPU空转、延迟反升。
worker_connections 直接影响 Nginx 能否及时接收、分发和维持连接，但它本身不加速单个请求的处理，而是决定“能不能撑住并发”。设得太低，新连接被拒绝或排队，用户感知为卡顿、超时、503；设得过高却不匹配系统与后端能力，反而引发资源争抢或空转，响应延迟不降反升。
它怎么影响响应时间
worker_connections 是每个 worker 进程能同时管理的连接总数（含客户端连接、上游连接、keepalive 空闲连接）。当实际并发连接数逼近该值时：
- 新连接可能被内核 listen 队列缓冲，等待 accept —— 增加首字节延迟（TTFB）
- 超过队列容量后，连接直接被丢弃，客户端重试 → 请求量虚增，后端压力翻倍
- worker 进程忙于轮询大量连接，事件处理效率下降，CPU 利用率升高但吞吐未提升
关键匹配项不能漏
单独调高 worker_connections 没用，必须同步满足以下条件：
- 系统文件描述符足够：ulimit -n ≥ worker_processes × worker_connections，否则启动报错或运行时报 “Too many open files”
- 后端响应够快：如果 upstream 处理一个请求要 2 秒，哪怕 worker_connections 设到 8192，连接也会堆积，Nginx 只是“排队窗口”，不是“加速器”
- CPU 核心数匹配 worker_processes：比如 4 核却配 8 个 worker，上下文切换开销上升，sy% 升高，响应抖动加剧
- net.core.somaxconn ≥ worker_connections：该内核参数限制 listen 队列长度，否则连接在进入 Nginx 前就被丢弃
反向代理场景下的典型配置组合
面向中高并发反向代理（如 API 网关、静态资源代理），推荐这样协同调整：
- worker_processes auto; （自动匹配物理核心数）
- events { worker_connections 4096; use epoll; }
- upstream backend { keepalive 32; } —— 复用连接，减少建连开销
- location / { proxy_http_version 1.1; proxy_set_header Connection ''; ... }
- proxy_connect_timeout 10; proxy_read_timeout 30; —— 避免慢请求长期占位
怎么确认它真起作用了
改完别只信配置，要看真实态：
- 用 ss -tan | grep :80 | wc -l 查当前 ESTABLISHED 连接数，对比 worker_connections × worker_processes
- 启用 stub_status，访问 /nginx_status，看 Accepts/Handled 是否接近 1（说明没丢连接）
- 观察 error.log：出现 “accept() failed (24: Too many open files)” 就是系统限制没跟上
- 压测时关注 wrk 的 latency p99 和失败率 —— worker_connections 不足时，p99 会陡升，失败率跳变
