核心是利用 proxy_next_upstream 配合健康检查失败后 fallback 到本地静态维护页：需配置 upstream 主动探测、proxy_next_upstream 触发重试、proxy_intercept_errors on 拦截错误并由 error_page 500 502 503 504 指向 /maintenance.html，该文件须置于 root 目录下且可读。
在 Nginx 中实现故障转移期间返回自定义维护页面，核心是利用 proxy_next_upstream 机制配合健康检查失败后 fallback 到本地静态页。关键不在于“切换服务器”，而是在上游全部不可用时，优雅降级到本地维护页。
配置 upstream 并启用主动健康检查
先定义带健康检查的 upstream，让 Nginx 主动探测后端可用性：
upstream backend {
server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
# 可选：开启主动健康检查（需 nginx plus 或开源版 + lua 模块）
# health_check interval=5 fails=2 passes=2;
}注意：max_fails 和 fail_timeout 控制“多快”判定节点失效，直接影响故障转移灵敏度。
用 proxy_next_upstream 触发重试与降级
在 location 块中启用重试，并明确哪些错误触发 fallback：
location / {
proxy_pass http://backend;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 2;
proxy_next_upstream_timeout 10s;
<pre class="brush:php;toolbar:false;"># 当所有 upstream 都失败时，跳转到本地维护页
proxy_intercept_errors on;
error_page 500 502 503 504 /maintenance.html;}
-
proxy_next_upstream指定哪些响应会让 Nginx 尝试下一个 upstream 节点 -
proxy_intercept_errors on是关键——它允许 Nginx 拦截 upstream 返回的错误状态码，转而执行error_page -
error_page 500... /maintenance.html必须指向一个本地可访问的静态文件（如放在/usr/share/nginx/html/maintenance.html）
提供静态维护页并确保可访问
将维护页面放入 Nginx 的 root 目录（如 /usr/share/nginx/html/），确保权限和路径正确：
- 文件需存在且 Nginx worker 进程有读取权限
- 建议在 server 块中显式声明 root，避免路径歧义：
root /usr/share/nginx/html; - 可为维护页单独加个 location，禁止缓存、开放直接访问：
location = /maintenance.html {<br> add_header Cache-Control "no-store, no-cache";<br>}
验证与调试要点
上线前务必验证流程是否闭环：
- 临时停掉所有 upstream 服务，curl 访问站点，确认返回 503 + 维护页内容
- 检查 Nginx error log，看是否有
upstream timed out或no live upstreams类提示 - 若维护页不显示，常见原因：
–proxy_intercept_errors未开启
–error_page路径不对或文件不存在
– 维护页本身返回了 404，导致循环错误
