open_file_cache_errors on 的作用是缓存404、403等错误结果，避免重复磁盘查询；必须与max、inactive、valid、min_uses四项参数协同配置于http块中才生效，单独使用无效。
open_file_cache_errors on 的作用是让 Nginx 把“文件不存在（404）”“权限不足（403）”这类查找失败的结果也缓存起来，避免反复触发系统调用去确认同一个无效路径——这对拦截恶意扫描、降低磁盘元数据压力非常有效。
为什么必须配合其他参数一起用
单独写 open_file_cache_errors on; 不会生效。它只是整个缓存机制的一环，依赖以下四项协同工作：
-
max=：设定缓存总容量（含成功+失败条目），比如
max=5000表示最多存 5000 条记录 -
inactive=：定义“冷数据”淘汰窗口，如
inactive=60s表示 60 秒内没被访问就准备清理 -
open_file_cache_valid：定期主动验证缓存有效性，例如
open_file_cache_valid 30s每 30 秒检查一次文件是否已被创建或权限是否变更 -
open_file_cache_min_uses：控制错误是否值得缓存，比如
min_uses=2表示同一路径在inactive时间内至少失败 2 次才记入缓存，防止单次误访污染缓存
怎么写才真正起效
配置必须放在 http 块中，全局生效。不要写在 server 或 location 里——Nginx 不支持局部启用该缓存。
一个稳妥的中小规模静态服务配置示例：
http {
open_file_cache max=2000 inactive=30s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
}
这个组合能快速识别并缓存常见扫描路径（如 /wp-admin/、/phpmyadmin/），后续请求直接返回 404，不再访问磁盘。
缓存错误状态的实际效果
开启后，Nginx 对无效路径的处理逻辑变成：
- 第一次访问
/xxx.php（实际不存在）→ 触发stat()→ 返回 404，并记录“失败一次” - 30 秒内再次访问同一路径 → 失败次数达
min_uses阈值 → 缓存该 404 状态 - 第三次及之后访问 → 直接从内存读取“不存在”，跳过所有系统调用
尤其适合防御目录爆破、CMS 路径探测等低价值高频请求，显著减少 openat 和 stat 系统调用次数。
怎么确认它真正在工作
通过自定义日志格式观察命中情况：
log_format cache_log '... ofc_hit:$open_file_cache_hits ofc_miss:$open_file_cache_misses';
如果日志中 ofc_miss 明显下降、ofc_hit 持续上升，且 404 请求响应时间变短，说明错误缓存已生效。也可用 lsof -p $(pgrep nginx) 查看 worker 进程打开文件数是否收敛，间接验证缓存减少了重复打开操作。
