open_file_cache_errors需与open_file_cache、open_file_cache_valid、open_file_cache_min_uses协同配置才生效，用于缓存404/403错误状态以跳过重复磁盘查询；单独启用无效。
open_file_cache_errors 本身不单独起作用，它必须和 open_file_cache 及其配套参数一起配置，才能缓存“文件不存在”（404）、“权限拒绝”（403）这类错误状态，跳过重复的磁盘查询。
为什么需要它
当 Nginx 收到对一个根本不存在路径（如 /old-logo.png、/wp-config.php.bak）的请求时：
- 若未启用该机制，每次请求都会真实执行
open()和stat()系统调用 → 失败 → 返回 404； - 高频扫描或配置残留路径会迅速引发大量无效 I/O，拖慢 worker 进程响应。
开启后，Nginx 把“该路径查无此文件”这个结论记进内存，在有效期内直接返回 404，完全跳过系统调用。
必须配合的四项基础配置
缺一不可，全部放在 http 或 server 块中：
open_file_cache max=2000 inactive=30s;
提供缓存容器：最多存 2000 条，30 秒内没被访问就准备淘汰。open_file_cache_valid 30s;
控制错误结果的有效期：30 秒后重新检查一次文件是否存在（不是永久缓存）。open_file_cache_min_uses 2;
同一路径需在inactive时间窗内出现至少 2 次失败请求，才进入缓存；防偶然扫描污染缓存。open_file_cache_errors on;
显式启用错误状态缓存（404 / 403 等），这是最终开关。
✅ 正确示例：
http { open_file_cache max=3000 inactive=30s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; }
怎么验证是否生效
它不写日志，但可通过系统行为判断：
-
用
perf stat对比开启前后系统调用次数：perf stat -e syscalls:sys_enter_openat,syscalls:sys_enter_statx -p $(pgrep nginx) -I 1000
压测同一 404 路径，开启后
openat/statx次数应明显下降。 -
用
lsof查看 Nginx 是否还在反复尝试打开：lsof -p $(pgrep nginx) | grep "No such file"
开启后几乎看不到这类输出，说明已跳过真实磁盘访问。
-
临时关闭
open_file_cache_errors并开启 debug 日志：error_log /var/log/nginx/error.log debug;
你会看到大量
open() "/xxx" failed (2: No such file or directory)；开启后这类日志大幅减少。
使用注意事项
缓存的是“错误状态”，不是“日志记录”——Nginx 不告诉你哪个路径被缓存了，排查问题时得关掉它 + 开 debug。
文件刚上传但缓存里还记着“不存在”，用户会短暂看到 404；此时可把
open_file_cache_valid调小（如10s）加快感知。-
若业务有灰度发布、动态路径生成（如带时间戳的调试 URL），建议在对应
location中显式关闭：location ~* \.debug\.js$ { open_file_cache_errors off; } 它适合稳定路径结构的生产环境，不适合频繁变更元数据且要求强一致性的开发调试场景。
