Nginx 如何在 Server 块中配置开启 open_file_cache 缓存文件元数据

直接在server块配置open_file_cache及配套五参数（max、inactive、valid、min_uses、errors）可复用文件描述符并缓存元数据，跳过stat()/open()调用以降I/O与CPU开销；必须全配且仅支持http/server作用域，不可置于location内。

直接在 server 块里配置 open_file_cache 及其配套参数，就能让该虚拟主机的静态文件服务复用文件描述符、缓存元数据（如是否存在、大小、修改时间、权限），从而跳过大量 stat() 和 open() 系统调用，降低 I/O 和 CPU 开销。

必须同时写全五项参数，缺一不可。只写 open_file_cache on; 或漏掉任意一项，配置都不生效。

注意：不能放在 location 块内，只支持 http 或 server 作用域。

H3 配置位置与基本结构

把以下四行完整写入目标 server 块内部（通常放在 root、index 等指令附近）：

open_file_cache max=5000 inactive=60s;open_file_cache_valid 30s;open_file_cache_min_uses 2;open_file_cache_errors on;

1. max=5000 控制最多缓存 5000 个文件的元信息和句柄，适合中等规模静态资源站点
2. inactive=60s 表示一条缓存记录若 60 秒内未被再次访问，就标记为待清理
3. open_file_cache_valid 30s 指每 30 秒主动检查一次缓存项是否仍有效（比如文件是否被删或改名）
4. open_file_cache_min_uses 2 要求同一文件在 inactive 时间窗口内至少被访问 2 次才进入长效缓存，防爬虫或临时路径污染
5. open_file_cache_errors on 把 404、403 这类错误结果也缓存住，避免反复探测无效路径触发系统调用

H3 为什么推荐放在 server 块而不是 http 块

1. 多个 server 对应不同域名或静态资源分布时，全局 http 块的缓存容易混杂无关路径
2. 单独在 server 中配置，可按需差异化设置：比如一个 CDN 回源站设 max=10000，另一个管理后台静态资源少，设 max=2000
3. 缓存只作用于该 server 下所有真实文件路径（包括 root、alias、try_files 解析出的最终路径）

H3 必须配合的关键协同项

光配 open_file_cache 不够，还需确保：

1. sendfile on; 已启用——它依赖内核 page cache，而 page cache 的有效性与 open_file_cache 维护的 inode 状态强相关
2. 静态资源尽量用前缀匹配 location /static/ { ... }，避免正则匹配带来的额外路径解析开销
3. 关闭非必要日志：access_log off; 或 log_not_found off;，防止日志写入本身成为 inode 访问热点
4. 若启用 open_file_cache_events，需检查并调高系统 inotify 限制：fs.inotify.max_user_watches，否则可能报 “could not build optimal open_file_cache”

H3 如何验证是否生效

添加自定义日志格式，利用内置变量统计命中情况：

log_format ofc_log '$remote_addr - $remote_user [$time_local] ''"$request" $status $body_bytes_sent ''ofc_hit:$open_file_cache_hits ofc_miss:$open_file_cache_misses';access_log /var/log/nginx/ofc.log ofc_log;

观察日志中 ofc_hit 与 ofc_miss 的比值，稳定在 80% 以上说明缓存已高效运行。