权重配置不当不会直接引发502，但会加剧后端不均衡，使高权重节点因流量过载而率先假死或响应异常，导致502集中出现在该节点；需通过错误日志定位异常IP，核查其资源占用、监听队列、服务日志及响应头大小，并确保健康检查配置统一。
权重设置过大本身不会直接引发故障，但会让高权重节点承担远超其处理能力的请求量，从而加速过载、响应延迟甚至假死，最终集中暴露 502、超时或连接拒绝等问题。排查关键不是调低 weight 数字，而是确认“这个权重是否把流量压向了一个实际撑不住的节点”。
看错误日志里 502 是否扎堆在某台高权重点
加权轮询下，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）在错误记录中占比极高（如超过 70%），而它恰好配置了 weight=10，那它就是重点怀疑对象——权重是导火索，真因在它自身能力或状态。
查这台节点的真实负载是否已明显超标
不能只看 weight 数值，要核对它当前的运行实况：
- CPU 使用率、内存占用、活跃连接数（ss -s 或 netstat -an | grep :8080 | wc -l）是否显著高于其他节点
- 监听队列是否持续溢出（netstat -s | grep "listen overflows" 数值是否快速上涨）
- 后端服务日志里有没有 OOM killed、too many open files、max threads reached 等关键报错
- 它是否运行着调试模式、旧版本代码或额外中间件，导致响应更慢、头更大
验证响应行为是否和其他节点一致
高权重节点若返回异常响应，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 '^
如果高权重点响应头远超其他节点（例如 >4KB），而 Nginx 没有调大 proxy_buffer_size，就会只在这台机器上触发 upstream sent too big header 类型的 502。
检查健康检查配置是否统一启用
权重常和 max_fails/fail_timeout 配合使用，但容易忽略一致性：
- 所有 server 行必须统一启用健康检查，不能有的写 max_fails=2 fail_timeout=30s，有的完全没写
- 若某节点曾被临时降权（如 weight=1），但没配 max_fails，Nginx 就不会自动剔除它——哪怕它已开始间歇性失败，流量仍按权重照发
- 用 nginx -T 确认生效配置中，该节点是否真的处于可参与轮询的状态（未被标记为 down 或长期处于 unhealthy）
