Nginx 如何排查 Nginx 在高吞吐下因为文件描述符限制过低导致的报错

必须同步调高系统级、启动环境级和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 上限：

1. 找主进程 PID：pgrep nginx | head -1
2. 查它的资源限制：cat /proc/<PID>/limits | grep "Max open files"
3. 若显示 1024 1024，说明启动环境没给够；若显示 65535 65535 却仍报错，再查 worker_connections × worker_processes 是否超过该值，或后端连接/日志/静态文件把 FD 耗尽了

检查并调高三处关键限制

必须同步改这三项，缺一不可：

1. 系统级：运行 ulimit -n 看当前会话限制；永久生效就加到 /etc/security/limits.conf，例如：

   nginx soft nofile 65535

   nginx hard nofile 65535

2. 启动环境级：二进制安装需改启动脚本（如 /etc/init.d/nginx），在 nginx 命令前加：

   ulimit -n 65535

   ulimit -Hn 65535

3. Nginx 自身级：在 nginx.conf 全局块（http 外）加：

   worker_rlimit_nofile 65535;

   同时确保 events { worker_connections 8192; } 不超过它

验证和辅助排查

改完别急着 reload，先确认是否真正生效：

1. 重启 Nginx 后，重新执行 cat /proc/<PID>/limits，确认数值已变
2. 用 lsof -p <PID> | wc -l 看当前打开的 FD 数，接近上限就要警惕泄漏
3. 临时提高内核总池子：sysctl -w fs.file-max=262144，并写入 /etc/sysctl.conf 永久生效
4. 开启连接复用减少开销：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 }