Nginx反向代理缓存高效运行的关键起点是proxy_cache_path配置，需在http块中定义缓存路径、levels目录结构、keys_zone内存索引区、max_size磁盘上限、inactive淘汰时长及use_temp_path=off优化写入。
要让 Nginx 的反向代理缓存真正高效、稳定地运行，proxy_cache_path 是最关键的配置起点。它不只是指定“把缓存存哪儿”，更决定了缓存如何组织、怎么查、何时删、能撑多大——每个参数都直接影响性能和可靠性。
path 与 levels：缓存文件怎么分目录存？
缓存路径（如 /var/cache/nginx/proxy_cache）必须提前创建，并确保 Nginx 工作进程（如 www-data 或 nginx 用户）有读写权限。单纯把所有缓存文件堆在一个目录里，当文件数超几万时，文件系统查找效率会急剧下降。
levels 就是解决这个问题的核心——它控制缓存文件的嵌套层级和每级目录名长度：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
levels=1:2最常用：取缓存 key 的 MD5 哈希值，最后 1 位做第一级目录（共 16 个可能值），再往前取 2 位做第二级目录（共 256 种组合），剩余部分作文件名。最终路径类似/path/f/3a/abc123... -
levels=2等价于levels=2:2:2，但 Nginx 实际只建两级；levels=1:1:1理论上生成 4096 个一级目录，但单目录仍易堆积，不推荐 - 建议优先用
levels=1:2：平衡性好，适配大多数业务规模
keys_zone：内存里怎么快速找缓存？
keys_zone 是必填项，格式为 名称:大小（如 my_cache:10m）。它不存响应体，只在共享内存中维护缓存 key、状态、过期时间等元数据，用于极速判断是否命中。
- 1MB 内存约支持 8000 个缓存条目，10m ≈ 8 万个活跃 key
- 名称（如
my_cache）需与后续proxy_cache my_cache中的名称严格一致 - 重启后该区域清空，但磁盘缓存文件仍有效，Nginx 启动时会重新加载索引
inactive 与 max_size：缓存什么时候删、删多少？
这两个参数共同构成缓存的生命周期管理机制，作用不同但需协同使用：
-
inactive=60m：某缓存条目在 60 分钟内完全没被访问过，就立即清理——不管它是否还在有效期内（proxy_cache_valid定义的） -
max_size=1g：整个缓存目录最多占用 1GB 磁盘空间；超出后按 LRU（最近最少使用）策略自动淘汰旧文件 - 注意：
max_size不是硬限制——达到上限后 Nginx 暂停写新缓存，直到空间释放；因此建议搭配合理的inactive值，避免缓存长期淤积
use_temp_path=off：为什么建议关掉临时路径？
默认情况下，Nginx 先把缓存内容写入临时路径（如 /tmp/nginx/proxy_temp），再移动到最终缓存目录。这会带来额外 I/O 和跨文件系统拷贝风险（尤其当 temp_path 和 cache_path 不在同一磁盘时）。
-
use_temp_path=off让 Nginx 直接将缓存文件写入目标路径，减少一次拷贝，提升写入效率 - 前提是确保缓存路径所在磁盘有足够空间和良好 I/O 性能（SSD 更佳）
- 生产环境强烈建议显式设为
off
