502表示负载均衡未收到后端有效响应，常见于后端进程宕机、端口未监听或防火墙拦截；504表示请求已抵达后端但响应超时，多因数据库慢查、线程池耗尽或依赖服务不可用。
负载均衡错误代码不是随机出现的，每个状态码都对应明确的故障环节。关键在于结合日志、监控和请求链路分段验证，而不是只看返回码本身。
先分清是哪一层出的问题
错误发生在客户端、负载均衡器还是后端，处理方式完全不同：
- 用 curl -v 观察完整请求过程：如果卡在 DNS 解析或 TLS 握手，问题在客户端或网络；如果请求发出去但没收到响应头，大概率是负载均衡或后端阻塞
- 登录负载均衡控制台，查看“后端健康状态”和“连接队列长度”：若大量节点显示 DOWN，优先查健康检查配置是否误判；若队列堆积但节点全绿，说明后端响应慢或超时设置过短
- 绕过负载均衡，直接 curl http://
: ：能通说明后端服务正常，问题出在负载均衡转发逻辑、安全组、或协议兼容性上/health
重点盯住 502 / 504 的真实含义
这两个码表面相似，根源完全不同：
- 502 Bad Gateway：负载均衡器根本没收到后端的有效响应。常见于后端进程未启动、端口未监听、防火墙拦截健康检查、或返回非 2xx 状态码（比如 /health 返回 302）
- 504 Gateway Timeout：请求已成功发到后端，但后端迟迟不回响应头。典型场景包括数据库慢查询、线程池耗尽、GC 暂停、或依赖服务（如 Redis、MQ）不可用
- 查 Nginx error_log 时，注意 “upstream timed out” 后面的短语：“while connecting” 是网络层问题，“while reading response header” 是后端业务卡住，“while sending request” 则要怀疑后端连接池满或接收缓冲区溢出
别忽略配置和资源类低级错误
很多报错看着像架构问题，实际是基础项没配对：
- 运行 nginx -t 或 haproxy -c -f 验证配置语法，一个漏掉的分号或拼错的 proxy_pass 就会导致静默失败
- 用 ss -s 查 socket 连接数，接近系统上限（如 65535）会触发 “too many open files”，需调大 net.core.somaxconn 和 ulimit
- 云厂商负载均衡（如 AWS ALB）要重点看 CloudWatch 中的 HTTPCode_ELB_5XX（负载均衡自身错误）和 TargetResponseTime（后端响应耗时），不能只盯后端指标
用日志字段交叉验证，避开误判
单条 error_log 很难定因，必须组合多个变量看趋势：
- 对比 $upstream_connect_time 和 $upstream_header_time：前者高波动 → 网络抖动；后者持续升高 → 后端处理变慢
- 看 $upstream_status 字段：如果是 “504,504,200” 这类多段码，说明重试机制在起作用，但后端已不稳定；如果全是单个 200 却偶发 timeout，更可能是瞬时网络丢包
- 把 error_log 和 access_log 按时间戳对齐，确认超时请求是否集中在某台后端 IP（$upstream_addr），再针对性查那台机器的 CPU、内存、线程堆栈
