Nginx临时跳转应使用return 302指令，因其简洁高效、立即终止处理、保留$request_uri参数且避免rewrite的隐含风险；需验证响应头、跳转链及搜索引擎索引状态。
临时业务跳转用 Nginx 做 302 重定向，核心是明确“临时性”、避免被搜索引擎误判为永久迁移，同时确保路径参数不丢失、跳转逻辑清晰可控。
用 return 指令最稳妥
这是推荐首选方式，简洁、高效、无歧义：
-
语法固定：直接写
return 302 目标URL;，Nginx 会原样返回 302 状态码，不缓存、不重写、不二次匹配 -
保留原始路径：用
$request_uri变量可完整携带路径和查询参数，例如：return 302 https://promo.example.com$requested_uri; -
适用位置灵活：可放在
server块顶层（全站跳转），也可嵌套在location中（仅特定路径跳转）
按场景选配置方式
不同业务需求对应不同写法：
-
整个域名临时跳转（如活动页上线期间）：
server { listen 80; server_name old-site.com; return 302 https://event.new-site.com$request_uri; } -
只跳特定路径（如 /beta/ 下所有请求）：
location /beta/ { return 302 https://staging.example.com$request_uri; } -
跳到固定页面（不传参）（如维护提示页）：
location / { return 302 /maintenance.html; }
务必避开 rewrite 的 redirect 标志
虽然 rewrite ... redirect; 也能触发 302，但存在隐含风险：
- 它依赖正则匹配，若规则写错或顺序不当，可能被后续 rewrite 或 location 规则覆盖
- 没有
return那样“立即终止处理”的确定性，容易引发意外循环或漏匹配 - 调试时日志不易追踪，尤其在多层 rewrite 场景下
验证是否生效
部署后快速确认三点：
- 用
curl -I http://your-domain.com/some-path查看响应头，确认含HTTP/1.1 302 Found和Location:字段 - 打开浏览器开发者工具 → Network 标签，访问目标地址，观察跳转链是否只有一次 302，且地址栏 URL 变更
- 检查搜索引擎是否仍索引原 URL（通常 302 不会导致原页被降权或替换）
