502错误主因是流量切换后新路径不通，需聚焦链路变化：检查proxy_pass地址有效性、upstream名称一致性、新服务监听状态、DNS解析、连通性及响应、抓包分析建连与协议行为、超时与缓冲区匹配。

流量切换后出现大量502错误，核心问题不是“服务挂了”，而是“新路径不通”——Nginx（或网关）按新配置转发请求，但上游服务未就绪、不可达或响应异常。排查要聚焦在“切换动作引发的链路变化”上，而不是泛泛查负载或日志。

确认切换是否真正生效且配置无硬伤

很多502直接源于配置写错，却因不报错而潜伏到切流时爆发：

• 检查 proxy_pass 地址是否指向真实监听的IP+端口，尤其注意：localhost/127.0.0.1 只对本机有效，跨节点部署时必须用实际内网IP
• 核对 upstream 块名称是否与 location 中 proxy_pass 引用的完全一致（大小写、下划线、拼写）
• 确认新服务实例已启动，并监听了配置中指定的端口（netstat -tuln | grep :8080）
• 若使用域名（如 http://backend-svc），验证 DNS 解析是否已生效（dig backend-svc +short），避免缓存导致解析仍指向旧地址

验证新上游服务的连通性与基础响应能力

不能只看进程在不在，要模拟Nginx视角发起一次真实连接：

• 从Nginx所在服务器执行：curl -v http://新上游IP:端口/health，观察是否返回200及响应时间
• 若超时或拒绝连接，检查防火墙（iptables -L -n）、安全组、SELinux 是否拦截了新端口
• 若返回非HTTP响应（如空包、RST、TLS握手失败），说明服务未正确暴露HTTP接口（例如Spring Boot默认只监听HTTP/1.1，但Nginx启用了HTTP/2）

抓包比对新旧路径的行为差异

切流前后对比网络行为，能快速定位是连接层、协议层还是应用层问题：

• 在Nginx服务器上对新上游目标抓包：tcpdump -i any host 新IP and port 新端口 -w switch.pcap
• 用Wireshark打开，过滤 tcp.flags.syn == 1 看是否能建连；过滤 tcp.analysis.retransmission 看有无重传；过滤 http 看是否有响应包
• 重点比对：旧路径能收到200响应，新路径是否卡在SYN_SENT、收到RST、或收到响应但内容非法（如非HTTP格式）

检查Nginx与新上游的超时和缓冲区匹配度

新服务响应特性可能与旧服务不同，原有超时设置会直接触发502：

• 查看 error.log 中具体报错，常见如："upstream timed out"（proxy_read_timeout） 或 "no live upstreams"（健康检查失败）
• 临时调大关键超时（仅用于验证）：proxy_connect_timeout 15s; proxy_send_timeout 60s; proxy_read_timeout 60s;
• 若新服务启用Keep-Alive，确认 keepalive_requests 值足够（现代前端单页常发数百请求，设100易触发连接复用失败）