open_file_cache_errors 控制Nginx是否缓存文件访问错误（如403/404），启用后在有效期内重复错误直接返回缓存结果，减轻I/O压力；必须配合open_file_cache使用，过期由open_file_cache_valid控制。

open_file_cache_errors 并不是用来“记录失效”的指令，它控制的是：当 open_file_cache 启用时，Nginx 是否将**文件访问错误（如权限拒绝、文件不存在等）也缓存起来**。

它的作用是缓存“错误结果”，而非记录日志

启用后，如果 Nginx 尝试打开某个文件失败（例如 403 Forbidden 或 404 Not Found 对应的磁盘路径不可读），且该错误在缓存有效期内重复发生，Nginx 就不再真实访问文件系统，而是直接返回缓存的错误状态。这能减轻磁盘 I/O 和系统调用开销，但会掩盖临时性问题（比如刚创建文件但缓存未更新）。

常见配置组合与注意事项

• 必须配合 open_file_cache 使用：单独设置 open_file_cache_errors on; 无效，因为没有基础缓存机制
• 典型搭配示例：

  open_file_cache          max=1000 inactive=60s;
  open_file_cache_valid    60s;
  open_file_cache_min_uses 2;
  open_file_cache_errors   on;

• 错误缓存也有过期时间：受 open_file_cache_valid 控制，不是永久缓存。60 秒后会重新检查文件状态
• 若关闭该选项（off），每次遇到文件访问失败都会重新触发系统调用，适合调试或文件状态变化频繁的场景

为什么你可能觉得“记录失效”？

容易混淆的点在于：Nginx 不会把错误写入 error_log 或 access_log；它只是内部跳过真实检查。如果你期望看到“哪个文件被缓存为错误”，Nginx 默认不输出这类信息。要排查，可临时关闭 open_file_cache_errors，并开启 debug 日志（error_log /path/to/log debug;），观察 file I/O 相关行。

实用建议

• 生产环境静态资源稳定时，建议开启 on，提升性能
• 开发或部署脚本频繁变更文件权限/路径时，建议设为 off，避免因缓存错误导致请求异常难以定位
• 配合 open_file_cache_min_uses 使用更稳妥——只缓存被多次访问（含失败）的文件项，减少误伤