调优 worker_connections 必须同步对齐系统文件描述符、nginx 进程级限制（worker_rlimit_nofile）和内核网络队列（net.core.somaxconn）三者最小值，缺一则实际并发上限被卡死，导致静默丢连接或“too many open files”错误。
调优 worker_connections 不是改一个数字就完事，它卡住时往往不报错，只静默丢连接、吞吐上不去、压测失真。真正起作用的是系统文件描述符限制、Nginx 进程级声明、内核网络队列三者中的最小值——任一环节偏低，再高的配置也白搭。
查清真实瓶颈：为什么设了 16384 却连 2000 都撑不住？
常见假象是“配置 reload 成功”，但实际生效值远低于预期。必须逐层验证：
- 看系统总容量：
cat /proc/sys/fs/file-max，应 ≥worker_processes × worker_connections × 1.4（预留 SSL 缓存、TIME_WAIT、日志等开销） - 看用户级限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，输出的 soft/hard 值必须 ≥ 你设定的worker_connections - 看 Nginx 自身声明：
worker_rlimit_nofile必须写在events块外、http块前，且值 ≥worker_connections（建议设为相同值或 1.2 倍） - 看内核入口队列：
ss -s | grep tcp，若inuse长期逼近net.core.somaxconn，说明连接还没进 Nginx 就被内核丢弃
系统与进程级限制必须同步放开
Linux 默认单进程最多打开 1024 个文件描述符，每个 TCP 连接至少占 1 个 fd，Nginx 还要额外用 fd 处理日志、上游连接、SSL session cache 等。
- 永久放开用户限制：编辑
/etc/security/limits.conf，为运行用户（如www-data）添加两行：www-data soft nofile 65536www-data hard nofile 65536 - 若用 systemd 管理，还需创建
/etc/systemd/system/nginx.service.d/override.conf，加入：[Service]LimitNOFILE=65536
然后执行systemctl daemon-reload && systemctl restart nginx - 验证是否落地：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"输出值应与你设定一致
按业务类型设合理值，不是越大越好
数值过高会吃内存、增上下文切换，过低则卡在连接入口。关键看连接生命周期和复用模式：
- 高频短连接（如 H5 秒杀页、REST API）：连接建得快、断得快，fd 消耗快但单连接驻留时间短 → 推荐
worker_connections 4096–16384，配合keepalive_timeout 5–15防堆积 - 长连接保活型（如 WebSocket、HTTP/2 上报、直播流）：单连接持续几十秒至数分钟，fd 占用稳定但总量大 → 推荐
2048–8192，并设keepalive_timeout 15–30控制空闲释放 - HTTPS 反向代理：除 socket 外还需 SSL session cache、OCSP stapling、证书读取等额外 fd →
worker_connections建议不超过单进程 ulimit 的 70%～80%
配套 events 参数必须协同启用
只改 worker_connections 就像拓宽车道却不修入口匝道——车根本上不来。
-
use epoll;：Linux 下必须显式指定，否则可能回退到select/poll的 1024 硬限制 -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队压力 -
accept_mutex on;：默认开启，防止多个 worker 同时争抢新连接导致“惊群”；与multi_accept协同工作更有效 - 关闭未启用的日志写入，或启用缓冲：
access_log /var/log/nginx/access.log main buffer=64k flush=1s;，减少每次请求的 fd 和 I/O 开销
