紧急维护时推荐用 nginx 的 return 302 实现临时跳转，因其性能高、逻辑清晰、不易出错；需在 server 块中配置监听端口、server_name，并指定目标 url 或结合 $request_uri 保留路径；避免使用 rewrite … redirect，以防匹配冲突；建议添加 cache-control 头防止误缓存，并上线前用 curl -i 验证。
紧急维护时用 Nginx 做临时跳转，核心就是发 302 状态码，告诉浏览器和搜索引擎“这只是暂时的”，原地址依然有效、权重不转移、下次还会回来查。
直接用 return 302 最简洁可靠
这是最推荐的方式，性能高、逻辑清晰、不易出错：
- 在 server 块里加一条 return 302，后面跟目标 URL（比如维护页）
- 保留原始路径用 $request_uri；只跳首页就写死 URL
- 确保该 server 监听的是用户实际访问的端口（通常是 80 或 443）
示例（HTTP 下全站临时跳转到维护页）：
server {listen 80;
server_name example.com;
return 302 https://example.com/maintenance.html;
}
需要带路径参数？用 $request_uri
如果希望用户访问任何页面都跳到新域名的对应路径（比如活动页、备用站点），加上 $request_uri 即可：
- 它会自动拼接原始请求的路径和查询参数（如 /user/profile?id=123）
- 注意目标 URL 要以协议+域名开头（http:// 或 https://），否则会被当成相对路径
示例（临时导流到新活动域）：
server {listen 80;
server_name old-site.com;
return 302 https://event.new-site.com$request_uri;
}
别用 rewrite … redirect 搞混了
虽然 rewrite … redirect 也能发 302，但容易踩坑：
- 它依赖正则匹配，配置稍复杂，且可能因 location 匹配顺序或 flag 冲突导致跳转失效
- return 是硬中断，一执行就返回，不会继续走后续规则；rewrite 则可能被其他 location 覆盖
- 紧急维护场景讲求稳定和可预期，return 更可控
额外提醒：避免缓存干扰
302 本不该被浏览器长期缓存，但部分旧版客户端或中间代理可能误存。为保险起见：
- 可在 return 前加 add_header Cache-Control "no-store, no-cache, must-revalidate";
- 维护结束后，及时删掉该配置并 reload nginx（
nginx -s reload） - 上线前用 curl -I 测试响应头，确认状态码确实是 302，Location 字段正确
