灰度发布期间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 每次请求都重新判断，天然适配灰度的动态性。
精准识别灰度用户再跳转
不能全站跳，得靠请求特征区分目标人群。常用方式包括：
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 按 Cookie：比如 if ($cookie_version = "beta") { return 302 https://beta.example.com$request_uri; }
- 按请求头：如测试人员带 X-Env: beta，配置 if ($http_x_env = "beta") { ... }
- 按 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。
上线前必须验证的关键点
光看页面跳了没不够，要确认底层行为是否合规：
- 用 curl -I 请求，响应头必须含 HTTP/1.1 302 Found 和正确的 Location 字段
- 检查响应头里没有 Cache-Control: public 类缓存指令，防止被误缓存
- 清空浏览器缓存或用隐身窗口测试，排除旧 301 缓存干扰
- 非灰度用户访问应返回 200，且日志中跳转频次合理，避免配置范围过大拖垮服务
