Nginx 中 302 重定向如何在灰度发布期间平滑切换用户的临时访问路由

灰度发布期间Nginx应使用return 302实现临时重定向，核心是按Cookie/请求头/IP等条件精准分流、保留$request_uri传递原始路径与参数、目标地址带完整协议，确保不伤SEO、可随时回退；禁用rewrite和301。

灰度发布期间用 Nginx 做 302 重定向，核心是“临时引导、按需分流、不伤 SEO”，不是把用户永久搬走，而是让部分人先去新环境看看，随时可关掉即刻回退。

必须用 return 302，别写 rewrite 或 301

直接写 return 302 https://new-site.com$request_uri; 最稳妥：语义明确、性能高、不触发正则解析、避免 rewrite 可能导致的循环跳转或路径拼接错误。301 是永久重定向，一旦被浏览器或 CDN 缓存，撤回困难；而 302 每次请求都重新判断，天然适配灰度的动态性。

精准识别灰度用户再跳转

不能全站跳，得靠请求特征区分目标人群。常用方式包括：

1. 按 Cookie：比如 if ($cookie_version = "beta") { return 302 https://beta.example.com$request_uri; }
2. 按请求头：如测试人员带 X-Env: beta，配置 if ($http_x_env = "beta") { ... }
3. 按 IP 段：内网验证常用，例如 if ($remote_addr ~ ^(192.168|10.) ) { ... }

注意：if 尽量放在 location 块内；更健壮的做法是用 map 预定义变量，避免 if 在 server 级别的潜在副作用。

保留原始路径和参数，确保功能连贯

跳转时带上 $request_uri，能让 /api/user?id=123 精准变成 https://beta.example.com/api/user?id=123，不丢参数、不破链路。目标地址必须带完整协议（https://），否则可能因协议缺失导致跳转失败或降级为 HTTP。

上线前必须验证的关键点

光看页面跳了没不够，要确认底层行为是否合规：

1. 用 curl -I 请求，响应头必须含 HTTP/1.1 302 Found 和正确的 Location 字段
2. 检查响应头里没有 Cache-Control: public 类缓存指令，防止被误缓存
3. 清空浏览器缓存或用隐身窗口测试，排除旧 301 缓存干扰
4. 非灰度用户访问应返回 200，且日志中跳转频次合理，避免配置范围过大拖垮服务