open_file_cache_errors 的核心作用是缓存文件不存在（404）、权限不足（403）等错误结果，避免重复系统调用；需配合 open_file_cache、open_file_cache_valid 和 open_file_cache_min_uses 才生效，适用于哈希资源清理、爬虫扫描等场景。
open_file_cache_errors 的核心作用，是让 Nginx 把“文件不存在”（404）、“权限不足”（403）这类错误结果也缓存起来，避免在短时间内反复执行 open() 或 stat() 系统调用去确认同一个路径是否真的不可用。
它怎么减少系统调用损耗
当一个请求访问某个静态资源（比如 /assets/logo.png），而该文件实际已被删除或路径写错时：
- 若
open_file_cache_errors off（默认关闭），每次请求都会真实触发一次磁盘 I/O 检查：尝试打开文件 → 失败 → 返回 404；重复 100 次，就是 100 次失败的系统调用。 - 若
open_file_cache_errors on，且已启用open_file_cache，Nginx 会在首次失败后把“此路径不存在”这个结果缓存起来；后续请求在缓存有效期内（由open_file_cache_valid控制）直接返回 404，跳过所有磁盘操作。
必须搭配的基础配置才能生效
单独写 open_file_cache_errors on; 是无效的——它依赖 open_file_cache 提供的缓存机制。你需要至少配置这三项：
-
open_file_cache max=5000 inactive=60s;：启用缓存，限制容量和淘汰策略 -
open_file_cache_valid 30s;：决定错误结果缓存多久（不是永久！30 秒后会重新检查） -
open_file_cache_min_uses 2;：虽对错误缓存影响不大，但能避免偶然性 404 占满缓存
完整示例（放在 http 块中）：
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
适合开启的典型场景
- 前端资源使用哈希命名（如
app.a1b2c3.js），旧版本文件被清理后，大量 404 请求集中涌入 - CDN 回源时携带了错误路径参数，或爬虫扫描大量无效路径
- 软链接目标被临时移除、权限被临时收紧等短暂性问题，不希望每秒都触发磁盘探测
需要注意的风险点
- 缓存的是“错误状态”，不是日志——Nginx 不会记录“哪个路径被缓存为 404”，排查需关掉该指令 + 开 debug 日志
- 如果文件刚被创建，但缓存里还记着“不存在”，用户会短暂看到 404；此时可缩短
open_file_cache_valid（如设为 10s）加快感知 - 配合
open_file_cache_events on（需内核支持 inotify）可更及时感知文件恢复，但多数生产环境仍以valid轮询为主
