proxy_cache_valid 仅定义缓存有效期，真正的“失效自动更新”依赖其与 proxy_cache_use_stale updating、proxy_cache_background_update 等指令协同实现缓存生命周期管理。

FastAPI Flask Proxy

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

下载

`proxy_cache_valid` 本身不直接“自动更新”缓存，它只定义缓存项的**有效期（TTL）**。所谓“失效自动更新”，其实是靠它与其他指令协同形成的**缓存生命周期管理闭环**：过期后如何响应、是否回源、是否后台刷新、是否复用旧内容等。关键不在 `proxy_cache_valid` 单独怎么写，而在于它和哪些指令配对、怎么配对。 下面从实际需求出发，分三类典型资源说明配置逻辑和要点：

静态资源（JS/CSS/图片）：长期缓存 + URL 版本化驱动更新

这类资源不变则永不过期，变则换 URL（如 `/app.js?v=20260512`）。缓存策略重在“稳”和“省带宽”：

• 设极长有效期（如 1年），让 Nginx 尽量不触发验证或回源
• 配合 proxy_cache_revalidate on 可选——但仅当无法控制 URL 版本时启用，否则反而增加无谓请求
• 404 也缓存（如 proxy_cache_valid 404 10s），防恶意探测或参数拼错刷空缓存
• 避免用 $args 做 cache key，防止带随机参数（如 ?t=123）导致缓存分裂

动态页面与 API（HTML 列表页、商品详情、用户数据）：中短期缓存 + 后台静默刷新

内容有变化但非实时敏感，适合“用户无感更新”。核心是让过期不等于卡顿：

• 设中等 TTL（如 proxy_cache_valid 200 302 5m），平衡新鲜度与压力
• 必须开启 proxy_cache_use_stale updating ——这是“返回旧内容+后台更新”的前提
• 搭配 proxy_cache_background_update on 和 proxy_cache_lock on，避免并发击穿，且用户 TTFB 不受影响
• 可加 proxy_cache_valid 304 1h，把上游返回的 304 响应也缓存起来，减少重复校验

重定向（301/302）与错误页（404/500）：按语义差异化设置

不同状态码代表不同业务含义，混设会破坏行为预期：

• 301 永久重定向：语义承诺长期有效，建议缓存 7d 或更久（proxy_cache_valid 301 7d）
• 302 临时重定向：可能随时变更，设短些（如 30s～2m），避免用户跳转到已失效目标
• 404 页面：缓存太长会掩盖真实上线延迟，一般 10s～1m 足够
• 5xx 错误页：缓存 30s～5m，缓解雪崩，但不宜过长以免掩盖恢复
• 注意：若上游返回了 Cache-Control: no-cache，需加 proxy_ignore_headers Cache-Control 才能让 proxy_cache_valid 生效

不复杂但容易忽略。