open_file_cache_retest 是 nginx 文件状态缓存中条目重新验证的间隔时间，决定再次访问时是否触发 stat() 检查文件变更；用于平衡缓存时效性与系统开销，需结合 open_file_cache_valid、inactive 等指令协同配置。
open_file_cache_retest 是 Nginx 中用于控制文件状态缓存（open_file_cache）中条目是否需要重新验证的间隔时间。它不直接决定“检测频率”，而是设定：当一个缓存中的文件条目被再次访问时，若距离上次检查已超过该值，Nginx 才会触发一次 stat() 系统调用，确认文件是否存在、是否被修改、权限是否变化等。
它解决什么问题？
启用 open_file_cache 后，Nginx 会缓存文件元信息（如 inode、大小、mtime、权限），避免每次请求都调用 stat()。但若后端文件被外部程序（如部署脚本、CI/CD）动态更新，缓存可能过期，导致返回旧内容或 404。而设得太短，又会让 stat() 频繁触发，增加磁盘 I/O 和系统调用开销——尤其在高并发静态资源场景（如图片站、CDN 边缘节点）下尤为明显。
如何设置合理的 retest 值？
关键不是“越小越好”或“越大越好”，而是匹配你的文件变更模式和业务容忍度：
-
静态资源几乎不变（如 CDN 分发的版本化 JS/CSS）：可设为
600（10 分钟）甚至3600（1 小时）。文件名含哈希，变更即新路径，缓存无需频繁刷新。 -
定期发布、有灰度窗口（如每日凌晨更新图片库）：设为
300（5 分钟）较稳妥。确保上线后几分钟内用户能命中新文件，同时避免每秒都 stat。 -
热更新敏感型场景（如运营后台可实时替换 banner 图）：建议
30–60，并配合open_file_cache_valid（缓存条目有效时间）一起调小，但需监控sysstat中的%iowait和syscalls:sys_enter_stat频次。
必须配合的关键指令
open_file_cache_retest 单独生效的前提是缓存本身已启用且条目未过期：
-
open_file_cache max=10000 inactive=60s;：定义缓存容量与非活跃条目淘汰时间。若inactive过短（如 10s），文件刚缓存就淘汰，retest几乎不触发。 -
open_file_cache_valid 30s;：决定缓存条目元信息的“保质期”。即使retest未到，只要超过valid时间，下次访问仍会强制 stat。 -
open_file_cache_min_uses 2;：防止低频文件反复进出缓存。建议 ≥2，避免单次访问就进缓存、很快又被踢出。
验证与观测方法
不要凭感觉调参，用真实指标判断效果：
- 用
perf record -e syscalls:sys_enter_stat -p $(pidof nginx)抓取 30 秒，再perf report查看 stat 调用次数；对比不同retest值下的下降幅度。 - 观察
nginx -T | grep open_file_cache输出，确认配置已加载；检查 error log 是否有open file cache limit reached，说明max设小了，导致缓存抖动，抵消 retest 效果。 - 对关键静态路径（如
/static/）开启log_format记录$request_time和$upstream_response_time，若后者显著波动，可能因频繁 stat 引起延迟毛刺。
