关键不是设统一时间，而是按状态码分层设置：200/304/206缓存1h～1d，301/302设10m～1h，404设10s～1m，5xx设10s～30s，慎用any兜底，并通过location层级和proxy_ignore_headers精准控制。

靠 proxy_cache_valid 提升缓存利用率，关键不是设一个统一时间，而是让不同响应“各得其所”：该长缓存的稳住不动，该短缓存的及时更新，不该缓存的绝不留痕。

按状态码分层设有效期

200、304、206 这类成功响应内容稳定，适合长期缓存；404 和 5xx 是临时异常，缓存太长反而掩盖问题。配置时应明确区分：

• 正常响应（200/304/206）：设为 1h～1d，比如 proxy_cache_valid 200 304 206 1h;
• 重定向（301/302）：设为 10m～1h，避免跳转链变更后长期失效
• 客户端错误（404）：设为 10s～1m，防爬虫反复刷不存在路径，但不阻塞真实修复
• 服务端错误（500/502/503/504）：设为 10s～30s，给后端留出恢复窗口，避免用户长时间看到错误页

用 any 做兜底，但别当主力

proxy_cache_valid any 5m; 可作为保底规则，但它只在没有更具体匹配时生效。如果同时写了 200 1h 和 any 5m，返回 200 就走 1h，不会降级到 5m。但若漏配某些状态码（比如忘了 302），any 就会接管——这容易掩盖配置疏漏，建议显式列出常用码，慎用 any。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

结合 location 精准控制粒度

全局策略（http 块）设宽松基础值，再在关键路径上收紧或放宽：

• 静态资源目录（如 /static/）可设 proxy_cache_valid 200 302 1d;
• API 接口（如 /api/v1/）常需高频更新，可设 proxy_cache_valid 200 5m; 覆盖全局 1h
• 健康检查接口（如 /health）建议禁用缓存：proxy_cache_valid any 0s;

配合 proxy_ignore_headers 防干扰

后端响应若带 Cache-Control: no-cache 或 Expires，Nginx 默认会尊重并跳过缓存。若你已确认后端头不可靠，可用：

• proxy_ignore_headers Cache-Control Expires Set-Cookie;
• 再搭配 proxy_cache_valid 主动接管生命周期，确保策略落地