紧急维护时用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 目录下，且有可读权限

按路径或条件精准触发跳转

不是全站都跳，而是只对用户可见页面做跳转，后台接口、健康检查等应放行：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 只对 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 标签 → 刷新页面 → 查看首条请求的状态码和响应头
• 临时注释掉跳转配置，确认维护页本身能正常访问（排除文件路径或权限问题）