worker_connections不是压测搜出最大值，而是验证是否配得准：需对齐系统/file-max、用户/limits.conf、nginx/worker_rlimit_nofile三层限制，按短连/长连/https业务模型设初始值（如4096–65535），压测时观察70%～80%负载下延迟、qps、accept失败及fd耗尽现象。
worker_connections 不是靠压测“搜出一个最大值”，而是通过压测验证它是否配得准——能否稳定承载你的真实连接模型，同时不触发系统瓶颈或拒绝错误。关键不在数字本身，而在三层限制是否对齐、资源是否吃紧、连接行为是否符合预期。
明确压测目标，不是找最大值，而是验稳定性
压测时重点关注以下几类现象，而非单纯追求连接数冲高：
- 当并发连接升至预设 worker_connections 的 70%～80% 时，p99 延迟是否明显上升、QPS 是否平台化甚至回落
- 是否出现 accept() failed (24: Too many open files) 或连接被静默重置（connection reset）
- Active connections 曲线是否随并发线性增长，有无突降或卡顿（说明连接被丢弃或阻塞）
- 系统级 fd 使用率是否逼近上限：用 lsof -p $(pgrep nginx) | wc -l 对比 ulimit 值
必须先对齐三层文件描述符限制
压测前若未对齐，结果完全失真。三者取最小值，才是真实瓶颈：
- 系统级：/proc/sys/fs/file-max ≥ worker_processes × worker_connections × 1.3～1.5（预留 SSL 缓存、TIME_WAIT、日志等开销）
-
用户级：/etc/security/limits.conf 中为 Nginx 运行用户（如 nginx 或 www-data）设置：
nginx hard nofile 65536
nginx soft nofile 65536
并确保重启会话或重载 systemd 生效 -
Nginx 级：在 nginx.conf 主块（events 外、http 前）添加：
worker_rlimit_nofile 65536;
该值必须 ≥ worker_connections，推荐设为相同值或略高（如 1.2 倍）
验证是否生效：运行 cat /proc/$(pgrep nginx)/limits | grep "Max open files"，输出软硬限均应 ≥ 你设定的 worker_connections。
按业务连接类型设定初始值再压测
不同场景下连接生命周期差异大，起始值和调优方向完全不同：
- 短连接密集型（如 API 网关、H5 秒杀页）：连接建立快、关闭快，fd 波动高频。建议从 4096～8192 起步，压测后逐步调到 16384～32768
- 长连接保活型（如 WebSocket、HTTP/2 上报、直播流）：单连接复用时间长，fd 占用稳定但总量大。建议直接设 32768～65535，并重点保障 worker_rlimit_nofile 和 file-max 充足
- HTTPS 反向代理：除 socket 外还需 SSL session cache、OCSP stapling、证书读取等额外 fd 开销。建议 worker_connections 不超过单进程 ulimit 的 70%～80%，例如 ulimit -n 是 65536，就设 40960 或更低
配套 events 参数必须同步启用
只改 worker_connections 效果有限，必须协同优化事件处理机制：
- 在 events 块中显式声明：use epoll;（Linux 必须，避免回退到 select/poll 的 1024 硬限）
- 启用 multi_accept on;：让单个 worker 在一次事件循环中尽可能多地接收新连接，缓解突发流量排队
- 保持 accept_mutex on;（默认开启）：防止多个 worker 同时争抢新连接导致“惊群”
- 日志写入可缓冲：access_log /var/log/nginx/access.log buffer=64k flush=1s;，减少每个请求占用的 fd
