rewrite与缓存模块无法加速重定向本身，因301/302仅返回location头；应将rewrite置于server顶层、用return替代、避免正则与if块，并缓存跳转目标资源以提升整体性能。
直接用 rewrite + 缓存模块无法“加速重定向本身”，因为重定向（301/302）本质是返回一个 Location 响应头，不涉及内容缓存。但你可以让重定向逻辑更轻、更早触发，并避免后续多余处理——这才是“极速响应”的关键。
rewrite 规则必须放在最前端，避开 location 匹配开销
重定向越早执行，性能越好。Nginx 处理请求时，先匹配 location，再执行其中的 rewrite。如果 rewrite 写在某个 location 块里，就得先完成 location 匹配（包括正则扫描），才进入 rewrite 阶段，白白增加延迟。
- 把 rewrite 放在 server 块顶层（不在任何 location 内），它会在 location 匹配前执行，命中即跳转，不走后续流程
- 优先使用 精确匹配或前缀匹配（如
location = /old或location ^~ /static）替代正则 location，减少 PCRE 开销 - 避免在 if 块中写 rewrite —— if 在 location 内属于“非标准上下文”，易出错且性能不稳定
用 return 替代 rewrite 实现更轻量的跳转
对于简单跳转（比如固定路径映射、协议强制跳转），return 比 rewrite ... permanent 更快：它不依赖 PCRE，不解析正则，也不做 URI 替换，直接构造响应并终止请求。
- 强制 HTTPS：
return 301 https://$host$request_uri; - 域名归一化：
if ($host != 'www.example.com') { return 301 https://www.example.com$request_uri; }（注意：仅限 server 块内，且确保 $host 可靠） - 带参数跳转需显式拼接：
return 301 https://new.com/path?$args;（$args会原样保留查询参数）
缓存模块不缓存重定向响应，但可缓存跳转后的目标资源
nginx 的 proxy_cache 或 fastcgi_cache 默认不缓存 3xx 响应（除非显式配置 proxy_cache_valid 301 1h;）。真正提升体验的是：跳转后用户访问的新地址，如果指向静态资源或稳定接口，可以被高效缓存。
- 对跳转目标（如
/articles/2024/xxx）启用 proxy_cache，设置proxy_cache_valid 200 302 1d;和proxy_cache_valid 301 1y; - 配合
add_header Cache-Control "public, max-age=31536000";让浏览器也缓存跳转结果（适用于长期不变的 301） - 用
proxy_cache_use_stale updating;避免缓存过期瞬间的并发回源压力
规避重定向链和循环，防止性能雪崩
多个 rewrite 或 return 层层跳转（比如 A→B→C），不仅增加 HTTP 往返耗时，还可能触发浏览器限制（通常最多 20 次跳转）。一次重定向到位才是极速的前提。
- 检查配置中是否存在隐式跳转：比如
location /old { rewrite ^/old(.*)$ /new$1 permanent; }后又在location /new中写了另一个 rewrite - 用
curl -I测试真实跳转次数，确认是否一步到位 - 日志中开启
rewrite_log on;（配合error_log ... notice;）快速定位冗余规则
