nginx默认不缓存自身生成的301/302重定向响应，仅缓存后端返回且经proxy_pass处理的301/302响应；需显式配置proxy_cache_valid 301 7d和302 2m，确保location匹配、忽略cache-control干扰、cache_key含关键变量。

Nginx 默认不缓存重定向响应（301/302），哪怕你写了 proxy_cache_valid 301 1h，也大概率不生效——这不是配置写错了，而是机制限制。真正起作用的前提是：该重定向响应必须由后端服务返回，且经过 proxy_pass 流程；Nginx 自己生成的 return 301 或 rewrite ... permanent 响应完全绕过缓存模块。

必须满足的三个硬性条件

缺一不可，否则 proxy_cache_valid 对 301/302 就是摆设：

• 全局定义缓存区：在 http 块中声明，例如：
  proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=redirect_cache:10m max_size=500m;
• location 中启用缓存并指向该区：在对应路径的 location 块里写：
  proxy_cache redirect_cache;
proxy_pass http://upstream_backend;（必须是 proxy_pass，不能是 return）
• 后端实际返回 301/302 响应，且不带禁止缓存的头：上游响应不能含 Cache-Control: no-cache、private，也不能带 Set-Cookie（除非加 proxy_ignore_headers Set-Cookie; 主动忽略）

按状态码显式设置缓存时间

不能只靠 proxy_cache_valid 200 10m 顺带覆盖 301；必须单独、明确写出：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• proxy_cache_valid 301 7d; → 永久重定向可长期缓存，适合域名迁移、旧 URL 归档
• proxy_cache_valid 302 2m; → 临时跳转必须设短，避免用户被锁在过期跳转里
• proxy_cache_valid 200 301 302 10m; 可共存，但 Nginx 会优先匹配更具体的 301 行
• proxy_cache_valid any 5s; 是兜底，不影响已声明的 301/302 规则

如何验证重定向是否真被缓存

加一行响应头便于调试：

• 在 location 块中加入：
  add_header X-Cache-Status $upstream_cache_status;
• 用 curl 多次请求同一路径：
  curl -I https://example.com/old-path
• 观察响应头：
  → 第一次返回 X-Cache-Status: MISS 或 UPDATING
  → 后续返回 X-Cache-Status: HIT 才说明 301 响应体（含 Location 头）已被缓存

更实用的替代思路

与其费力缓存重定向本身，不如把性能优化重心放在“跳转决策”和“目标内容”上：

• 用 map + return 301 实现毫秒级跳转：所有映射关系预加载进内存，不查库、不走 proxy_pass，CPU 开销趋近于零
• 确保重定向后的目标 URL（如 /new-page）本身被强缓存：
  location /new-page { proxy_cache my_cache; proxy_cache_valid 200 1h; }
• 若跳转逻辑需动态计算（如登录态判断），让后端接口返回一个可缓存的 301 响应，并在 Nginx 层缓存该接口响应