必须同步调高系统级、启动环境级和nginx自身级三处文件描述符限制：在/etc/security/limits.conf设nginx用户软硬限制为65535，启动脚本前加ulimit命令，并在nginx.conf全局块配置worker_rlimit_nofile 65535且确保worker_connections×worker_processes不超过该值。
遇到高吞吐下 Nginx 报 accept() failed (24: Too many open files) 或 worker_connections are not enough，基本可以锁定是文件描述符（FD）不足——不是配置写少了，而是系统、进程、Nginx 三层限制没对齐，其中任一环卡在 1024 就会崩。
看真实瓶颈在哪一层
别猜，直接查进程实际拿到的 FD 上限：
- 找主进程 PID：
pgrep nginx | head -1 - 查它的资源限制：
cat /proc/<pid>/limits | grep "Max open files"</pid> - 若显示
1024 1024，说明启动环境没给够；若显示65535 65535却仍报错，再查worker_connections × worker_processes是否超过该值，或后端连接/日志/静态文件把 FD 耗尽了
检查并调高三处关键限制
必须同步改这三项，缺一不可：
-
系统级：运行
ulimit -n看当前会话限制；永久生效就加到/etc/security/limits.conf，例如：nginx soft nofile 65535nginx hard nofile 65535 -
启动环境级：二进制安装需改启动脚本（如
/etc/init.d/nginx），在nginx命令前加：ulimit -n 65535ulimit -Hn 65535 -
Nginx 自身级：在
nginx.conf全局块（http 外）加：worker_rlimit_nofile 65535;
同时确保events { worker_connections 8192; }不超过它
验证和辅助排查
改完别急着 reload，先确认是否真正生效：
- 重启 Nginx 后，重新执行
cat /proc/<pid>/limits</pid>，确认数值已变 - 用
lsof -p <pid> | wc -l</pid>看当前打开的 FD 数，接近上限就要警惕泄漏 - 临时提高内核总池子：
sysctl -w fs.file-max=262144，并写入/etc/sysctl.conf永久生效 - 开启连接复用减少开销：
keepalive_timeout 60;和keepalive_requests 100;放在 http 块里
注意 Docker 场景的特殊性
容器里默认只有 1024 FD，且 limits.conf 不生效。必须在 docker run 时加参数：--ulimit nofile=65535:65535
或在 docker-compose.yml 中写：ulimits: nofile: { soft: 65535, hard: 65535 }
