worker_rlimit_nofile是Nginx主配置指令，用于在fork worker前调用setrlimit()设其nofile软限，但必须≤系统对nginx用户的soft/hard limit，且需同步配置limits.conf、systemd LimitNOFILE及内核fs.file-max才生效。
worker_rlimit_nofile 是 Nginx 专用的配置指令，它**不能突破系统单进程文件描述符限制**，而是用来在 Nginx 主进程启动时，主动向内核申请一个更高的 per-process 文件描述符上限——前提是这个值**不超出系统已允许的软/硬限制**。换句话说，它是“声明式”的，不是“突破式”的。真正起决定作用的是操作系统层的 ulimit、limits.conf 和内核参数。
它实际做什么？
worker_rlimit_nofile 告诉 Nginx 主进程：启动工作子进程（worker process）前，请先调用 setrlimit() 系统调用，把每个 worker 进程的 nofile 软限制设为你指定的数值。这个动作发生在 Nginx 解析配置并 fork worker 之前。
但它不会、也不能：
- 绕过 /etc/security/limits.conf 对 nginx 用户（如 www-data 或 nobody）设定的 hard nofile 限制；
- 越过当前 shell 会话的 ulimit -Hn 值（如果 Nginx 是手动启动的）；
- 改变内核全局 fs.file-max 或单进程最大可设的 nr_open 上限。
为什么设了 worker_rlimit_nofile 却仍报 “Too many open files”？
常见原因有三个层级未对齐：
- 用户级限制未放开：/etc/security/limits.conf 中 nginx 所属用户（如 www-data）的 hard nofile 值 ≤ worker_rlimit_nofile 设置值 → 启动失败或被截断；
- systemd 服务限制覆盖了 limits.conf：现代 Linux（如 Ubuntu 22.04+/CentOS 8+）中，若 Nginx 由 systemd 管理，默认忽略 limits.conf。必须在 /etc/systemd/system/nginx.service.d/override.conf 中显式设置 LimitNOFILE；
- 内核上限不足：fs.file-max 太小（如仅 65536），而 Nginx worker 数 × 平均连接数接近该值，内核无法分配更多 FD。
正确配置顺序（缺一不可）
要让 worker_rlimit_nofile 生效且稳定，需按以下顺序设置：
- 修改 /etc/sysctl.conf，提高内核总容量：
fs.file-max = 2097152
执行 sudo sysctl -p 加载； - 编辑 /etc/security/limits.conf，放开 nginx 用户限制：
www-data soft nofile 1048576
www-data hard nofile 1048576（若用 root 启动则配 root）； - 为 systemd 服务补全限制（推荐）：
创建 /etc/systemd/system/nginx.service.d/override.conf：
[Service]
LimitNOFILE=1048576
再执行 sudo systemctl daemon-reload && sudo systemctl restart nginx； - 最后，在 nginx.conf 的 main 上下文中设置：
worker_rlimit_nofile 1048576;
如何验证是否真正生效？
不要只看 ulimit -n。应检查运行中的 worker 进程实际限制：
- 查 Nginx worker PID：ps -eo pid,comm | grep nginx（找非 master 的 PID）；
- 查看该进程限制：cat /proc/<PID>/limits | grep "Max open files"；
- 输出应类似：
Max open files 1048576 1048576 files —— 两列数字一致才表示软硬限制均已成功提升。
