正确做法是使用upstream定义主备节点并配合proxy_next_upstream实现502自动重试与故障转移，而非在location中用if或多个proxy_pass硬编码处理；需配置max_fails、fail_timeout、proxy_next_upstream等参数，并提供自定义502页面。
location 块本身不能“处理”502 错误，也不能在内部做路径切换或重试——它只是请求路由规则。真正优雅应对 502 的方式，是把容错逻辑交给 upstream + proxy_next_upstream 机制，让 Nginx 在代理层自动完成重试与故障转移，而不是在 location 里写 if、多 proxy_pass 或硬编码备用地址。
用 upstream 定义主备，而非在 location 里拼路径
错误做法：在 location 中试图用 if 判断状态码、或写多个 proxy_pass；Nginx 不支持运行时判断后端响应码来改写 proxy_pass，且这类配置不可靠、难维护、易出错。
- 正确做法：定义一个含主节点和 backup 节点的 upstream 块，把容错能力下沉到连接池层面
- 主节点配置 max_fails 和 fail_timeout，实现被动健康探测（例如连续 2 次失败，10 秒内不发新请求）
- backup 节点仅当所有非 backup 节点都被标记为不可用时才启用，避免过早切换
开启 proxy_next_upstream，精准控制 502 重试行为
光有 upstream 还不够，必须显式启用并约束重试逻辑，否则默认不重试 502：
- proxy_next_upstream error timeout http_502：明确将 502 视为可重试条件，同时覆盖连接失败、超时等底层异常
- proxy_next_upstream_tries 3：最多尝试 3 次（含首次），防止雪崩式重试
- proxy_next_upstream_timeout 10s：整个重试过程不超过 10 秒，避免用户长时间等待
配好基础代理参数，避免重试被干扰
某些常见配置会无意中破坏重试效果，需特别注意：
- 关闭主动 health_check（除非你有强依赖的 L7 探针），优先用 max_fails/fail_timeout 这类被动探测更稳定
- 确保 proxy_http_version 1.1 和 proxy_set_header Connection "" 已设置，防止 HTTP/1.0 连接复用导致重试失败
- proxy_buffer_size 和 proxy_buffers 大小要适配后端响应体，缓冲区不足也可能间接触发 502
配合自定义 502 页面，提升终端体验
即使做了自动故障转移，仍可能所有后端都不可用。这时返回一个友好、带品牌信息的 502 页面比裸露 nginx 默认页更专业：
- 准备静态 HTML 文件（如 /usr/share/nginx/html/502.html），内容可含客服入口、刷新提示、返回首页链接
- 在 server 或 http 块中加：error_page 502 /502.html;
- 确保该 location 存在且能直接返回静态文件：location = /502.html { root /usr/share/nginx/html; }
