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，跳过磁盘查询。
必须配齐的基础配置
只写 open_file_cache_errors on; 没有效果。以下四项需同时出现在 http 或 server 块中：
- open_file_cache max=2000 inactive=30s;——提供缓存容器和淘汰机制，比如最多存 2000 条，30 秒未访问就清理
- open_file_cache_valid 30s;——控制错误结果的缓存有效期，404 状态最多缓存 30 秒，之后重新检查文件是否存在
- open_file_cache_min_uses 2;——同一路径需在 inactive 时间窗内被请求至少 2 次才进入缓存，防恶意扫描或临时路径占位
- open_file_cache_errors on;——启用对 404、403 等失败结果的缓存
适合缓存 404 的典型场景
不是所有路径都适合缓存错误，重点用于稳定、高频但确实不存在的路径：
- 固定探测路径，如
/healthz、/ping（Nginx 自身不提供，但客户端高频请求） - 已下线的旧资源路径，如
/old-api.js、/v1/users - 前端路由 fallback 中可能命中但服务端无对应文件的路径（配合
try_files $uri /index.html;时尤其明显）
避免缓存干扰上线调试
缓存 404 虽能降系统调用，但也可能掩盖部署问题：
- valid 值不宜设过大（例如超过 120 秒），否则文件已上传成功，用户仍持续看到 404 长达两分钟
- 若业务存在灰度发布、A/B 测试或动态路径生成，建议在对应
location块中显式关闭：open_file_cache_errors off; - 紧急恢复时，执行
nginx -s reload可立即清空全部缓存，比等待自然过期更快
验证是否真正起效
它不写专门日志，但可通过系统行为判断：
- 开启前后，用
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)日志；开启后这类日志会大幅减少
