报错是这么冒出来的。nginx 1.22 的 upstream 里配了两台主节点加一台 backup，主节点进程挂掉之后请求仍然报 502，backup 那台机器上一条访问日志都没有。
中间走过弯路，把「健康检查依赖被动探测，失败次数没累计够就被重置」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。upstream 里没写 max_fails 和 fail_timeout，nginx 还认为主节点可用。也可能是backup 只在一组主节点全部被标记失败后才启用，单台挂掉不触发。
少数情况下是proxy_next_upstream 没包含 error，连接被拒后不再换节点重试。
动手时先确认 nginx 有没有把主节点判死
curl -s http://127.0.0.1/nginx_status | head给 upstream 补上失败判定和重试条件
grep -nE 'max_fails|proxy_next_upstream' /etc/nginx/conf.d/site.conf然后改完后重载并模拟一台主节点故障
nginx -t && systemctl reload nginx && systemctl stop app剩下的就是看 backup 是否接手流量
tail -5 /var/log/nginx/access.log恢复的判定其实很直接。停掉一台主节点后请求全部落到健康节点和 backup 上，返回 200，backup 机器上的访问日志开始出现记录。
容易忽略的是，backup 只是兜底，不能替代多活；被动健康检查要等真实请求失败才生效，对延迟敏感的业务建议单独起主动探活。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。