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 层缓存该接口响应
