主备切换引发502的根源在于状态不同步与健康检查滞后，表现为切换窗口期集中出现connection refused或upstream timed out，需重点核查upstream实时性、健康探针有效性、新主服务就绪状态及配置一致性。

主备切换本身不是故障，但若切换过程不平滑、状态未同步或健康检查滞后，就极易引发502。这类502的特点是：集中出现在切换窗口期（如秒级到分钟级），错误日志里常伴随 Connection refused 或 upstream timed out，且仅影响部分请求路径——说明网关已尝试转发，但新主节点尚未就绪或旧主已被摘除。

看Nginx upstream状态是否实时更新

主备切换依赖负载均衡器（如Nginx的upstream）动态感知节点健康状态。如果健康检查配置不合理，就可能出现“旧主已下线、新主未注册，但Nginx还在往空地址发请求”的情况。

• 检查Nginx中upstream块是否启用health_check（1.11.5+）或通过check模块（如Tengine）主动探测；仅靠max_fails/fail_timeout被动摘除不够及时
• 确认健康检查路径（如/healthz）在新主节点上真实可访问、返回200，且响应时间远小于interval设置
• 用curl -v http://新主IP:端口/healthz手动验证，避免因路径权限、防火墙或应用启动顺序导致探测失败

查新主节点服务是否真正ready

很多502源于“进程起来了，但服务没准备好”——比如Spring Boot应用虽已监听端口，但数据库连接池未初始化完成、缓存预热未结束、或内部gRPC服务尚未注册成功。

• 不要只看ss -tlnp | grep :8080有监听，要确认应用层健康接口返回{"status":"UP"}且耗时稳定（建议
• 检查应用日志中是否有Started Application in X seconds之后才出现的首次请求处理记录；若502集中在启动后前几秒，大概率是就绪探针太激进
• 对Java类服务，可加JVM参数-Dspring.lifecycle.timeout-per-shutdown-phase=30s避免优雅关闭超时干扰下次启动

核对主备间配置与环境一致性

切换后502突然复现，往往不是服务挂了，而是新主节点的某项配置与旧主不一致，导致请求进来后无法正常路由或鉴权。

• 对比两节点的application.yml或环境变量：特别是server.address（是否误配为127.0.0.1）、spring.profiles.active（是否加载了测试profile）、redis.host或db.url等依赖地址
• 检查Nginx proxy_pass是否硬编码了IP，而非指向upstream name；若用了DNS，确认TTL足够低（建议≤30s），避免DNS缓存导致流量仍打向旧IP
• 容器化场景下，检查Service的Endpoint是否已更新：kubectl get endpoints your-service -o wide，确保IP列表包含新主且无残留旧主

分析错误日志中的时间戳偏移

主备切换引发的502常带有时序特征：一批错误集中在同一秒内爆发，随后迅速收敛。抓准这个窗口，能快速定位是切换动作本身触发的。

• 用awk '/502/{print $4}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -5统计高频出错时间点
• 结合运维操作记录（如Ansible执行时间、K8s rollout时间），比对错误峰值是否严格落在切换命令发出后10–60秒内
• 若错误持续超过2分钟，大概率不是切换问题，而是新主节点存在更深层缺陷（如磁盘满、OOMKilled）