必须开启 open_file_cache_errors，因为它能将“文件不存在”等错误状态缓存到内存，避免重复系统调用；需配合 open_file_cache、open_file_cache_valid 和 open_file_cache_min_uses 三项使用。

直接缓存“文件不存在”这类错误状态，能显著减少恶意扫描或配置错误导致的重复系统调用。open_file_cache_errors 不是锦上添花的选项，而是高频小文件服务中防抖、降负载的关键一环。

为什么必须开启 open_file_cache_errors

当 Nginx 收到对一个根本不存在路径（如 /favicon.ico.malware、/wp-admin/）的请求时，若未启用该指令，每次请求都会触发一次 open() 和 stat() 系统调用——即使结果永远是 404。大量此类请求会快速拖垮磁盘 I/O 和内核调度开销。

开启后，Nginx 会把“路径不存在”“权限拒绝（403）”等失败结果也记入内存缓存，后续相同请求直接返回对应状态码，跳过所有底层文件系统访问。

必须搭配的前置条件

该指令单独存在无效，需与以下三项共存才能生效：

• open_file_cache 已启用（即配置了 max 和 inactive）
• open_file_cache_valid 设置合理（建议设为 30s，用于定期验证缓存项是否仍有效）
• open_file_cache_min_uses ≥ 1（默认为 1，但显式写上更稳妥；它控制“失败请求是否也参与准入”，配合 errors 使用时建议保持为 1 或 2）

典型配置示例与说明

在 http 或 server 块中写入：

open_file_cache max=3000 inactive=30s;<br>open_file_cache_valid 30s;<br>open_file_cache_min_uses 1;<br>open_file_cache_errors on;

说明：

• 缓存最多 3000 个条目，含成功和失败记录
• 30 秒内未被访问的条目（无论成败）自动淘汰
• 每 30 秒检查一次缓存中的路径是否已被创建或权限变更（例如原本 404 的文件后来被上传了，缓存会及时更新）
• min_uses 1 表示哪怕只发生一次 404，也允许进入缓存（适合拦截扫描类流量）

效果验证方式

无法从 access_log 直接看出，但可通过系统级指标确认：

• 运行 lsof -p $(pgrep nginx) | wc -l：开启前后对比，打开文件数应明显收敛、不再随请求数线性增长
• 用 perf stat -e syscalls:sys_enter_openat -p $(pgrep nginx) 抓取 10 秒内 openat 调用次数：开启后通常下降 40%–70%，尤其在存在大量 404 的场景下效果突出
• 观察 nginx -t && nginx -s reload 后首次访问 404 路径耗时是否略高（因首次需探测并缓存），之后同路径响应时间趋近于内存查表级别（微秒级）