302重定向专用于服务器迁移过渡期的临时跳转，核心是“临时、可逆、不干扰SEO”，应配合return指令、精准范围控制和严格验证，避免误用为永久跳转或长期拖延方案。
服务器迁移过渡期用 Nginx 配 302 重定向，核心是“临时、可逆、不干扰 SEO”，避免被搜索引擎当成永久搬家。关键不是写对语法，而是选对时机、范围和状态码语义。
明确适用场景再动手
302 专用于短期过渡，比如：
- 新旧服务器并行运行，只把部分流量切过去测试（如按 IP 或 cookie 分流）
- 数据库或服务尚未完全同步，主站暂不可用，先跳转到维护页或备用站点
- 灰度发布期间，让内网用户访问新环境，外部用户仍走老服务
- 域名备案未完成，临时用子域或测试域名承载流量
如果已确定旧服务器将下线、所有数据已迁移完毕，就该用 301 —— 302 不该成为“拖延战术”的替代方案。
用 return 指令配最稳妥
相比 rewrite，return 更轻量、更直观，不易出错，适合简单跳转：
- 整站临时跳转到备用地址：
return 302 https://backup.example.com$request_uri; - 仅特定路径跳转（如 /admin 和 /api 除外）：
location / {
if ($request_uri !~ ^/(admin|api)/) {
return 302 https://backup.example.com$request_uri;
}
} - 带条件跳转（例如只对非爬虫用户生效）：
if ($http_user_agent !~ "bot|crawl|spider") {
return 302 https://maintenance.example.com;
}
注意：$request_uri 会保留原始请求路径和全部参数，比 $uri 更安全；return 后直接结束处理，不触发后续 location 匹配。
避免常见坑点
实际配置中容易忽略的细节：
-
不要混用 rewrite + redirect：虽然
rewrite ... redirect也能实现 302，但它会多一次内部重写解析，且 flag 逻辑易与 break/last 冲突，过渡期建议统一用 return -
别漏掉 HTTPS 协议判断：若跳转目标是 HTTPS 地址，而源请求是 HTTP，需显式写
https://，否则可能跳成http://backup...导致混合内容或跳转失败 -
禁止对静态资源做无差别 302：CSS/JS/图片等资源跳转会拖慢页面加载，建议通过
location ~ \.(js|css|png|jpg)$单独放行，直连旧服务器 - 检查响应头是否含 Cache-Control: no-cache：浏览器默认不缓存 302，但若后端或 CDN 加了缓存头，可能导致跳转失效，可用 curl -I 验证
上线前必须验证
配置 reload 后，立刻做三件事：
- 用 curl -I 测试不同路径，确认返回状态码确实是 302，且 Location 头指向正确地址
- 打开浏览器开发者工具 → Network 标签，看跳转链是否干净（避免出现 302→301→302 的嵌套）
- 用搜索引擎的“site:old-domain.com”查收录是否仍为原 URL，确认权重未被误转移
过渡期结束后，及时撤掉 302 配置，或切换为 301 —— 长期挂着 302 会让搜索引擎困惑，也增加服务器额外负担。
