open_file_cache_errors 的作用是缓存403/404等错误结果以跳过系统调用，必须与open_file_cache等指令配合使用，单独启用无效。
open_file_cache_errors 的作用不是“记录错误”，而是把“文件不存在（404）”“权限拒绝（403）”这类失败结果缓存进内存，让后续相同请求直接返回对应状态码，跳过 open()、stat() 等系统调用——这才是降低无效内核查询的关键。
必须搭配 open_file_cache 才能生效
单独写 open_file_cache_errors on; 完全无效。它只是 open_file_cache 机制的组成部分，依赖以下基础配置共存：
-
open_file_cache max=2000 inactive=30s;—— 提供缓存容器和淘汰规则 -
open_file_cache_valid 30s;—— 控制错误结果的校验周期（比如 404 缓存 30 秒后重新检查文件是否存在） -
open_file_cache_min_uses 2;—— 同一路径需在inactive时间窗内重复失败至少 2 次才进入缓存（适合拦截扫描类流量）
典型配置示例（推荐用于静态资源服务）
放在 http 或 server 块中即可：
open_file_cache max=2000 inactive=30s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
说明：
- 高频探测路径（如
/healthz）、固定失效路径（如/old-api.js）容易快速满足min_uses=2，被缓存为 404 -
valid=30s意味着即使文件后来被创建，最多等待 30 秒就能更新状态，兼顾性能与一致性 - 不建议将
valid设得过长（如 >120s），否则可能长期返回过期的 404，影响上线调试
验证是否真正起效
它不会写日志，但可通过系统行为观察：
- 用
perf stat -e syscalls:sys_enter_openat,syscalls:sys_enter_statx -p $(pgrep nginx)压测同一 404 路径，开启前后对比系统调用次数应明显下降 - 用
lsof -p $(pgrep nginx) | grep "No such file"查不到结果是正常现象——说明 Nginx 已跳过真实打开，直接返回缓存错误 - 临时关闭
open_file_cache_errors并开启error_log /path/to/log debug;，可看到大量open() "/xxx" failed (2: No such file or directory)日志；开启后这类日志会大幅减少
使用注意事项
这个功能适合路径结构稳定的生产环境，但要注意：
- 会掩盖临时性问题，比如刚上传文件但缓存还没刷新，用户仍看到 404
- 若业务存在大量动态生成路径或灰度发布场景，建议在对应
location块中禁用：open_file_cache_errors off; - 错误缓存的生命周期由
open_file_cache_valid统一控制，没有独立超时参数
