301重定向必须配长缓存，因其语义为永久迁移，短缓存会破坏浏览器/CDN/搜索引擎的信任机制，导致回源频繁、权重传递不稳定；推荐proxy_cache_valid 301 7d或1d，且需确保配置位置正确、不被覆盖、忽略上游no-cache头，并区分302的短缓存策略。
不能设“短周期”——301 重定向语义上是永久性的，配置短缓存（比如 2m 或 5m）违背协议本意，会引发严重问题：浏览器或 CDN 可能反复回源、上游重定向逻辑被重复触发、SEO 权重传递不稳定，甚至造成跳转链抖动。
为什么 301 必须配长缓存
HTTP 规范明确 301 表示“资源已永久移至新位置”。搜索引擎（如 Google）、浏览器、CDN 都基于此假设做优化：
- Google 搜索中心要求 301 才能传递 90–99% 的链接权重，前提是缓存稳定可信
- 浏览器会本地缓存 301 跳转，下次访问旧 URL 直接跳新地址，不发请求
- 边缘节点若只缓存几分钟，等于把“永久”当成“临时”，失去语义一致性
推荐的 proxy_cache_valid 301 缓存周期
生产环境应设为1天到7天，兼顾语义正确性与运维可控性：
- 7d（推荐）：适用于域名迁移、结构固化等长期不变场景
- 1d：适合需保留一定调整窗口的中短期策略（如灰度切换期）
- 避免使用
1h、10m等短值——这不是“保守”，而是误用
配置时必须注意的关键点
仅写 proxy_cache_valid 301 7d; 不够，还需确保：
- 该指令位于启用
proxy_cache的location或server块内，否则无效 - 显式分开写，不要合并进
proxy_cache_valid any ...，否则会被覆盖 - 若上游返回带
Cache-Control: no-cache，需加proxy_ignore_headers Cache-Control; - 涉及查询参数（如
?ref=abc）时，proxy_cache_key必须包含$args，否则不同参数共用一个缓存项
对比：301 和 302 的缓存策略必须分离
二者语义和用途完全不同，混用会导致策略失效：
-
proxy_cache_valid 301 7d;—— 永久跳转，信任长期有效 -
proxy_cache_valid 302 2m;—— 临时跳转，允许快速响应上游变化 - 切勿写成
proxy_cache_valid 301 302 2m;或依赖any统一兜底
