open_file_cache通过缓存文件元数据和句柄，跳过stat()和open()系统调用，避免磁盘查找；需同时配置max、inactive、valid、min_uses及errors四项参数，并配合系统限制与try_files优化才能生效。

open_file_cache 通过把文件元数据和句柄“记进内存”，让 Nginx 跳过反复调用内核的 open() 和 stat() 系统调用，从而直接避免磁盘查找。它不读文件内容，只缓存“这个路径是否存在”“是不是目录”“大小多少”“权限如何”这些判断结果——而这些正是每次请求都要查磁盘的关键动作。

缓存什么，跳过什么

每次请求静态资源时，Nginx 默认需执行以下内核操作：

• 调用 stat() 查文件是否存在、是否为目录、mtime、权限等；
• 若存在且可读，再调用 open() 获取文件描述符（fd）；
• 若路径是目录且启用了 index，还会额外尝试拼接 /index.html 并重复上述两步。

open_file_cache 把这些结果缓存在内存中。后续相同路径的请求，直接复用缓存值，完全绕过磁盘访问。

必须配齐的四项核心参数

单独写 open_file_cache on; 无效。以下四项需同时配置在 http 块中：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 容量与淘汰：open_file_cache max=10000 inactive=60s; —— 最多缓存 1 万个条目；60 秒内未被访问则标记为待清理
• 主动校验：open_file_cache_valid 60s; —— 每 60 秒检查一次缓存项对应文件是否仍存在、是否被修改，防止返回过期状态
• 准入门槛：open_file_cache_min_uses 2; —— 同一路径需在 inactive 时间窗内被访问至少 2 次才进入缓存，过滤偶然请求（如爬虫乱扫）
• 错误也缓存：open_file_cache_errors on; —— 把 “404 文件不存在”“403 权限拒绝” 等结果也记下来，避免同一非法路径反复触发磁盘查询

配合系统限制才能真正生效

光配 Nginx 不够，底层必须跟得上：

• 确认 worker_rlimit_nofile 足够大（建议 ≥ 65535），否则缓存了 fd 也打不开
• 若启用 open_file_cache_events on;（依赖 inotify），需检查 /proc/sys/fs/inotify/max_user_watches 是否 ≥ 缓存条目数 × 1.5；否则 nginx -t 会报 “could not build optimal open_file_cache”
• 避免在日志路径、上传目录、模板目录等非服务路径中意外触发缓存，防止缓存污染

搭配 try_files 减少隐式查找

当 index 和 try_files 同时存在时，Nginx 会先按 index 规则探测（触发多次 stat），再走 try_files fallback（可能再触发一次 open）。改用：

try_files $uri $uri/ /index.html;

显式接管逻辑，让目录存在性判断也落入 open_file_cache 范围，进一步压缩磁盘查找次数。