worker_connections需按业务类型、硬件上限、系统限制和配套参数四方面协同调优：短连设4096–16384，长连设2048–8192并配keepalive_timeout；理论并发=worker_processes×worker_connections，但受ulimit、worker_rlimit_nofile和CPU核数三重限制；必须搭配use epoll;、multi_accept on;和accept_mutex on;才能生效。
worker_connections 不是拍脑袋填的数字，它得和你这个站点真实扛得住多少并发请求对齐——填高了系统卡死，填低了资源浪费。调优核心就四件事：看业务类型、算硬件上限、破系统限制、配配套参数。
先按业务连接特征定起点值
不同业务对连接的“粘性”差别很大，直接影响单 worker 能稳住多少连接：
- 静态资源（图片、JS/CSS）或短连接 API：连接建立快、用完即关，适合设 4096–16384；起步建议用 8192
- HTTP/2 或 WebSocket 长连接：一个用户可能挂十几分钟，连接不释放，建议 2048–8192，同时把
keepalive_timeout控在 15–30 秒，防空闲占位 - 反向代理且后端响应慢（比如调老系统接口）：连接会在 Nginx 里排队等待，这时盲目加 worker_connections 没用，优先调
proxy_read_timeout和重试策略
再看硬件和系统能撑住多少
理论最大并发 = worker_processes × worker_connections，但这只是纸面数字，实际受三道硬门槛卡着：
-
系统文件描述符限制：Linux 默认每个进程最多 1024 个 fd，每个连接至少占 1 个。设了 8192 却没调
ulimit -n，实际还是 1024 -
Nginx 自身声明上限：必须在
nginx.conf主上下文（http 块外）加worker_rlimit_nofile 65536;，且该值 ≥worker_connections -
CPU 核心数：
worker_processes建议设为auto（物理机/VM）或显式设为容器分配的核数（如 2 核就设 2），避免进程过多反而抢资源
配套 events 参数必须一起调
只改 worker_connections 几乎没用，必须搭配事件模型才能真正跑满：
-
use epoll;：Linux 必须显式写上，否则可能回退到 select/poll，有 1024 硬上限 -
multi_accept on;：让一个 worker 在一次事件循环里尽可能多地 accept 新连接，应对突发流量 -
accept_mutex on;：默认开启，防止多个 worker 同时争抢新连接（惊群问题），和 multi_accept 是搭档
验证是否真生效
别信配置写了就有效，要动手查：
- 查系统限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，软硬限制都应 ≥ 你设的worker_connections - 查运行中连接：
ss -s | grep "tcp"或netstat -an | grep :80 | wc -l，对比 ESTABLISHED 数是否接近理论值 - 盯错误日志：
tail -f /var/log/nginx/error.log，反复出现Too many open files就说明 fd 没调通
