proxy_cache_valid 本身不实现动态失效，仅设静态TTL；动态失效需通过状态码分级、Content-Type映射及stale+background_update+lock三件套协同实现。
proxy_cache_valid 本身不实现“动态失效”，它只设静态有效期（TTL）。所谓“动态失效”，实际是通过组合指令 + 状态码分级 + 响应头协同，让缓存行为随内容变化节奏自动调整。关键不是单写一条指令，而是构建一套响应驱动的缓存生命周期策略。
按 HTTP 状态码差异化设置失效时间
不同状态码代表不同语义，混设会破坏业务逻辑：
-
proxy_cache_valid 200 302 5m;—— 成功页和临时跳转缓存 5 分钟，适合商品详情、列表页等轻量变动内容 -
proxy_cache_valid 301 7d;—— 永久重定向缓存 7 天，保障 SEO 权重稳定传递 -
proxy_cache_valid 302 2m;—— 临时跳转只缓存 2 分钟，避免用户长期跳转到已下线目标 -
proxy_cache_valid 404 1m;—— 404 页面缓存 1 分钟，防恶意探测刷空缓存，又不掩盖真实上线延迟 -
proxy_cache_valid 500 5m;—— 错误页缓存 5 分钟，缓解雪崩，但不过长掩盖恢复
多条 proxy_cache_valid 共存时，Nginx 按状态码精确匹配，最先匹配的规则生效，不取最大或最短。
利用响应头（Content-Type）动态映射失效时长
静态资源与 API 响应更新频率差异大，靠 $sent_http_content_type 实现真正动态控制：
map $sent_http_content_type $cache_ttl {
default "5s";
~*^text/ "1h";
~*^application/javascript "1h";
~*^image/ "24h";
~*^application/json "10s";
~*^application/vnd.api+json "10s";
}再在 location 中引用：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
proxy_cache_valid 200 302 $cache_ttl; proxy_cache_valid 404 1m;
⚠️ 注意：必须开启 proxy_buffering on;，且上游响应需带 Content-Type 头；若启用 gzip，Nginx 可能改写该头，需配合 gzip_vary off 或补充匹配规则。
让过期缓存“自动更新”而非直接穿透
proxy_cache_valid 设完只是起点，真正实现用户无感更新靠三件套：
-
proxy_cache_use_stale updating;—— 缓存过期时，允许返回旧内容并后台刷新 -
proxy_cache_background_update on;—— 启用异步回源，不影响用户 TTFB -
proxy_cache_lock on;—— 防止并发请求全部穿透，只放行首个验证请求
这三者配合 proxy_cache_valid 的 TTL，才能形成“到期即更新、用户无感知”的动态效果。
处理上游响应头干扰，确保配置生效
后端返回的 Cache-Control 优先级高于 proxy_cache_valid：
- 若返回
Cache-Control: no-cache或max-age=0，Nginx 默认不缓存 - 加
proxy_ignore_headers Cache-Control;可强制忽略，让proxy_cache_valid主导 - 对含
Set-Cookie或Vary: Cookie的响应，默认不缓存，需显式proxy_ignore_headers Set-Cookie;并谨慎评估业务风险
不复杂但容易忽略。
