Nginx http块open_file_cache_errors配置详解
open_file_cache_errors控制Nginx是否缓存文件访问错误(如403/404),启用后在有效期内重复错误直接返回缓存结果,减轻I/O压力;必须配合open_file_cache使用,过期由open_file_cache_valid控制。
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使用更稳妥——只缓存被多次访问(含失败)的文件项,减少误伤


































