301重定向必须配长缓存，因其“永久”语义要求浏览器、CDN和搜索引擎长期信任；短缓存会破坏SEO权重传递、增加后端与CDN回源压力；Nginx需显式配置proxy_cache_valid 301 7d及以上，CDN层同步设置TTL≥86400秒。
301重定向必须配长缓存，不能设短周期——这是由其“永久”语义决定的。设几秒或几分钟会破坏SEO权重传递、增加后端压力、让CDN边缘节点频繁回源，反而拖慢访问速度。
为什么301必须设长缓存
HTTP协议规定301代表资源已永久迁移，浏览器、CDN和搜索引擎都据此做长期信任决策：
- Google明确要求只有301才能传递95%左右的SEO权重；缓存太短会导致爬虫反复抓取旧URL，浪费抓取预算
- 用户多次访问旧地址时，若301未被缓存，每次都要触发后端逻辑（如PHP动态生成响应），加重服务器负担
- CDN边缘节点若不缓存301，就会不断回源，失去边缘缓存意义，延迟和带宽消耗反而上升
Nginx中正确的proxy_cache_valid配置方式
必须显式、独立地为301声明缓存时间，不能混入proxy_cache_valid any或与其他状态码合并：
- 推荐写法：
proxy_cache_valid 301 7d;—— 7天是兼顾稳定性与人工干预窗口的通用选择 - 若重定向关系确定长期不变（如old.com → new.com），可设
301 30d甚至更长 - 底线是不低于24小时；低于1天已接近302行为，丧失301价值
- 需确保
proxy_cache_key包含$request_uri，避免不同参数的请求命中同一缓存项 - 若上游返回
Cache-Control: no-cache，要加proxy_ignore_headers Cache-Control;
CDN层必须同步配合
仅靠Nginx不够，CDN边缘节点也要按同样逻辑控制：
- 阿里云CDN、CloudFront等平台需开启“回源跟随301/302”功能
- 为301响应单独设置TTL，建议≥86400秒（1天），推荐填3600～604800秒（1小时到7天）
- 禁用“强制不缓存重定向响应”类开关，否则会覆盖源站的
proxy_cache_valid策略
常见失效原因与排查要点
缓存没生效，往往不是配置写错，而是环境或逻辑没对齐：
- location块未覆盖发起重定向的请求路径——比如重定向由
/old/入口触发，但proxy_cache_valid 301只写在/new/里 - 后端响应头含
Cache-Control: no-store或Pragma: no-cache，且未用proxy_ignore_headers忽略 - 未启用
proxy_cache指令，或缓存区（如my_cache_zone）未正确定义 - 测试时用浏览器直接访问，结果被本地磁盘缓存劫持（显示“from disk cache”），应改用
curl -I或隐身模式验证
