Nginx紧急故障302跳转应使用return指令优先，确保快速明确、不干扰SEO；需正确处理路径参数与外部跳转，避免误配301或缓存；rewrite需加redirect标志；必须设置Cache-Control防误缓存；验证须确认状态码为302且维护页可访问。
紧急故障页面跳转时，Nginx 配置 302 重定向的核心目标是：快速、明确、不干扰 SEO，且确保用户看到备用页面，同时搜索引擎仍认定原地址有效。关键不是“加个跳转”，而是避免误配成 301 或缓存行为异常。
用 return 指令最稳妥
这是推荐首选方式——简洁、高效、语义清晰，不易出错：
- 直接在 server 或 location 块中写：
return 302 /maintenance.html; - 若需保留原始路径参数（如 /order/123?ref=ad），改用：
return 302 /maintenance.html?$query_string; - 若跳转到外部维护页（如 https://status.example.com），写全协议：
return 302 https://status.example.com/down?path=$request_uri;
用 rewrite + redirect 要注意匹配精度
适合需要正则判断的场景（比如只对特定路径或用户代理跳转），但必须加 redirect 标志，否则默认是内部重写（地址栏不变）：
- 全部请求临时跳转到维护页：
rewrite ^(.*)$ /maintenance.html redirect; - 仅对 /api/ 开头的请求跳转（保留后端健康检查不中断）：
location /api/ { rewrite ^/api/(.*)$ /maintenance.html redirect; } - 切勿漏掉 redirect —— 写成 rewrite ... break; 或不带 flag，会导致静默重写，用户看不到跳转效果。
务必禁用浏览器缓存干扰
302 本不该被缓存，但某些旧客户端或中间代理可能误存。可在响应头中显式控制：
- 在对应 location 或 server 块中加入：
add_header Cache-Control "no-store, must-revalidate, max-age=0"; - 配合 return 使用更安全：
location = /maintenance.html { add_header Cache-Control "public, max-age=3600"; }
验证是否生效的三步法
别只看浏览器跳转，要确认状态码和响应头准确无误：
- 用 curl 测试：
curl -I http://yoursite.com/any-path → 检查返回 HTTP/1.1 302 Found 和 Location: /maintenance.html - 打开 Chrome DevTools → Network 标签 → 刷新页面 → 查看跳转请求的 Status 列是否为 302（不是 301，也不是 200）
- 确认维护页本身返回 200，且内容可访问（避免跳过去又 404）
