Nginx临时业务迁移首选302重定向，用return指令配合$request_uri保留参数，支持全站、路径级及条件跳转，上线前须用curl验证响应头、参数完整性和无痕模式防缓存。
临时业务迁移时，Nginx 用 302 重定向 是最稳妥的选择——它明确告诉浏览器和搜索引擎：“这只是暂搬，原地址仍有效”，避免权重误转移、索引被覆盖。
核心配置方式：优先用 return 指令
简洁、高效、无正则开销，适合大多数临时迁移场景：
- 直接返回 302 状态码 + 目标 URL，不缓存，每次请求都走服务器验证
- 务必使用
$request_uri保留原始路径和查询参数（如?utm_source=test） - 目标域名建议写全（含协议），避免相对路径引发跳转异常
示例（将 old-site.com 全量临时迁至 temp.new-site.com）：
server {
listen 80;
server_name old-site.com;
return 302 https://temp.new-site.com$request_uri;
}
按路径做精细化临时跳转
不是全部迁移？只需把特定模块或目录临时切走，可用 location + return 组合：
- 匹配精确路径（如
/checkout/、/api/v2/），避免影响其他功能 - 支持内部路径跳转（如跳到同站维护页），也支持跨域跳转
- 注意：location 中的 return 会终止后续处理，无需额外 break
示例（仅将支付路径临时导向新服务）：
location ^~ /payment/ {
return 302 https://pay-api-temp.new-site.com$request_uri;
}
带条件的临时跳转（如灰度或维护中）
需要按用户来源、IP 或时间窗口控制跳转范围？可结合 if + rewrite（慎用 if，但简单判断可行）：
- 用
$http_user_agent或$remote_addr做基础分流 - rewrite 后加
redirect标志，等效于 302；不要混用 permanent - 避免在 if 中写复杂逻辑，优先考虑 upstream + 条件路由等更健壮方案
示例（仅对内网 IP 开放临时跳转）：
if ($remote_addr ~ "^192\.168\.1\.") {
rewrite ^/(.*)$ https://dev-staging.new-site.com/$1 redirect;
}
上线前必须验证的三件事
配置生效后，别只看页面跳了——关键要看底层行为是否符合预期：
- 用 curl -I 访问原 URL，确认响应头含
HTTP/1.1 302 Found和Location:字段 - 检查跳转后地址是否完整保留参数（如
/product?id=123&ref=abc） - 用无痕模式多次访问，确认不会因浏览器缓存变成“伪永久跳转”（Chrome 对 302 不缓存，但人为干预过可能残留）
