最稳妥方式是用 return 302：语义明确、性能最优、不被缓存；如 server { listen 80; server_name promo.old.com; return 302 https://event.new.com$request_uri; }，需确保用 $request_uri、显式写 https、避免与后端 302 冲突。
临时活动页面跳转，用 Nginx 配置 302 重定向最稳妥的方式是直接用 return 302，简单、高效、语义明确，且不会被浏览器或搜索引擎长期缓存。
用 return 指令配置（推荐）
这是最清晰、性能最好的写法，适用于整站或子域名级别的临时跳转：
- 跳转整个旧活动域名到新活动页（保留路径）：
server {<br> listen 80;<br> server_name promo.old.com;<br> return 302 https://event.new.com$request_uri;<br> } - 只对特定路径做临时跳转（比如 /sale → /summer-sale）：
location = /sale {<br> return 302 /summer-sale;<br> }
注意：这里用=精确匹配，不带参数；若需带查询参数，改用$request_uri。 - 配合条件判断（如仅限移动端用户跳转）：
if ($http_user_agent ~* "(Mobile|Android|iPhone)") {<br> return 302 https://m.event.new.com$request_uri;<br> }
（注意：if 在 location 外慎用，建议放在 server 块内或改用 map 变量更安全）
用 rewrite 指令配置（灵活但稍重）
适合需要正则提取路径、重排参数等复杂逻辑的场景，但要注意 flag 选 redirect：
- 将所有 /promo/xxx 跳到 /campaign/xxx（临时）：
location /promo/ {<br> rewrite ^/promo/(.*)$ /campaign/$1 redirect;<br> }redirect表示返回 302；permanent是 301，别混淆。 - 跳转时统一加 utm 参数（测试用）：
rewrite ^/(.*)$ https://event.new.com/$1?utm_source=nginx&utm_medium=temp redirect;
关键细节提醒
避免踩坑，这几个点必须确认：
- 别用 301 替代 302：301 会被浏览器强缓存，活动结束后用户可能仍被跳转，清缓存都未必立即生效。
-
$request_uri 要带上：它包含完整路径+查询参数（如
?id=123&ref=abc），比$uri更可靠。 -
HTTPS 协议要显式写明：如果目标是 HTTPS，别依赖 $scheme —— 活动页可能只支持 HTTPS，硬写
https://更稳妥。 -
检查响应头：用
curl -I http://promo.old.com确认返回状态码确实是302 Found，且Location头正确无误。
和后端 302 冲突怎么办
如果你用 Nginx 代理后端应用（比如 Node.js 或 PHP），而它自己也返回 302 到内网地址（如 Location: http://10.0.1.5:3000/login），Nginx 默认不会改写这个响应头。这时要加：proxy_redirect http://10.0.1.5:3000/ $scheme://$host/;
同时确保已设置：proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header Host $host;
否则用户可能跳到不可访问的地址。
