open_file_cache需max、inactive、valid、min_uses、errors五项参数协同配置才生效，专为高频小文件缓存文件描述符及元数据（大小、mtime、错误状态等），不缓存内容，可显著降低open()/stat()系统调用开销。

open_file_cache 不是开个开关就起效的机制，它必须在 http 块（即全局 HTTP 配置层）中用五个参数协同配置，才能真正缓存文件描述符、减少 open() 和 stat() 系统调用，从而提升高频小文件（如 index.html、图标、健康检查端点）的访问效率。

它不缓存文件内容，只缓存：

• 文件描述符（fd）
• 文件大小、修改时间、权限等元数据
• “文件不存在”“权限拒绝”等错误状态（需显式启用）

---

✅ 必须配齐的五项参数（缺一不可）

open_file_cache 的作用依赖完整策略闭环，单独写 open_file_cache on; 完全无效：

• max=N
  缓存条目上限，建议按并发请求数 × 平均静态路径数预估。过高（如 >20000）可能引发共享内存锁争用。

• inactive=time
  条目空闲超时时间。60 秒是默认值，但对高密访问场景（如 /healthz），可设为 20s 或 30s，加快复用节奏。

• open_file_cache_valid=time
  主动校验周期。每过这个时间，Nginx 扫描缓存项，检查文件是否仍存在、mtime 是否变化。推荐 30s，避免 valid 过长导致返回过期 404 或旧内容。

• open_file_cache_min_uses=N
  准入门槛。同一文件需在 inactive 时间窗口内被访问 ≥ N 次才进缓存。设为 2 可过滤偶然请求；若路径极固定（如网关探针），也可设 1。

• open_file_cache_errors on
  启用错误缓存。把 ENOENT（404）、EACCES（403）结果也记入缓存，防止反复触发磁盘查询。生产环境强烈建议开启。

⚠️ 注意：只要这五项都存在，缓存自动激活，无需额外写 open_file_cache on;

---

? 推荐的全局 http 块配置示例

http {
    # 高频小文件通用型（适合静态资源服务 + 探针混合场景）
    open_file_cache max=5000 inactive=60s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    # 其他必要协同配置（非 open_file_cache 本身，但影响最终效果）
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # 静态资源 location 中建议关闭无关日志
    log_not_found off;
    access_log off;

    # … 其余配置（mime、server 块等）
}

---

? 怎么确认它真正在工作？

没有直接日志输出，但可通过系统指标验证：

• 查看 worker 进程打开的文件数是否收敛稳定：
  lsof -p $(pgrep nginx) | wc -l
  开启后应明显低于未启用时，且波动变小。

• 对比 openat 和 statx 系统调用次数：
  perf stat -e syscalls:sys_enter_openat,syscalls:sys_enter_statx -p $(pgrep nginx)
  理想情况下，第二次访问同文件时这两类调用应下降 50% 以上。

---

? 小提醒：别忽略底层配合

• 文件系统挂载建议加 noatime：mount -o remount,noatime /path，避免每次读取都更新访问时间戳。
• 若静态资源由 location ~* \.(js|css|png)$ 匹配，确保该块内没意外覆盖 open_file_cache 设置（它继承自上层 http 块，除非被显式重置）。

不复杂但容易忽略