worker_rlimit_nofile仅是Nginx声明每个worker进程文件描述符上限的入口，必须同步调优系统limits、systemd限制、内核fs.file-max，并匹配worker_connections与keepalive策略，否则无法解决“Too many open files”错误。
worker_rlimit_nofile 本身不能“彻底解决” too many open files 错误，它只是 Nginx 配置中一个关键的**上限声明入口**，真正起作用的是它与系统级资源限制、Nginx 工作进程模型、连接生命周期管理的协同配合。单独调大这个值而不调整底层限制或优化连接行为，反而可能掩盖问题、触发内核 OOM 或引发稳定性风险。
明确 worker_rlimit_nofile 的作用边界
该指令仅用于在 Nginx 主进程启动时，通过 setrlimit(RLIMIT_NOFILE, ...) 系统调用，为所有 worker 进程**统一设置打开文件数的软/硬限制**（等效于 ulimit -n）。它不改变系统全局限制，也不自动分配文件描述符——它只是告诉内核：“每个 worker 最多允许打开这么多 fd”。若系统未提前配置足够高的 limits.conf 或 systemd 限制，Nginx 启动会失败或静默降级到默认值（通常是 1024）。
必须同步调整的系统级限制
worker_rlimit_nofile 要生效，需确保以下三层限制均满足且合理递进：
-
/etc/security/limits.conf（适用于 sysvinit 或非 systemd 环境）：
nginx soft nofile 65536
nginx hard nofile 65536
注意：需确认 Nginx 以 nginx 用户运行，并重启登录会话或重载 PAM。 -
systemd 服务限制（现代主流发行版默认使用）：
在/etc/systemd/system/nginx.service.d/override.conf中添加：
[Service]
LimitNOFILE=65536
执行systemctl daemon-reload && systemctl restart nginx -
内核级总限制（可选但推荐）：
检查fs.file-max（如sysctl fs.file-max），建议设为高于单机总连接预期值（例如 200 万），避免全局耗尽：
echo 'fs.file-max = 2097152' >> /etc/sysctl.conf && sysctl -p
匹配 Nginx 配置与连接模型
即使系统允许 65536 个 fd，若 Nginx 配置不当，仍会快速耗尽：
-
worker_connections 必须 ≤ worker_rlimit_nofile / worker_processes：
例如：4 个 worker + worker_rlimit_nofile 65536 → 单 worker 最高可用约 16384 个连接。若设worker_connections 32768，实际只能用到上限值，多余配置无效，还可能因争抢 fd 导致 accept 队列溢出。 -
启用连接复用与及时释放：
keepalive_timeout 15;
keepalive_requests 100;
reset_timedout_connection on;
避免长连接堆积；对上游代理，加proxy_http_version 1.1; proxy_set_header Connection '';复用后端连接。 -
监控真实 fd 使用量：
用lsof -p $(pgrep nginx | head -1) | wc -l查单 worker 当前 fd 数；
用ss -s看全系统 socket 统计；结合nginx -T | grep worker_connections核对配置一致性。
不要忽略上游与客户端行为
“too many open files” 往往不是 Nginx 自身代码缺陷，而是外部压力传导结果：
- 客户端短连接风暴（如爬虫、健康检查高频请求）→ 增加
limit_conn和limit_req控制速率 - 上游服务响应慢或超时未关闭 → 设置合理的
proxy_read_timeout、proxy_next_upstream timeout，启用proxy_buffering off（谨慎）加速释放 - 日志写入频繁（尤其 access_log 未缓冲）→ 启用
buffer=64k flush=5s或切到 syslog
