活动页面临时跳转应使用Nginx配置302重定向，推荐用return 302指令，语法简洁、执行高效、语义明确；需匹配活动域名或路径，保留原始请求URI（如$request_uri），避免internal限制导致内部重写，并通过curl -I验证返回状态码为302 Found。
活动页面临时跳转，用 Nginx 配 302 是最稳妥的做法——它明确告诉浏览器和搜索引擎：“这只是暂时的，原链接还有效”。关键不是“能不能跳”，而是跳得对不对、会不会被当成永久迁移。
直接用 return 302 最简洁可靠
这是推荐方式，语法干净、执行快、无歧义：
- 在 server 块中匹配活动子域名或路径，例如 promo.example.com 或 /campaign/
- 用 return 302 指向目标地址，保留原始路径用 $request_uri，只跳首页就写死 URL
- 确保没加 internal 或其他限制，否则会变成内部重写而非真实跳转
示例配置（跳转到活动页并保留参数）：
server {
listen 80;
server_name promo.example.com;
return 302 https://event.example.com/campaign$uri?$args;
}
用 rewrite + redirect 也行，但要小心 flag
如果已有 rewrite 规则习惯，可用 redirect 标志触发 302：
- 必须写 redirect，不能写 permanent（那是 301）
- 正则捕获要完整，比如 ^(.*)$ 才能带全路径和查询参数
- 避免放在 if 块里，Nginx 官方不建议在 if 中用 rewrite，易出边界问题
示例（等效于上面的 return 写法）：
server {
listen 80;
server_name promo.example.com;
rewrite ^(.*)$ https://event.example.com/campaign$1 redirect;
}
注意三个容易翻车的点
配完测试时，常因这些细节失效：
- HTTP 和 HTTPS 混用：如果目标是 https，但当前 server 只监听 80，跳转后可能被浏览器拦截或降级；建议统一用 https 目标地址
- $request_uri vs $uri?$args：前者包含完整路径+查询串，后者需手动拼接；用错会导致参数丢失（如 ?utm_source=ad 消失）
- 反向代理场景下漏了 proxy_intercept_errors off：若上游返回 302，Nginx 默认不接管，需显式关闭拦截才能透传；但活动跳转一般自己发，这条通常不涉及
验证是否真跳了 302
别只看浏览器地址栏变了——用 curl 确认状态码：
curl -I http://promo.example.com
输出里必须有 HTTP/1.1 302 Found 和正确的 Location: 头。如果看到 200 或 301，说明配置逻辑有误。
