worker_rlimit_nofile仅在main块中设置进程级文件描述符上限，须≤系统soft/hard limit且需同步配置limits.conf、systemd LimitNOFILE及内核fs.nr_open才能生效。
直接调大 worker_rlimit_nofile 并不能突破单进程打开文件句柄数的限制，它只是告诉 Nginx 主进程在启动时主动调用 setrlimit(RLIMIT_NOFILE, ...)，尝试提升自身及后续 worker 进程能打开的文件描述符上限。真正起决定作用的是操作系统层面的限制，以及 Nginx 启动时的执行上下文。
理解 worker_rlimit_nofile 的作用范围
该指令仅影响 Nginx 主进程及其 fork 出的 worker 进程，不改变其他进程（如 systemd、shell）的限制；它必须在 main 块中配置，且仅在主进程启动阶段生效；它的值不能超过系统允许的最大值（/proc/sys/fs/nr_open），也不能高于启动 Nginx 时父进程（如 shell 或 systemd）所拥有的 nofile 软/硬限制。
必须同步调整系统级资源限制
-
用户级限制（推荐）：编辑
/etc/security/limits.conf，为运行 Nginx 的用户添加两行：nginx soft nofile 65536nginx hard nofile 65536
确保登录 shell 加载了 limits（可通过ulimit -n验证），且 Nginx 由该用户以交互式或 login shell 方式启动（systemd 默认不加载 limits，需额外配置）。 -
systemd 服务限制（生产常用）：修改 Nginx 的 service 文件（如
/etc/systemd/system/multi-user.target.wants/nginx.service），在[Service]段加入：LimitNOFILE=65536
然后执行systemctl daemon-reload && systemctl restart nginx。 -
全局内核参数（谨慎）：若需所有进程提高上限，可临时设置：
sysctl -w fs.nr_open=1048576
并写入/etc/sysctl.conf持久化。注意：此值是系统单进程可设RLIMIT_NOFILE的绝对上限，不可低于目标值。
验证是否真正生效
不要只看配置文件或 nginx -t，而要检查运行中的 worker 进程实际限制：
- 查主进程 PID：
ps aux | grep nginx | grep master - 查任一 worker 进程的 limits：
cat /proc/<em>PID</em>/limits | grep "Max open files" - 确认输出中
Soft Limit和Hard Limit均达到预期（如 65536）；若仍是 1024 或 4096，说明系统限制未打通，需回溯上一步配置。
常见失效原因与绕过方式
即使 worker_rlimit_nofile 设为 65536，仍可能卡在 1024，典型原因包括：
- systemd 未启用
PAMlimits 支持：检查/etc/pam.d/systemd是否存在session required pam_limits.so；若无，添加后重启宿主机（非仅 reload）。 - Nginx 由 root 启动但降权运行（如
user nginx;）：此时 worker 进程继承的是 root 的 limits，而非 nginx 用户的 limits。应统一使用 systemdLimitNOFILE或确保 root 的 limits 已调高。 - 容器环境（如 Docker）：宿主机限制 + 容器
--ulimit nofile=65536:65536+ 容器内 Nginx 配置三者缺一不可。
调优本质是打通“配置指令 → 启动上下文 → 内核接口”的链路，单改 Nginx 配置只是其中一环。不复杂但容易忽略。
