nginx 的 open_file_cache 缓存文件元数据而非内容，无直接命中率指标；需通过减少 stat 调用、降低 i/o、提升小文件响应速度等间接方式验证其有效性，并排查权限、频繁变更、配置位置及缓存容量等失效原因。
注意：Nginx 本身没有“文件描述符缓存命中率”这个指标。你提到的其实是 open_file_cache 的缓存效果，它缓存的是文件元数据（如 inode、修改时间、权限、是否存在等），不是文件内容，也不产生类似 $upstream_cache_status 那样的 HIT/MISS 状态。它不叫“命中率”，更准确的说法是open_file_cache 的有效命中比例或复用效率——而这无法直接统计，只能通过间接方式评估是否生效、是否配置合理。
确认 open_file_cache 是否启用并生效
这是前提。未启用就无从谈“效果”：
- 在 http 或 server 块外（全局作用域）添加配置，例如：
open_file_cache max=5000 inactive=60s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on; - reload Nginx 后，检查错误日志：
tail -f /var/log/nginx/error.log，确认无 "open_file_cache is not enabled" 类报错 - 该缓存对所有静态文件服务（root/alias）起作用，无需在 location 中重复配置
观察系统级表现：间接验证有效性
因为 Nginx 不暴露 open_file_cache 的 HIT/MISS 计数，我们转而看它带来的实际收益：
- 减少 stat() 系统调用：用 strace -p $(pgrep nginx) -e trace=stat,openat -f 2>&1 | grep -c "stat" 对比启用前后单位时间内的 stat 调用次数 —— 显著下降说明缓存正在复用元数据
- 降低磁盘 I/O 压力：用 iostat -x 1 观察 %util 和 await，高并发静态请求下，启用后 await 应更平稳，尖峰减少
- 提升小文件响应速度：对大量小图、JS/CSS 的压测（如 wrk -t4 -c100 -d30s http://site/logo.png），对比启用前后的 p95 响应时间，通常可下降 5–15%
排查常见失效场景
很多情况下“看似没效果”，其实是被隐性绕过：
- 权限问题：Nginx worker 进程用户（如 www-data）对文件或父目录无读/执行权限 → 缓存会记录失败状态（因启用了 open_file_cache_errors on），后续请求仍反复 stat
- 文件频繁变更：若文件每秒都被构建工具覆盖（如 webpack watch），即使设置了 inactive=60s，也会因 open_file_cache_valid 检查发现 mtime 变化而失效
- 配置位置错误：写在 location 或 server 块内无效；必须放在 http 块之外、events 块之外的顶层作用域
- 缓存条目不足：max 值太小（如仅 100），在数千静态资源站点上迅速挤满，旧条目被轮替淘汰
替代方案：用 vmtouch 监控文件页缓存热度
真正影响读取性能的是内核 page cache（内存中缓存的文件内容页）。虽然这不是 Nginx 的 open_file_cache，但对静态文件性能更关键：
- 安装 vmtouch：apt install vmtouch（Debian/Ubuntu）
- 查看缓存目录整体热度：vmtouch /var/www/static/ → 显示 “Resident Pages” 占比，接近 100% 表示文件内容常驻内存
- 监控变化：watch -n 5 'vmtouch /var/www/static/ | grep Resident'
