nginx的open_file_cache缓存已打开的文件描述符（fd）、文件大小、修改时间、存在性与类型、权限检查结果及符号链接目标路径；需同时配置max、inactive、valid、min_uses、errors五项参数才生效。
Nginx 的 open_file_cache 不缓存文件内容，只缓存静态文件的描述符（fd）和元数据——比如文件是否存在、大小、最后修改时间（mtime）、权限状态、是否为目录或符号链接等。这些信息正是响应头（如 Content-Length、Last-Modified）和状态判断（如 404、403）所依赖的底层数据。缓存它们，就能跳过重复的 open() 和 stat() 系统调用，显著降低磁盘 I/O 和 CPU 开销。
它真正缓存的是什么
- 已打开的文件描述符（fd），实现句柄复用，避免反复
open()/close() - 文件大小、修改时间（用于生成
ETag和Last-Modified） - 存在性与类型（普通文件 / 目录 / 符号链接 / 不存在）
- 权限检查结果（是否可读，避免反复触发
EACCES） - 符号链接目标路径（需配合
open_file_cache_retest启用）
必须配齐五项参数才生效
单独写 open_file_cache on; 或只设 max 和 inactive 是无效的。以下五项需同时出现在 http 或 server 块中：
-
open_file_cache max=2000 inactive=30s;
最多缓存 2000 个条目；30 秒内无访问即标记为非活跃，等待清理 -
open_file_cache_valid 60s;
每 60 秒主动校验一次缓存项：文件是否还在、mtime 是否变化、权限是否仍有效 -
open_file_cache_min_uses 2;
同一文件需在inactive时间窗口内被访问 ≥2 次，才进入长期缓存，防冷数据污染 -
open_file_cache_errors on;
把ENOENT（404）、EACCES（403）等错误结果也缓存，避免恶意扫描或误配路径反复查磁盘 -
open_file_cache_events on;（推荐启用）
基于 inotify 实时监听文件变更，比轮询更及时；若系统不支持，可依赖valid轮询兜底
缓存生效的关键前提
- 必须放在
http或server块，不能写在location内 - 需搭配
worker_rlimit_nofile 65535;，否则缓存再多 fd 也无法实际打开 - 静态资源 location 中建议开启
sendfile on;，与 fd 缓存协同，让内核直接传输，绕过用户态拷贝 - 文件系统挂载时加
noatime，避免每次读取都更新访问时间，减少额外 I/O
验证是否起效
没有日志输出，但可通过以下方式确认：
-
lsof -p $(pgrep nginx) | wc -l：开启后，worker 进程打开的文件数应趋于稳定并明显下降 -
strace -e trace=open,stat,close -p $(pgrep nginx -w | head -1)：观察open()/stat()调用频次是否大幅减少 - 对比启用前后
perf stat -e syscalls:sys_enter_openat的系统调用计数
不复杂但容易忽略
