Nginx 中 302 重定向如何实现临时的网址跳转与灰度测试

用 return 302 最直接可靠，不缓存、不传递 SEO 权重、每次请求重新判断，适用于活动导流、域名切换、短期维护及灰度测试；需匹配域名或路径，目标地址带完整协议，用 $request_uri 保留原始路径和参数，避免混用 rewrite、禁用缓存头，并用 curl -I 验证响应头。

用 return 302 指令最直接可靠，它不缓存、不传递 SEO 权重、每次请求都重新判断，天然适配临时跳转和灰度测试场景。

临时网址跳转的配置方式

适用于活动页导流、域名切换、短期维护等明确“只跳一阵子”的情况：

1. 在 server 块中按域名匹配：比如旧活动域名 promo.example.com 全量跳转到新活动页
2. 目标地址必须带完整协议（如 https://），否则会变成站内相对路径跳转
3. 用 $request_uri 保留原始路径和查询参数，例如访问 /2024?utm=ad 会跳到 https://event.example.com/2024?utm=ad
4. 若只对部分路径跳转（如仅 /campaign/ 下的请求），优先用 location ^~/campaign/ + return 302 组合

灰度测试的分流写法

核心是“只让特定用户跳，其他人无感”，不能全量，也不能永久固化：

1. 按 Cookie 判断：if ($cookie_version = "beta") { return 302 https://beta.example.com$request_uri; }
2. 按请求头识别：if ($http_x_env = "beta") { return 302 https://beta.example.com$request_uri; }
3. 按 IP 段控制（适合内网测试）：if ($remote_addr ~ ^(192.168|10.)) { return 302 https://beta.example.com$request_uri; }
4. 更健壮的做法是用 map 预定义变量，避免 if 在非 location 块中的潜在风险

必须避开的常见坑

看似简单，但错一处就可能让 302 变相失效或引发连锁问题：

1. 别混用 rewrite ... redirect 和 return 302——前者易因正则漏写 $1 或误加 last 导致无限跳转
2. 别给 302 响应加 Cache-Control: public，否则 CDN 或浏览器可能缓存跳转结果，失去“临时”意义
3. 目标域名要能正常访问，SSL 证书需有效；否则用户看到的是浏览器安全警告，不是跳转
4. 上线前一定用 curl -I 验证：响应头里必须有 HTTP/1.1 302 Found 和正确的 Location 字段

为什么不用 301？

301 是永久搬家，搜索引擎会把原页面权重转移到新地址，浏览器和 CDN 也可能长期缓存。灰度或临时跳转一旦用了 301，后续想撤回就得等缓存过期，甚至要手动清理 CDN 缓存，风险高、恢复慢。302 每次都走服务端逻辑，关掉配置即刻回退，可控性强。