加权轮询不直接导致502，但权重与节点实际能力不匹配会使低配节点过载失联，集中暴露502；需通过错误日志定位故障节点，核查其资源使用、连接队列及响应头大小，并验证健康检查配置一致性。
加权轮询本身不直接压垮服务器，但当权重配置未匹配实际服务能力时，低配节点会因流量过载迅速失联、响应超时或返回异常，最终集中暴露 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 - 若低配节点（如 192.168.1.30:8080，weight=2）占全部 502 的 70% 以上，说明它已成为故障单点
- 注意：该节点可能被高权重节点“连带拖累”——比如高权重点响应慢，Nginx 重试时频繁 fallback 到它，加剧其负担
查真实负载，确认资源是否已触顶
权重只是调度比例，不能掩盖硬件或服务瓶颈。登录该低配节点，验证实际承载情况：
- CPU 和内存使用率是否持续 >90%（用
top或htop） - 连接数是否远超其他节点：
ss -s | grep "TCP:"或netstat -an | grep :8080 | wc -l - 监听队列是否溢出：
netstat -s | grep "listen overflows"——数值持续增长说明请求进不来 - 后端服务日志中是否有 OOM killed、too many open files、max threads reached 等关键报错
验响应行为，排除协议层兼容问题
低配节点常因性能妥协而引入隐性风险，比如启用调试模式、旧版中间件或冗余响应头，导致 Nginx 在读取阶段直接拒收：
- 逐个直连测试健康接口：
curl -v http://192.168.1.30:8080/health 2>&1 | grep '^ - 对比各节点响应头大小，若低配节点明显超标（如 >4KB），而 Nginx 未调大
proxy_buffer_size，就会只在此节点触发 upstream sent too big header 类 502 - 检查是否返回非法字符、状态行格式错误（如多空格、换行符）、或非标准 HTTP 版本，这些都可能让 Nginx 解析失败
核对 upstream 配置一致性，避免健康检查干扰判断
低配节点更容易因响应慢被健康检查误判为故障，从而退出轮询——这会让剩余节点压力倍增，形成恶性循环：
- 确认所有
server行是否统一配置了max_fails和fail_timeout；若低配节点没写，它将永不进入 fail 状态，但可能长期卡住请求 - 临时关闭健康检查（注释掉
max_fails和fail_timeout），再用短连接压测（如wrk -c 100 -d 30s --timeout 2s http://nginx/），观察低配节点是否仍率先失联 - 检查是否混用了
ip_hash或hash $cookie_session——一旦启用，加权轮询完全失效，所有同源请求全打到同一节点
