加权轮询本身不直接导致502，但权重配置不当会加剧后端不均衡，使高权重节点率先过载并集中暴露502；需通过错误日志定位异常节点，核查其资源、响应头大小及健康检查配置一致性。
Nginx 加权轮询本身不会直接导致 502，但权重配置不当会放大后端节点间的不均衡压力，让本就脆弱的高权重节点率先过载、假死或响应异常，从而集中暴露 502 问题。排查重点不是“权重设错了”，而是看权重是否把流量不合理地压向了能力不足或配置异常的节点。
看日志里 502 是否集中在特定 upstream 地址
加权轮询下，502 不会均匀分布。打开 /var/log/nginx/error.log，用以下命令快速统计：
grep "upstream.*failed\|502" /var/log/nginx/error.log | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}:[0-9]+' | sort | uniq -c | sort -nr
如果某台 IP:端口（比如 192.168.1.20:8080）在错误记录中出现频次远高于其他节点（例如占全部 502 的 80% 以上），而它恰好是 weight=10 的那个，就要立刻盯住它——权重只是导火索，真因在它自身。
检查各节点实际承载与权重是否匹配
权重只是调度比例，不代表节点真实处理能力。需人工核对：
- 该节点的 CPU、内存、连接数（
ss -s或netstat -an | grep :8080 | wc -l）是否明显高于其他节点； - 它的
accept queue是否持续溢出（netstat -s | grep "listen overflows"数值增长快）； - 它的后端服务日志里是否有
OOM killed、too many open files、max threads reached等关键错误； - 它是否运行着调试模式、额外中间件或旧版本代码，导致响应头更大、耗时更长。
验证所有节点响应行为是否一致
加权轮询下，若某节点返回的响应头过大（如 JWT 过长、Cookie 冗余）、响应体含非法字符、或 HTTP 状态行格式异常，Nginx 会在读取阶段直接拒收并报 502。此时需逐个直连验证：
curl -v http://192.168.1.10:8080/health 2>&1 | grep '^curl -v http://192.168.1.20:8080/health 2>&1 | grep '^<br> 对比字节数。若高权重点头大小明显超标（比如超 4KB），且 Nginx 配置未调大 <code>proxy_buffer_size，就会只在这台机器上触发upstream sent too big header类 502。
检查 upstream 块内是否混用不同健康策略
权重常和 max_fails/fail_timeout 共用，但容易忽略一致性：
- 所有
server行必须统一启用健康检查，不能有的写max_fails=2 fail_timeout=30s，有的完全没写； - 若某节点因历史原因被临时降权（如
weight=1），但没配max_fails，Nginx 就不会自动剔除它——哪怕它已开始间歇性失败，流量仍会按权重打过去，造成稳定 502； - 确认没有节点误配了
backup、down或slow_start参数，导致调度逻辑与预期不符。
不复杂但容易忽略
