open_file_cache_errors 必须配合 open_file_cache、open_file_cache_valid、open_file_cache_min_uses 三项共同生效，用于缓存404/403等错误结果，使后续相同请求跳过磁盘查询、秒级返回状态码，显著降低系统调用开销。
开启 open_file_cache_errors 能直接让 Nginx 把“文件不存在”“权限拒绝”这类失败结果缓存进内存，后续相同请求跳过磁盘访问，秒级返回 404 或 403——这不是锦上添花，而是对抗恶意扫描、错误配置和高频探测的刚需配置。
必须配齐的四项基础指令
单独写 open_file_cache_errors on; 完全无效。它只是 open_file_cache 机制的组成部分，依赖以下四项协同生效：
-
open_file_cache：提供缓存容器，例如
max=2000 inactive=30s（限制条目数与淘汰窗口） -
open_file_cache_valid：控制错误结果的缓存有效期，建议设为
30s；太长（如 >120s）会导致刚上线的文件仍被误判为 404 -
open_file_cache_min_uses：同一路径需在
inactive周期内被访问 ≥2 次才进入缓存，防止单次探测污染缓存 - open_file_cache_errors on：显式启用错误状态缓存
典型配置示例（放在 http 或 server 块中）
适用于静态资源服务或代理模式下的 fallback 场景：
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
它真正解决什么问题
比如攻击者反复请求 /wp-admin/、/phpmyadmin/ 或爬虫扫大量已下线的旧路径，每次都会触发一次 stat() 和 open() 系统调用。开启后：
- 首次请求失败 → 记录“该路径不存在”到缓存
- 后续 30 秒内相同请求 → 直接返回 404，不碰磁盘、不走文件系统
- 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)；开启后这类日志大幅减少
