必须独立配置301和302的proxy_cache_valid，因为nginx默认不区分重定向语义，混写或依赖any规则会导致301缓存过短（破坏seo权重传递）或302缓存过长（掩盖真实状态变化），进而引发后端压力增大、搜索引擎索引延迟甚至放弃抓取等问题。

301 和 302 重定向必须用 分开的 proxy_cache_valid 指令配置，不能混写、不能依赖 any 规则，否则缓存行为会错乱——301 被缓存太短会破坏 SEO 权重传递，302 缓存太久又会掩盖真实状态变化。

为什么必须独立配置 301 和 302

Nginx 默认不区分重定向语义，proxy_cache_valid any 或 proxy_cache_valid 200 302 1h 这类写法会让 301 落入默认缓存逻辑（可能不缓存或仅缓存 1 分钟），而 302 又可能被设得过长。实际效果是：

• 用户反复访问旧 URL，后端仍被频繁调用生成 301（比如 PHP 动态跳转），增加服务器压力
• 搜索引擎抓取旧地址时得不到稳定响应，延迟权重迁移，甚至放弃索引
• 302 若缓存数小时，上游服务已切到新目标，用户却还在跳转旧地址

推荐的缓存周期与配置写法

按 HTTP 语义设定，不是“越快更新越好”：

FastAPI Flask Proxy

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

下载

• 301 永久重定向：设 7d（7 天）最稳妥；长期不变可设 30d；底线不低于 1d
• 302 临时重定向：设 2m～5m；高动态场景可用 30s；避免超过 10m

正确写法示例（放在对应 location 块内）：

location /old/ {
  proxy_pass http://backend;
  proxy_cache my_cache_zone;
  proxy_cache_valid 301 7d;
  proxy_cache_valid 302 2m;
  proxy_cache_valid 200 10m;
}

让配置真正生效的关键细节

光写对状态码还不够，下面三点漏掉一个就可能失效：

• 确保 location 覆盖发起重定向的请求路径：比如旧 URL 是 /a 返回 301，那配置就得写在 location /a 或更宽泛的匹配里，不能只配在新地址的 location
• 处理上游 Cache-Control 干扰：若后端返回 Cache-Control: no-cache，需加 proxy_ignore_headers Cache-Control;
• 检查 cache_key 是否含变量：如果重定向依赖查询参数（如 ?id=123），proxy_cache_key 必须包含 $args，否则不同参数共用同一缓存项

CDN 边缘层要同步配合

Nginx 配好了，CDN 层没跟上，301 依然会被频繁回源。以主流 CDN（如阿里云、腾讯云）为例：

• 开启「回源跟随 301/302」功能
• 为 301 响应单独设置 TTL，最低建议 86400 秒（1 天），推荐 604800（7 天）
• 关闭「强制不缓存重定向响应」类开关，避免覆盖源站策略