Nginx中302重定向本质是直接输出HTTP 302状态码，其业务灵活性体现在何时返回、向哪跳、对谁生效三个维度：按用户身份分流、按路径局部迁移、按环境或健康状态兜底跳转。
Nginx 中 302 重定向本身不“配合状态码”来实现业务逻辑——它本身就是 HTTP 状态码（302 Found）的直接输出。所谓“灵活的业务逻辑重定向”，本质是：在满足特定条件时，主动返回 302 响应，并精准控制跳转目标与范围。关键不在状态码组合，而在 何时返回、向哪跳、对谁生效。
以下从三个实用维度说明如何用好 302 实现真实业务需求：
按用户身份做灰度或测试分流
适合 A/B 测试、内测邀请、员工预览等场景，确保只有目标人群跳转，其他人无感知：
- 利用 Cookie 标识测试分组：
if ($http_cookie ~* "ab_version=beta") { return 302 https://beta.example.com$request_uri; } - 识别请求参数触发跳转（如分享链接带
?ref=test）：if ($args ~* "(^|&)ref=test(&|$)") { return 302 https://test.example.com$request_uri; }⚠️ 注意：
if在 server 级可用，但避免嵌套复杂逻辑；高并发场景建议改用map预计算变量。
按路径或模块做局部临时迁移
不是全站搬家，而是只把某块功能（如支付、后台、API）切到新服务，其余照常运行：
- 精确匹配路径前缀，跳转时保留完整请求：
location ^~ /checkout/ { return 302 https://pay-new.example.com$request_uri; } - 排除静态资源，避免拖慢页面（CSS/JS 图片直连旧服务）：
location ~ \.(js|css|png|jpg|gif|woff2)$ { # 不跳转，正常提供 }
按环境或健康状态做兜底跳转
用于维护页、灾备切换、服务降级等动态决策场景：
- 检查后端是否异常，自动跳转备用页（需配合
proxy_next_upstream或外部健康检查）：location / { proxy_pass http://backend; proxy_intercept_errors on; error_page 502 503 504 = @maintenance; } location @maintenance { return 302 https://status.example.com/maintenance.html; } - 仅对非爬虫用户跳转，保障 SEO 不受影响：
if ($http_user_agent !~ "(bot|crawl|spider|monitor)") { return 302 https://maintenance.example.com; }
所有配置上线前必须验证：
-
curl -I http://example.com/some-path确认返回HTTP/1.1 302 Found和正确Location头 - 检查
$request_uri是否完整保留原始路径和参数（如/search?q=nginx&sort=desc） - 用无痕窗口多次访问，排除浏览器缓存干扰
302 的灵活性，来自它轻量、可控、不固化的行为特性。用对了，就是业务演进的润滑剂；用错了，就变成不可控的跳转黑洞。
