应避免多级重定向，归并为单次301跳转；优先用return而非rewrite实现重定向；禁用冗余跳转链路；对重定向响应关闭响应体、启用缓存及dns预解析。
多级重定向（比如 /old → /new → /final）会显著拖慢首屏加载，因为每次跳转都增加一次完整的 HTTP 往返，TTFB 累加、DNS 查询可能重复、SSL 握手也可能重做。Nginx 本身不生成重定向逻辑，但它是重定向行为的执行者和优化关键点——重点在于“避免链式跳转”和“让重定向尽可能轻量”。
用单次 301 替代多级跳转
常见问题是历史配置层层叠加：旧规则未清理，新规则又追加，导致请求经过多个 return 301 或 rewrite ... redirect。应归并为一步直达。
- 检查所有
server和location块中的return 301、rewrite ... redirect、permanent指令，删除中间跳转环节 - 例如把
location /a { return 301 /b; }和location /b { return 301 /c; }合并为location /a { return 301 /c; } - 使用
curl -I或浏览器 Network 面板验证跳转次数，确保响应状态码直接为301且Location头指向最终地址
优先用 return 而非 rewrite 实现重定向
return 是 Nginx 最快的重定向方式，它不触发内部 URI 重写流程，不查 location 匹配，不走正则引擎；而 rewrite ... redirect 会强制 Nginx 重新匹配 location，带来额外开销，尤其在复杂配置中易引发意外循环或性能抖动。
- 静态路径跳转一律用
return 301 https://example.com/new-path; - 避免写
rewrite ^/old$ /new redirect;，除非必须依赖正则提取变量 - 若需带参数透传（如
/old?id=123→/new?id=123），可用return 301 $scheme://$host/new?$query_string;
禁用不必要的重定向链路
很多重定向并非业务必需，而是由习惯性配置或框架默认行为引入，比如：
- HTTP 自动跳 HTTPS（合理），但又在 HTTPS server 块里做了路径重写，造成二次跳转
- 前端路由 fallback（如
try_files $uri $uri/ /index.html;）与重定向规则冲突，导致 404 后再跳转 - CDN 或负载均衡层已做跳转，Nginx 又重复执行
- 检查访问日志中频繁出现的
301或302请求，定位是否来自冗余规则，并注释或删除
对重定向响应启用基础优化
即使只跳一次，也能让它更快被浏览器接收和处理：
- 关闭重定向响应体：
return 301 https://example.com/;不带 body，比rewrite生成的默认 HTML 跳转页更轻量 - 设置
add_header Cache-Control "public, max-age=31536000";让浏览器长期缓存重定向结果（仅适用于稳定、永久的 301） - 确保重定向目标域名已预解析：可通过
add_header Link "<https:></https:>; rel=dns-prefetch";提示浏览器提前做 DNS 查询
