nginx 默认关闭 open_file_cache，需手动配置以缓存文件元数据和描述符；推荐配置为 open_file_cache max=10000 inactive=60s; open_file_cache_valid 60s; open_file_cache_min_uses 2; open_file_cache_errors on。
安装 Nginx 后，默认的 open_file_cache 是关闭的，不会自动启用文件描述符缓存。这意味着每次处理静态文件（如 CSS、JS、图片）时，Nginx 都要重复执行 open()、stat() 等系统调用，增加磁盘 I/O 和 CPU 开销，尤其在高并发或小文件多的场景下影响明显。
open_file_cache 的核心作用
它缓存以下三类信息：
- 文件是否存在（open）、是否为目录、权限等元数据（通过
stat获取） - 打开文件后的文件描述符（fd），避免反复 open/close
- 符号链接的目标路径（若启用
open_file_cache_retest）
注意：它不缓存文件内容 —— 内容缓存由 sendfile、内核页缓存或第三方模块（如 ngx_http_fancyindex_module）负责。
推荐的基础启用配置（放在 http 块中）
以下配置适合大多数中小型静态资源服务场景（日均请求数万到百万级）：
open_file_cache max=10000 inactive=60s; open_file_cache_valid 60s; open_file_cache_min_uses 2; open_file_cache_errors on;
说明：
-
max=10000：最多缓存 10000 个条目，根据服务器内存调整（每个条目约占用 1KB，10000 条 ≈ 10MB） -
inactive=60s：若某文件在 60 秒内未被再次访问，就从缓存中移除 -
open_file_cache_valid 60s：每隔 60 秒重新检查缓存中所有条目的有效性（比如文件是否被删除或权限变更） -
min_uses 2：一个文件至少被访问 2 次才加入缓存，过滤掉一次性访问的冷文件 -
errors on：把“文件不存在”“权限拒绝”等错误也缓存起来，避免反复失败调用（需搭配valid使用才生效）
需要避开的常见误区
这些配置看似合理，但容易引发问题：
-
不要在 location 块里设置 open_file_cache：它只能出现在
http或server块顶层，location 中写会报错 -
避免 inactive 时间远大于 valid 时间：例如
inactive=300s; valid=30s可能导致已删除文件仍被缓存 5 分钟，返回 404 却不更新 -
动态内容站点慎用或禁用：如果后端频繁更新静态资源（如构建后覆盖 JS/CSS），且没配好缓存失效机制，用户可能看到旧文件或 404；此时建议配合版本号或哈希命名（如
app.a1b2c3.js）来规避 -
不替代真正的静态资源缓存策略：它优化的是“文件是否存在/能否打开”，不是“该不该返回 304”或“浏览器要不要重用”，HTTP 缓存头（
Cache-Control、ETag）仍需单独配置
验证是否生效的小技巧
可通过 Nginx 状态页（需编译时启用 --with-http_stub_status_module）或系统级观测确认：
- 开启 stub_status 后访问
/nginx_status，观察Active connections和Reading/Writing/Waiting数值变化趋势，配合压测看稳定性提升 - 用
strace -p $(pgrep nginx) -e trace=open,stat,close对比开启前后系统调用次数（注意仅用于调试，勿在生产长期运行） - 检查 error.log 是否出现大量
open() "/path/to/file" failed (2: No such file or directory)—— 若开启open_file_cache_errors on后此类日志显著减少，说明缓存已起效
