调大worker_connections不等于提升并发能力，必须与系统file-max、用户limits.conf、nginx.conf中worker_rlimit_nofile三者对齐，并按短连/长连/https场景合理设值，同步启用epoll、multi_accept等events参数。
调大 worker_connections 不等于提升并发能力，反而容易踩进“Too many open files”、连接静默拒绝、压测失真等雷区。关键不是填个数字，而是让这个值在系统资源、Nginx 运行机制和业务连接行为之间真正对得上。
先打通三层文件描述符限制
实际能撑住的连接数，取决于以下三者的最小值——任一环节卡住，worker_connections 就只是个摆设：
-
系统总上限：
/proc/sys/fs/file-max，建议设为worker_processes × worker_connections × 1.4（预留 SSL 缓存、TIME_WAIT、日志等开销） -
用户级限制：编辑
/etc/security/limits.conf，为 Nginx 运行用户（如www-data或nginx）添加：
www-data soft nofile 65536
www-data hard nofile 65536 -
Nginx 进程级声明：在
nginx.conf主块（events外、http前）加：
worker_rlimit_nofile 65536;（推荐 ≥worker_processes × worker_connections，留 10%～20% 余量）
按业务类型设真实合理的值
不同连接模式对资源消耗差异极大，不能统一套用高数值：
-
短连接密集型（如 API 网关、H5 秒杀页、CDN 回源）：连接快建快关，fd 高频复用。建议从
4096–8192起步，压测后逐步调至16384–32768；keepalive_timeout可设15–30s -
长连接保活型（如 WebSocket、HTTP/2 上报、直播流 HTTP-FLV）：单连接复用时间长，fd 占用稳定但总量大。建议直接设
32768–65535，并重点保障worker_rlimit_nofile和内核net.core.somaxconn充足 -
HTTPS 反向代理：除 socket 外，还需 SSL session cache、OCSP stapling、证书文件等额外 fd 开销。建议
worker_connections不超过单进程ulimit -n的70%–80%（例如 ulimit 是 65536，就设 ≤52428）
配套 events 参数必须同步生效
只改 worker_connections 几乎没用，连接还没进 Nginx 就可能被内核丢弃：
-
强制启用高效事件模型：Linux 下必须显式写
use epoll;，否则可能回退到有 1024 硬限的select/poll -
提升单次事件循环吞吐：加
multi_accept on;，让一个 worker 在一次 epoll wait 后尽可能多地 accept 新连接 -
扩大内核监听队列：设
net.core.somaxconn = 65535（写入/etc/sysctl.conf并执行sysctl -p），避免 SYN 包被直接丢弃 -
listen 指令带 backlog：如
listen 80 backlog=4096;，且确保该值 ≤net.core.somaxconn
验证是否真正落地
reload 成功 ≠ 配置生效，务必实测确认：
- 查运行中 worker 的实际句柄上限：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 观察当前 fd 占用：
lsof -p $(pgrep nginx) | wc -l - 看连接状态分布：
ss -s | grep tcp，重点关注inuse是否长期逼近somaxconn - 压测时监控
Active connections是否持续 >85%，同时Accepts/Handled比例明显下降（说明连接入口或处理链路已瓶颈）
