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，就会静默降级或直接失败：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 查当前主进程用户：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 必须 ≥ 该值，否则说明系统级限制未打通