Nginx缓存重定向响应需显式配置proxy_cache_valid指定301/302等状态码，如proxy_cache_valid 301 302 1h；且后端响应必须含Cache-Control或Expires头，否则默认不缓存，配合add_header X-Cache $upstream_cache_status可验证命中。

要为重定向响应（如 301、302）单独设置 proxy_cache_valid 缓存时长，需在 Nginx 配置中显式指定对应状态码，不能依赖通配规则或默认 fallback。

明确指定重定向状态码的缓存策略

Nginx 的 proxy_cache_valid 指令支持按 HTTP 状态码精确控制缓存时间。重定向响应必须用具体状态码（如 301、302、307、308）单独声明，否则不会生效。

• 错误写法：proxy_cache_valid 200 304 10m; —— 不包含 301/302，重定向不缓存
• 正确写法：proxy_cache_valid 200 304 10m; proxy_cache_valid 301 302 1h;
• 更完整示例：proxy_cache_valid 200 304 10m; proxy_cache_valid 301 302 307 308 1h; proxy_cache_valid 404 1m;

确保重定向响应实际被缓存

仅配置 proxy_cache_valid 不够，还需满足以下条件，Nginx 才会真正缓存重定向响应：

FastAPI Flask Proxy

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

下载

• 后端返回的重定向响应必须带 Cache-Control 或 Expires 头（即使值为 no-cache 或 max-age=0），否则 Nginx 默认不缓存 3xx 响应
• 若后端不返回缓存头，可配合 proxy_ignore_headers 强制忽略（慎用）：proxy_ignore_headers Cache-Control Expires;，再依赖 proxy_cache_valid 主导
• 确认未启用 proxy_cache_bypass 或 proxy_no_cache 导致跳过缓存

验证缓存是否生效

通过响应头和日志确认重定向是否进入缓存：

• 查看响应头中是否出现 X-Cache: HIT（需自行添加 add_header X-Cache $upstream_cache_status;）
• 检查 Nginx error 日志级别设为 info 时的缓存日志（开启 log_format 含 $upstream_cache_status）
• 使用 curl -I 多次请求同一重定向 URL，观察 Age 头是否递增，表明命中缓存

注意与 proxy_redirect 的区别

proxy_cache_valid 控制的是「上游返回的重定向响应」在边缘节点的缓存时长；而 proxy_redirect 仅改写响应头中的 Location 地址，不影响缓存逻辑。二者功能正交，需分别配置。