open_file_cache_errors需与open_file_cache及其max、inactive、valid、min_uses四项参数协同配置才生效，单独启用无效；它缓存“文件不存在”等错误结果，跳过磁盘查询和系统调用，从而降低404响应时延。

open_file_cache_errors 本身不消除时延，它让 Nginx 把“文件不存在”这个结论缓存起来，后续请求直接返回 404，跳过磁盘查询和系统调用——这才是时延下降的真正原因。它必须配合 open_file_cache 及其关联参数才能起效，单独启用无效。

必须配齐的基础配置

只写 open_file_cache_errors on; 没有任何作用。你需要在 http 或 server 块中同时设置：

• open_file_cache max=2000 inactive=30s; —— 提供缓存容器和淘汰机制，比如最多存 2000 条，30 秒未访问就可清理
• open_file_cache_valid 30s; —— 控制错误结果的有效期，404 状态只缓存 30 秒，之后重新检查磁盘
• open_file_cache_min_uses 2; —— 同一路径需在 30 秒内被访问至少 2 次，才把它的“不存在”状态记入缓存，避免单次探测污染缓存
• open_file_cache_errors on; —— 开启错误结果缓存，这是最终开关

哪些场景能明显见效

该配置对以下高频、固定、失败路径效果最突出：

• 爬虫或扫描器反复请求已下线的旧资源（如 /old-api.js、/wp-admin/）
• 前端构建后自动清理哈希文件，但 HTML 中仍残留旧引用（如 /static/app.a1b2c3.js 已删）
• 健康检查探针路径写错或临时未部署（如 /healthz 返回 404）
• 灰度发布中部分节点尚未同步静态资源，导致短暂 404

验证是否真正生效

它不写日志，但可通过系统行为判断：

• 用 perf stat -e syscalls:sys_enter_openat,syscalls:sys_enter_statx -p $(pgrep nginx) 压测同一 404 路径，开启前后系统调用次数应明显下降
• 开启 error_log /path/to/error.log debug; 后，会看到大量 open() "/xxx" failed (2: No such file or directory)；启用后这类日志大幅减少
• 执行 lsof -p $(pgrep nginx) | grep "No such file" 查不到结果是正常现象——说明 Nginx 已跳过真实打开，直接返回缓存错误

要注意的实际限制

它不是万能方案，使用时需规避几个典型风险：

• valid 时间不宜设过长（如超过 120s），否则新文件上线后用户仍要等很久才能看到 200
• 若业务存在动态路径（如带时间戳的调试 URL、A/B 测试路径），建议在对应 location 块中显式关闭：open_file_cache_errors off;
• 它会掩盖刚上传但缓存未刷新的问题，紧急恢复可用 nginx -s reload 清空整个缓存
• NFS 或容器挂载卷环境下，文件变更可能无法被 inotify 捕获，此时更依赖 valid 主动轮询，需确保 valid 值合理