Nginx负载均衡器需通过proxy_intercept_errors on、error_page映射及upstream重试协同实现维护页接管：仅对4xx/5xx响应生效，须在location块配置error_page 500 502 503 504 /maintenance.html，并配对应location块与MIME类型，配合proxy_next_upstream容错与合理超时，确保所有后端重试失败后才触发维护页。
要让 Nginx 负载均衡器在后端全部不可用或返回错误时，统一展示维护页或降级页，关键不是“拦截失败”，而是“接管响应”——靠 proxy_intercept_errors 开关 + error_page 映射 + 后端重试策略协同实现。
必须开启并限定作用域的拦截开关
proxy_intercept_errors on; 默认关闭，必须显式启用，且建议放在 location 块内（而非 http 或 server 级），避免影响静态资源等非代理路径。
- 它只对后端返回的非空 4xx/5xx 响应生效（例如后端 PHP 返回 500、Node.js 返回 502）
- Nginx 自身生成的 502/503/504（如 upstream 全连接拒绝、全超时）同样受控，只要配了对应
error_page - 不处理 200 状态码下的业务错误（哪怕响应体是错误 HTML），因为 Nginx 只看状态码
精准声明要捕获的状态码并指向可访问页面
光开开关没用，必须配对 error_page，例如：
error_page 500 502 503 504 /maintenance.html;
- 推荐覆盖 500、502、503、504 —— 这四类最常见于负载均衡故障场景
- 若想隐藏原始错误码（如把 503 改成 200），写成：
error_page 503 =200 /maintenance.html; - 页面路径是 URI，不是文件系统路径；必须有对应
location = /maintenance.html块，并配置root或alias指向真实文件位置 - 确保该 location 下 MIME 类型正确（
include mime.types;或显式设置types { text/html html; }）
与 upstream 容错机制配合减少误触
拦截是兜底，重试是预防。两者结合才能让维护页真正“最后才出现”：
- 在 upstream 块中启用容错：
proxy_next_upstream error timeout http_502 http_503 http_504; - 设置合理超时：
proxy_connect_timeout 1s;、proxy_read_timeout 3s;，避免单节点卡死拖垮整体 - 只有所有后端都重试失败后，Nginx 才生成最终错误响应，此时
error_page才接管，逻辑更合理
验证是否真正生效的实操方式
别只看配置有没有语法错误，要验证流量是否真的被接管：
- 临时停掉所有后端服务，用
curl -v https://your-domain/api/test观察返回：状态码是否为你设定的（如 200），响应体是否为maintenance.html内容 - 在
location = /maintenance.html中加一句add_header X-Handled-By "nginx-error-page";，通过响应头确认是否走到了 Nginx 的自定义逻辑 - 检查 Nginx 错误日志，正常触发时会有类似
upstream prematurely closed connection或no live upstreams记录
