加权轮询本身不导致丢包，异常根源在连接调度、缓冲或超时协同失效；排查需分三层：先确认是否真为该环节问题，再聚焦upstream转发链路，最后回溯系统资源瓶颈。
加权轮询本身不会直接导致丢包，报文转发异常的根源在连接调度、缓冲机制或超时协同失效，而非 weight 配置错误。排查要分三层：先确认是否真为“加权轮询环节”出问题，再聚焦 upstream 转发链路，最后回溯系统级资源瓶颈。
验证是否真是加权轮询策略引发异常
加权轮询只是请求分发逻辑，不参与数据包收发。若出现丢包、502/504、响应截断等现象，大概率与 weight 无关，而是后端处理能力、健康状态或 Nginx 代理参数不匹配所致：
- 用 access_log 中 $upstream_addr 字段确认请求确实按 weight 分配到了对应节点（例如 weight=3 的机器应接收约 3 倍于 weight=1 的请求数）
- 检查 error.log 是否集中出现某台 upstream 的 “upstream timed out” 或 “Connection refused” —— 若仅某台频繁报错，说明该节点实际不可用，weight 再高也转不过去
- 对比三台后端的 真实处理耗时（P95/P99）和 CPU/内存负载：若 weight=3 的节点响应慢 3 倍，实际吞吐反而更低，此时轮询结果看似“倾斜”，实为后端性能失衡
检查 upstream 连接与缓冲配置是否适配加权场景
加权轮询常用于混合规格后端（如 8C16G 和 2C4G），但若缓冲和超时未按节点能力差异化调优，易触发连接堆积、响应截断或主动关闭：
- proxy_read_timeout 必须对齐后端 keepalive timeout：例如后端 Tomcat 设为 60s，Nginx 应设为 55s；若统一设为 30s，而 weight=1 的小规格节点实际需 40s 响应，就会被强制断连，表现为丢包或 504
- proxy_buffers 和 proxy_buffer_size 需按后端响应体量调整：weight 高的节点若返回大 JSON（>500KB），默认 4K buffer 会截断；建议统一设为 proxy_buffer_size 128k; proxy_buffers 8 128k;
- 启用 keepalive 连接复用：加权轮询下连接更易集中到高 weight 节点，不复用会导致 TIME_WAIT 暴涨；配置 keepalive 200; keepalive_requests 1000; 并透传 HTTP/1.1
定位丢包发生的具体环节
Nginx 不统计 TCP 丢包，但可通过日志信号 + 系统指标交叉判断丢包位置：
- error.log 中高频出现 “upstream prematurely closed connection”：大概率是后端进程崩溃或主动断连，非 Nginx 丢包
- 大量 “client closed connection while waiting for upstream”：客户端因网络不稳定提前断开，常伴移动网络切换或 WiFi 断续，Nginx 无法控制
- 运行 netstat -s | grep -A 3 "Tcp:"，观察 timeouts 是否突增：若上升，说明 SYN 包在防火墙、安全组或中间设备被拦截，未达 Nginx
- 执行 ss -i dst 后端IP:端口，查看单连接的 retrans（重传次数）和 rto（重传超时）：若 retrans > 3，说明链路中存在丢包，需查物理网络或网卡驱动
快速验证与临时缓解
若需快速恢复服务并缩小范围：
- 将 upstream 中疑似故障节点 临时注释或设 backup，观察丢包是否消失——若消失，问题在该节点自身
- 对高 weight 节点单独配置 location 块，加大其超时与缓冲：proxy_read_timeout 120s; proxy_buffer_size 256k;
- 用 hping3 -S -p 后端端口 后端IP 直连测试，绕过 Nginx：若直连也丢包，说明问题在后端或网络层
