worker_rlimit_nofile 生效需满足三条件：配置在main上下文、系统硬限制≥配置值、systemd LimitNOFILE已覆盖；最终以/proc/[pid]/limits中Soft Limit为准。
排查 worker_rlimit_nofile 配置生效失败，不能只看 nginx.conf 是否写了，关键要验证它是否真正被内核授权、被 worker 进程继承。失效往往不是配置错了，而是系统级限制链路断了。
确认配置位置是否合法
该指令必须位于 main 上下文 —— 即 nginx.conf 文件最外层、events 块之前、http 块之外。任何嵌套写法都无效：
- 写在
http { }内 → 报unknown directive "worker_rlimit_nofile" - 写在
server或location块内 → 同样触发未知指令错误 - 写在
events { }块内部 → 语法不报错但完全不生效
检查系统硬限制是否对齐
nginx 启动时会以运行用户身份向内核申请句柄上限，若配置值超过该用户的 hard nofile，就会静默降级或直接失败：
- 查当前主进程用户：
ps -eo pid,comm,user | grep "nginx: master" | awk '{print $3}' - 查该用户的硬限制：
sudo -u www-data bash -c "ulimit -Hn"（用户名按实际替换） - 若输出是
1024，而你在 nginx.conf 中设了131072，那必然失败
验证 systemd 是否覆盖了限制
现代 Linux 普遍用 systemd 管理 Nginx，它默认忽略 /etc/security/limits.conf。只改 limits 文件，对 systemctl start nginx 完全无效：
- 查服务实际限制：
systemctl show nginx | grep LimitNOFILE - 若为空或远低于预期，需创建覆盖配置：
/etc/systemd/system/nginx.service.d/override.conf - 内容为：[Service]
LimitNOFILE=131072 - 执行：
systemctl daemon-reload && systemctl restart nginx
验证进程真实生效值
所有配置和重启之后，唯一可信的验证方式是读取正在运行的 worker 进程的内核 limits：
cat /proc/$(pgrep -f "nginx: worker" | head -n1)/limits | grep "Max open files"- 输出中 Soft Limit 必须等于你配置的
worker_rlimit_nofile值 - Hard Limit 必须 ≥ 该值，否则说明系统级限制未打通
