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 65536
nginx 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 未启用 PAM limits 支持：检查 /etc/pam.d/systemd 是否存在 session required pam_limits.so；若无，添加后重启宿主机（非仅 reload）。
• Nginx 由 root 启动但降权运行（如 user nginx;）：此时 worker 进程继承的是 root 的 limits，而非 nginx 用户的 limits。应统一使用 systemd LimitNOFILE 或确保 root 的 limits 已调高。
• 容器环境（如 Docker）：宿主机限制 + 容器 --ulimit nofile=65536:65536 + 容器内 Nginx 配置三者缺一不可。

调优本质是打通“配置指令 → 启动上下文 → 内核接口”的链路，单改 Nginx 配置只是其中一环。不复杂但容易忽略。