紧急维护时用Nginx做302跳转应优先使用return指令，精准匹配用户页面路径并放行API等必要接口，同时添加Cache-Control等响应头防止缓存，并通过curl和浏览器开发者工具三步验证生效。
紧急维护时用 Nginx 做 302 跳转，核心是明确“临时性”、避免被搜索引擎缓存原地址，并确保用户能快速看到维护提示页。配置不复杂，但关键细节容易出错。
用 return 指令实现最简可靠的 302
推荐优先使用 return，它轻量、高效、语义清晰，适合维护场景：
- 在 server 或 location 块中直接写：
return 302 /maintenance.html; - 若需跳转到外部维护页（如统一维护中心），用完整 URL：
return 302 https://status.yoursite.com/maintenance; - 注意：
/maintenance.html必须真实存在于 Nginx 的 root 目录下，且有可读权限
按路径或条件精准触发跳转
不是全站都跳，而是只对用户可见页面做跳转，后台接口、健康检查等应放行：
- 只对 HTML 页面跳转（排除 API、静态资源）：
location / {<br> if ($request_filename ~ \.html$) {<br> return 302 /maintenance.html;<br> }<br>} - 更稳妥的做法是用 location 匹配主入口路径，例如：
location / {<br> return 302 /maintenance.html;<br>}
再单独放行 API：location /api/ { proxy_pass http://backend; }
确保浏览器不缓存 302 响应
虽然 302 默认不缓存，但某些 CDN 或中间代理可能误缓存。主动加响应头更保险：
- 在 return 同级或 location 块中添加：
add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";<br>add_header Pragma "no-cache";<br>add_header Expires "Wed, 11 Jan 1984 05:00:00 GMT";
- 这样即使遇到异常缓存，也能强制每次重新请求
验证是否生效的三步法
别只靠浏览器刷新看效果，要确认状态码和响应头：
- 用 curl 检查真实返回：
curl -I http://yoursite.com/→ 看是否含HTTP/1.1 302 Found和正确Location头 - 打开浏览器开发者工具 → Network 标签 → 刷新页面 → 查看首条请求的状态码和响应头
- 临时注释掉跳转配置，确认维护页本身能正常访问（排除文件路径或权限问题）
