加权轮询本身不触发限流，但会放大高权值节点负载压力，使其率先触达自身限流阈值；需结合Nginx日志、后端监控与健康检查配置综合排查。
加权轮询本身不会触发后端限流，真正导致限流的是流量分发后，某些后端节点因权重过高、响应变慢或连接堆积，超出其自身处理能力，从而被自身的限流策略（如令牌桶、QPS阈值、线程池满）拦截。排查的关键不是“加权轮询是否触发了限流”，而是“加权轮询是否放大了某台后端的负载压力，使其率先触达限流边界”。
看后端实际承接的请求量与响应分布
加权轮询长期比例接近设定值，但短时间可能不均衡。需确认：某台高权值节点是否在单位时间内收到远超预期的请求数？是否伴随平均响应时间明显上升？是否出现大量超时或5xx错误？
- 在Nginx侧开启详细日志，用$upstream_addr和$upstream_response_time记录每次转发的目标和耗时
- 用awk + sort + uniq -c统计各后端IP的请求占比，对比是否符合weight比例（例如 weight=5:2:3，应接近 50% : 20% : 30%）
- 同时采集后端应用的接入日志或监控指标（如QPS、RT、线程池活跃数、拒绝数），定位最先出现限流告警的节点
检查健康检查是否掩盖真实压力
max_fails/fail_timeout只屏蔽完全不可达或连续失败的节点，对“能响应但已限流”的慢节点无感知——它仍会持续收请求，形成“假健康、真过载”。
- 如果后端返回的是429（Too Many Requests）或自定义限流码（如599），Nginx默认不将其视为失败，不会剔除该节点
- 可配合proxy_next_upstream error timeout http_429，让Nginx在收到429时主动重试下一台，避免死磕限流节点
- 更彻底的做法是启用主动健康检查（需nginx plus或openresty），定期探测后端真实可用性与响应能力
验证权重设置是否合理
权重不是性能倍数，而是相对调度频次。若一台机器CPU已长期70%，另一台仅30%，却给前者设weight=10、后者weight=1，极易造成前者率先限流。
- 观察各节点的资源使用率（CPU、内存、GC频率、连接数），权重比应尽量贴近其稳定承载能力比
- 避免极端权重比（如100:1），小权重节点可能长期空闲，大权重节点持续承压；建议控制在1:1到5:1之间
- 上线新权重前，先用least_conn或ip_hash做短期对照，确认单节点压力是否可控
排查Nginx与后端之间的连接行为
短连接+高并发下，Nginx频繁建连会加剧后端连接压力；长连接未复用则浪费资源，也可能干扰后端连接池判断。
- 确认是否配置了proxy_http_version 1.1和proxy_set_header Connection ''，以支持HTTP/1.1 keepalive
- 检查后端是否开启连接复用，以及Nginx的proxy_max_temp_file_size和proxy_buffering是否影响流式响应
- 用ss -s或netstat -ant | grep :8080 | wc -l查看后端ESTABLISHED连接数，判断是否因连接未释放导致限流
