Nginx可通过proxy_intercept_errors on配合error_page指令统一兜底展示维护页，拦截502/503/504等上游错误并跳转至自定义页面，需在location中启用、配对声明状态码、确保路径可访问，并与proxy_next_upstream协同实现故障重试后再降级。
要让 Nginx 在负载均衡场景下，对所有后端服务故障（如节点宕机、超时、502/503/504）统一展示一个维护页或降级页，核心就是 proxy_intercept_errors 和 error_page 的协同配合。它不依赖后端是否健康，而是靠状态码触发拦截与接管，真正实现“前端兜底”。
必须开启并精准控制拦截范围
proxy_intercept_errors 默认是 off，必须显式设为 on 才生效。但它本身不决定显示什么，只起“开关”作用：一旦开启，且后端返回 4xx/5xx 状态码（响应体非空），Nginx 就会中断透传，转而查找对应 error_page 指令。
- 推荐在具体 location 块中开启，避免 http 或 server 级别误影响静态资源等非代理路径
- 不要只写 proxy_intercept_errors on;，必须搭配 error_page 显式声明要捕获哪些状态码
- 常见兜底组合：error_page 400 401 403 404 500 502 503 504 /error.html;
让 502/503/504 这类上游故障也能被接管
当 upstream 中所有节点都不可达（连接拒绝、全超时），Nginx 自身会生成 502/503/504 响应。这类错误同样受 proxy_intercept_errors 控制——只要开启 + 配了对应 error_page，就能统一跳转到维护页。
- 注意：500 类若由 Nginx 自身语法错误（如 rewrite 循环）触发，不走 proxy 流程，不受此指令影响
- 确保 error_page 指向的路径可访问，例如用
location = /error.html { root /usr/share/nginx/html; } - 若想隐藏原始状态码，可用
error_page 502 503 504 =200 /error.html;，返回 200 状态
与 upstream 故障转移策略协同使用
proxy_intercept_errors 解决的是“错误展示”，而 upstream 的容错能力决定“是否真走到错误”。两者要配合，才能减少用户看到错误页的概率。
- 启用
proxy_next_upstream error timeout http_502 http_503 http_504;，让单次失败自动重试其他节点 - 设置合理超时：
proxy_connect_timeout 1s; proxy_read_timeout 3s;，避免卡死等待 - 若重试后仍全部失败，才最终触发 error_page，此时展示统一维护页更合理
验证是否真正生效
光配对不等于跑通。最直接的验证方式是模拟后端返回错误响应：
- 用 curl -v 请求接口，观察返回的状态码和 body 是否来自你配置的 error.html
- 临时在 error_page 对应的 location 中加
add_header X-Error-Handled "true";，通过响应头确认是否被 Nginx 接管 - 查看 error.log，搜索 “intercept” 或 “error_page”，确认拦截日志是否输出
