worker_rlimit_nofile是解决Nginx海量缓存文件读取时“Too many open files”错误的关键配置，需设于main上下文、协同系统级limits与systemd限制，并配合open_file_cache等调优。

在海量缓存文件读取场景下，Nginx 频繁打开静态资源（如图片、CSS、JS、模板片段等），每个文件、每个连接、每个 upstream socket 都会占用一个文件描述符。当缓存目录含数万小文件且并发请求密集时，“Too many open files” 错误极易触发，表现为 502、500 或日志中大量 open() failed (24: Too many open files)。仅调大 worker_connections 不够，必须从底层句柄容量入手——worker_rlimit_nofile 就是这个关键开关。

明确配置位置和数值逻辑

worker_rlimit_nofile 必须写在 nginx.conf 的最外层（main 上下文），也就是 events 块之前、http 块之外。它不是性能参数，而是进程级资源上限指令，语法简单：

• worker_rlimit_nofile 131072;（推荐值：128K～256K，适用于万级缓存文件+高并发）
• 该值不能超过系统对 nginx 用户设定的 硬限制（hard nofile），可通过 ulimit -Hn 查看
• 建议设为硬限制的 90% 左右，预留空间给访问日志、临时文件、SSL 会话缓存等

同步打通系统级限制链路

Nginx 无法突破启动时刻继承的系统限制。若只改配置不调系统，该指令将静默失效。需三处协同：

• /etc/security/limits.conf：添加两行（假设 Nginx 以 www-data 或 nginx 用户运行）
  www-data soft nofile 131072
www-data hard nofile 131072
• PAM 模块启用：确保 /etc/pam.d/common-session 包含
  session required pam_limits.so
• systemd 服务覆盖（若用 systemctl 管理）：创建 /etc/systemd/system/nginx.service.d/override.conf，内容为：
  [Service]
LimitNOFILE=131072

关联调优 events 参数与验证方式

句柄上限要能支撑实际连接与文件操作需求：

• worker_connections 应 ≤ worker_rlimit_nofile × 0.7（例如设 131072，则 worker_connections 建议 ≤ 90000），避免被日志、上游连接挤占
• 重启生效：必须 systemctl restart nginx（reload 不重置句柄限制）
• 验证是否落地：执行
  cat /proc/$(pgrep -f "nginx: worker" | head -n1)/limits | grep "Max open files"
  输出中 Soft Limit 应与配置值一致

缓存场景下的额外注意事项

海量小文件读取还会放大其他瓶颈：

• 确认内核参数 fs.file-max 足够（建议 ≥ 2× 句柄总需求），通过 sysctl -w fs.file-max=2097152 临时调整
• 避免使用 open_file_cache off；启用并合理设置缓存时效，减少重复 open/close：
  open_file_cache max=20000 inactive=60s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
• 若缓存由应用生成（如 Node 渲染后落盘），确保生成进程本身也配置了足够 ulimit -n，否则写入阶段就可能失败