open_file_cache_errors的作用是缓存404/403等文件查找失败结果，使后续相同请求直接返回状态码、跳过stat()/open()系统调用；必须与open_file_cache、open_file_cache_valid、open_file_cache_min_uses协同配置才生效，缺一不可。
open_file_cache_errors 的作用不是“记录错误信息”，而是让 Nginx 把 文件查找失败的结果（如 404、403）缓存进内存，后续相同请求直接返回对应状态码，跳过 stat() 和 open() 系统调用——这才是真正加速拒绝的关键。
它不能单独启用，必须和 open_file_cache 机制协同工作。配置目标很明确：对高频但确实不存在的路径（比如扫描路径、下线资源、前端 fallback 路由），实现秒级响应、零磁盘开销。
必须配齐的四项基础配置
-
open_file_cache提供缓存容器，定义容量和淘汰规则 -
open_file_cache_valid控制错误结果的校验周期（即缓存多久后重新检查） -
open_file_cache_min_uses决定失败请求是否够格进入缓存（防单次探测污染） -
open_file_cache_errors on是最终开关，显式启用错误状态缓存
缺一不可，否则该指令完全不生效。
推荐配置写法（放在 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;
说明：
-
max=2000：最多缓存 2000 条记录（含成功与失败），适合中小规模静态服务 -
inactive=30s：一条记录若 30 秒内没被再次访问，就准备淘汰 -
valid=30s：每 30 秒主动验证一次缓存项是否仍有效（例如文件是否已被创建） -
min_uses=2：同一路径需在 30 秒内失败至少 2 次，才缓存其 404/403 状态
这个组合能有效拦截扫描流量（如 /wp-admin/、/phpmyadmin/），又不会因缓存太久影响上线调试。
哪些场景适合开启？哪些要慎用？
适合缓存错误的路径：
- 固定探测路径：
/healthz、/ping、/.git/config - 已下线旧资源：
/v1/api.js、/old-logo.png - SPA fallback 路由：配合
try_files $uri /index.html;时，大量前端路由命中但无对应文件
需在特定 location 中关闭的情况：
- 灰度发布或 A/B 测试目录（路径动态生成）
- 文件频繁被外部进程覆盖的目录（如日志输出路径）
- 刚上线新资源的调试阶段（可临时关掉
open_file_cache_errors验证）
怎么确认它真的起效了？
不用翻日志，看系统行为更准：
-
执行压测命令对比前后差异：
perf stat -e syscalls:sys_enter_openat,syscalls:sys_enter_statx -p $(pgrep nginx) -I 1000
对同一 404 路径连续请求，开启后
openat/statx系统调用次数应明显下降。 -
检查是否跳过真实打开：
lsof -p $(pgrep nginx) | grep "No such file"
如果几乎无输出，说明 Nginx 已不再尝试打开，直接返回缓存结果。
-
临时关闭
open_file_cache_errors并开启 debug 日志：error_log /var/log/nginx/error.log debug;
你会看到大量
open() "/xxx" failed (2: No such file or directory)；开启后这类日志大幅减少。
不复杂但容易忽略
