worker_connections 65535需同步调优三层文件描述符限制：系统级（/etc/security/limits.conf）、systemd级（LimitNOFILE）、Nginx进程级（worker_rlimit_nofile），并配全epoll、multi_accept等events参数，否则将因fd不足报“Too many open files”或连接卡顿。
worker_connections 65535 不是直接填进去就能用的
设成 worker_connections 65535 后 Nginx 启动失败、日志里反复报 24: Too many open files，或者压测时连接数卡在几万就上不去——这说明系统没真正“放行”，不是配置写错了，而是资源链路断在了前面。
必须同步调高三处文件描述符限制
每个 TCP 连接至少占 1 个文件描述符（fd），而 worker_connections 是 per-worker 的上限。若 worker_processes 是 8，那理论需要 524280 个 fd；但只要其中任意一环卡在默认 1024，实际就只能撑住不到 1024 连接。
- 系统级硬限：
/etc/security/limits.conf中添加（替换nginx为实际运行用户，如www-data）：* soft nofile 65535<br>* hard nofile 65535
- systemd 服务级限制（如果用
systemctl start nginx）：在/etc/systemd/system/nginx.service.d/override.conf中写：[Service]<br>LimitNOFILE=65535
，然后执行systemctl daemon-reload && systemctl restart nginx - Nginx 进程级声明：在
nginx.conf主块（events外、http前）加worker_rlimit_nofile 65535；该值必须 ≥worker_connections，否则 Nginx 自己会降级使用默认值
验证是否生效：运行 cat /proc/$(pgrep nginx)/limits | grep "Max open files"，输出的 soft 和 hard 值都应 ≥ 65535。
events 块里还要配齐配套参数
只改 worker_connections，不调 use epoll 或 multi_accept，高并发下连接进不来、accept 慢、CPU 空转，65535 就只是个纸面数字。
- Linux 必须显式写
use epoll；自动探测可能 fallback 到低效的select -
multi_accept on：让单次事件循环尽可能多地accept()新连接，减少延迟抖动 -
accept_mutex on（短连接密集场景建议开启）：避免多个 worker 同时争抢 accept，引发“惊群” - 确保
worker_connections写在events { }块内，且不在http或server块里重复定义
65535 在不同业务场景下未必是最优解
这个值对 API 网关或静态资源服务比较稳妥，但对长连接或 HTTPS 反向代理，它可能偏高甚至有害——每个连接内存占用上升、上下文切换加剧，还可能挤占上游连接池空间。
- 短连接 + 高频请求（如 JSON API）：从
worker_connections 8192起步，压测后逐步调到 32768，配合keepalive_timeout 15控制复用窗口 - WebSocket / HTTP/2 / 直播流：连接生命周期长，更依赖
worker_rlimit_nofile和sysctl底层队列，worker_connections设 32768～65535 即可，重点调net.core.somaxconn和net.ipv4.tcp_max_syn_backlog - HTTPS 反向代理：SSL session cache、OCSP stapling、证书文件都会额外消耗 fd，建议
worker_rlimit_nofile至少设为worker_connections × 1.2
真正卡脖子的往往不是 worker_connections 本身，而是它背后那条从内核 fs.file-max → 用户级 ulimit → Nginx worker_rlimit_nofile → events 参数的完整链路；漏掉任何一环，65535 就只是个会报错的数字。
