301重定向必须配长缓存，因其语义是“永久重定向”，设短周期会破坏SEO权重传递、增加服务器压力、削弱CDN缓存效果；推荐Nginx中单独配置proxy_cache_valid 301 7d，CDN层同步设TTL≥86400秒。
不能设“短周期”——301 重定向必须配长缓存，设短周期是反模式，会直接破坏 301 的语义和效果。
为什么 301 绝对不能设短缓存
301 的 HTTP 语义是“永久重定向”，浏览器、CDN、爬虫都据此做长期信任决策。Google 明确要求：只有 301 才能传递几乎全部 SEO 权重；若被缓存过短（如几秒或几分钟），会导致：
- 搜索引擎反复抓取旧 URL，浪费爬虫预算，延迟权重转移
- 用户多次访问旧地址时仍触发后端重定向逻辑（比如 PHP 动态生成 301），增加服务器压力
- CDN 边缘节点频繁回源，失去缓存意义，反而放大延迟和带宽消耗
正确的 301 缓存周期建议
应按语义稳定性设定，而非“越快更新越好”：
- 推荐 7d（7 天）：平衡长期有效性与人工干预窗口，适合绝大多数域名迁移、路径重构场景
- 可设 30d 或更长：当重定向关系确定长期不变（如 old.com → new.com 永久切换）
- 不建议低于 1d：24 小时已是底线，低于此值已接近 302 行为，丧失 301 价值
Nginx 中的正确配置写法
必须单独声明，不可混入 any 或与其他状态码合并：
location /old/ {
proxy_pass http://backend;
proxy_cache my_cache_zone;
proxy_cache_valid 301 7d;
proxy_cache_valid 200 10m;
proxy_cache_valid 302 2m;
}
关键点：
- proxy_cache_valid 301 必须显式写出，且独立于 proxy_cache_valid any
- 若上游响应含 Cache-Control: no-cache，需加 proxy_ignore_headers Cache-Control;
- 确保 proxy_cache_key 包含 $request_uri（保留路径+参数），避免不同查询串命中同一缓存项
CDN 边缘层的对应设置（以阿里云 CDN 为例）
仅靠 Nginx 不够，CDN 层也需同步控制：
- 在 CDN 控制台开启“回源跟随 301/302”
- 为 301 响应单独设置缓存 TTL，例如填 3600 秒（1 小时）起跳，推荐 86400（1 天）或更高
- 禁用“强制不缓存重定向响应”类开关，避免覆盖源站策略
