必须开启proxy_intercept_errors并配合error_page、internal location和proxy_next_upstream，才能实现后端502/503/504错误的统一拦截、友好提示、防直访及自动重试闭环。
在反向代理场景下，Nginx 默认会把后端返回的 502、503、504 等错误原样透传给用户，既不拦截也不美化。要实现统一拦截 + 可读提示，关键不是只放一个 HTML 文件，而是构建「拦截 → 替换 → 防直访 → 可控响应」这一闭环。
必须开启 proxy_intercept_errors
这是整个流程的开关。没有它，error_page 对后端错误完全失效：
- proxy_intercept_errors on; 必须写在 proxy_pass 所在的 location 块内
- 它只对后端返回的 4xx/5xx 状态码起作用；若后端返回 200 但内容是错误 JSON，Nginx 不管——那是业务该处理的
- 建议显式配置，不要依赖默认值（某些旧版本默认 off）
用 error_page 绑定错误码与内部路径
指定哪些状态码触发跳转，并指向一个内部 location：
- 写法示例：error_page 500 502 503 504 = /error;（带等号表示用 /error 返回的状态码覆盖原始错误码）
- 若想保留原始状态码（如仍返回 502），可写成 error_page 502 /error;，但需在 /error 中显式 return 502
- 多个错误码可合并写，避免重复配置
定义 internal location 并返回结构化内容
这个 location 是真正生成提示的地方，必须加 internal 防止被外部直接访问：
- location = /error { internal; } —— 路径必须严格匹配，且不能有别名或正则
- 推荐用 return 直接构造响应，例如：return 502 '{"code":502,"message":"服务暂时不可用","trace_id":"'$request_id'"}';
- 加上 add_header Content-Type "application/json; charset=utf-8"; 确保前端能正确解析
- HTML 提示页也适用：配合 root 和 try_files，但记得在对应 location 中加 internal 和 root 指向静态资源目录
可选：加一层自动重试兜底
对临时性故障（如网络抖动、上游瞬时超时），可配合 proxy_next_upstream 提升可用性：
- 在 upstream 或 location 中配置：proxy_next_upstream error timeout http_502 http_504;
- 再搭配 proxy_next_upstream_tries 3; 和 proxy_next_upstream_timeout 3s; 控制重试行为
- 注意：它和 error_page 是协作关系，不是替代关系——重试失败后仍会走到 error_page 流程
