open_file_cache_errors 要生效必须与 open_file_cache、open_file_cache_valid、open_file_cache_min_uses 同时配置；典型组合为 max=2000 inactive=30s、valid=30s、min_uses=2、errors on；它缓存“文件不存在”状态以减少系统调用，但需权衡时效性。
要让 open_file_cache_errors 真正缓存“文件不存在”这类状态、从而减少无效的 open() 和 stat() 系统调用，关键不是单独开启它，而是把它作为 open_file_cache 整体机制中的一环来配置——它本身不独立工作，必须依赖缓存容器和校验规则才能生效。
必须配齐的基础指令
这四项需同时出现在 http 或 server 块中，缺一不可：
-
open_file_cache：提供缓存空间和淘汰逻辑，例如
max=2000 inactive=30s -
open_file_cache_valid：控制错误结果（如 404）缓存多久，建议设为
30s，兼顾响应及时性与系统开销 -
open_file_cache_min_uses：避免偶然请求污染缓存，设为
2表示同一路径需在inactive时间内失败两次才被缓存 - open_file_cache_errors on：显式启用错误状态缓存
典型配置示例
适用于大多数静态资源服务场景：
open_file_cache max=2000 inactive=30s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
说明：
– 高频探测路径（如 /healthz）或已下线的旧资源（如 /v1/old-api.js）会快速满足 min_uses=2，进入错误缓存
– valid=30s 意味着即使文件随后被创建，最多等待 30 秒就能刷新状态，不影响上线调试
验证是否真正起效
它不写日志，但可通过系统行为确认：
- 用
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 ... debug，可观察到大量open() "/xxx" failed (2: No such file or directory)日志；开启后这类日志应大幅减少
使用时需注意的边界情况
这个功能提升性能的同时也引入了时效性权衡：
- 刚上传文件但缓存尚未刷新时，用户仍看到 404；此时可将
valid缩短至10s加快感知 - 灰度发布、动态路径生成等场景建议在对应
location块中禁用：open_file_cache_errors off - 它缓存的是“错误状态”，不是日志记录——排查问题时需配合 debug 日志，不能仅靠缓存状态反推路径
