必须用 return 302 实现临时维护跳转，因其直接返回 http/1.1 302 found 与绝对 url 的 location 头，精准传达“临时不可用”语义；需避免 rewrite、error_page 或相对路径，维护页须 internal 保护并配 no-cache 响应头。
系统维护升级时，Nginx 用 return 302 是向搜索引擎表明“临时不可用”的最直接方式——它不传递权重、不被长期缓存、每次请求都由服务器重新判断，完全符合搜索引擎对临时状态的语义理解。
必须用 return 302，而不是 rewrite 或 error_page
return 指令会立即返回 HTTP/1.1 302 Found 状态码和 Location 头，搜索引擎能明确识别这是临时跳转。而：
- rewrite + redirect 虽然也发 302，但多一层正则匹配，性能略低，且易与 last/break 混用导致内部重写
- error_page 默认触发内部重定向，不改变状态码；若强行配 302，需配合命名 location，逻辑冗余且易出错
- if 块中 return 302 可用，但仅限简单判断（如文件存在性），避免嵌套或复杂条件
目标地址必须是完整 URL（含协议+域名）
搜索引擎依赖 Location 响应头中的绝对地址做索引判断。如果只写 /maintenance.html，Nginx 返回的是相对路径，浏览器会拼在原域名下，搜索引擎仍认为你在同一站点内跳转，无法体现“服务暂离”意图。
- ✅ 正确：
return 302 https://example.com/maintenance.html; - ❌ 错误：
return 302 /maintenance.html;（站内跳转，非语义化临时状态） - ⚠️ 注意：URL 中含变量（如
$host）时，务必用双引号包裹，防止空格或特殊字符解析失败
确保维护页本身不被跳转规则覆盖
否则会触发跳转循环，搜索引擎爬虫可能收到 302 → 302 → … → 超时，最终放弃抓取。关键做法是单独声明维护页路径，并加 internal 限制：
- 用
location = /maintenance.html精确匹配，避免被泛匹配规则捕获 - 加上
internal;，禁止用户或爬虫直接访问该 URL，只允许 Nginx 内部跳转调用 - 维护页 HTML 文件需真实存在，且响应 Content-Type 为
text/html（Nginx 默认支持）
可选但推荐：加提示头辅助识别
便于监控系统、前端脚本或 SEO 工具快速识别当前处于维护模式：
-
add_header X-Maintenance "true" always;—— 强制添加，不随缓存丢失 -
add_header Cache-Control "no-store, no-cache, must-revalidate" always;—— 防止 CDN 或代理错误缓存 302 响应 - 不要设
Expires或max-age，保持响应“无缓存”特性
配置完成后，用 curl -I https://example.com/ 验证响应头：必须看到 HTTP/1.1 302 Found 和正确的 Location:，且没有 301 或 200 混入。搜索引擎会在下次抓取时自然接受这个临时信号，无需额外提交或通知。
