限时促销临时跳转必须用302而非301，推荐return 302配置，需写完整目标URL并保留$request_uri；rewrite redirect适用于正则匹配场景；注意目标可达、避免与proxy_pass混用、统一跳转层级，活动结束时注释配置即可回切。
限时促销临时跳转必须用 302，不能用 301 —— 否则搜索引擎会误判为永久迁移，导致原页面权重流失、活动结束也无法恢复流量。
明确使用 return 302（推荐）
简单、高效、语义清晰，适合纯跳转场景：
- 直接在 server 块中配置，匹配促销子域名或路径
- 保留原始请求路径和参数（用 $request_uri），方便活动页识别来源
- 跳转目标 URL 必须写完整协议+域名，例如 https://promo.example.com
示例配置：
server {listen 80;
server_name shop.example.com;
return 302 https://promo.example.com$request_uri;
}
用 rewrite + redirect（兼容旧写法）
适用于需要正则匹配路径的场景，比如只对 /sale/ 开头的请求跳转：
- rewrite ... redirect 显式触发 302，和 return 302 效果一致
- 注意不要漏掉 redirect 标志，否则默认是内部重写（不跳转）
- 避免在 if 块里滥用 rewrite，Nginx 官方不推荐 if + rewrite 组合
示例：
location ^~ /sale/ {rewrite ^/sale/(.*)$ https://promo.example.com/sale/$1 redirect;
}
关键细节别踩坑
302 跳转看着简单，但几个细节错一点就失效或伤 SEO：
- 跳转目标必须可访问且返回 200，否则用户看到空白页或报错
- 不要混用 return 302 和 proxy_pass 在同一 location，return 会终止所有后续处理
- 如果后端应用本身也发 302（比如 Spring RedirectView），Nginx 层再套一层容易引发跳转链，建议统一由 Nginx 控制
- 测试时用 curl -I 看响应头，确认状态码是 302 Found，Location 字段正确，且没有缓存头（如 Cache-Control: public）
活动结束时快速回切
302 的优势就是“随时可撤”：
- 活动下线只需注释或删掉对应配置，reload nginx 即生效
- 无需清理浏览器或 CDN 缓存（302 默认不被缓存）
- 原页面 URL 流量自动回归，搜索引擎仍持续抓取老地址
