权重过大不会直接导致nginx调度异常，但会扭曲加权轮询行为，造成请求分配严重倾斜；官方无硬性上限（0–65535），但建议最大权重≤100且同量级，需结合stub_status或access_log验证实际分发比例是否符合预期。
权重数值过大本身不会直接导致 Nginx 调度异常，但会显著扭曲加权轮询（weight）的预期行为，表现为某些上游服务器被过度倾斜分配请求，而其他服务器长期空闲——这常被误认为“调度失效”或“节点失联”。排查重点不是“数值是否超限”，而是验证权重是否合理、是否与其他配置冲突、以及实际流量是否符合加权比例。
确认 weight 值是否超出合理范围
Nginx 官方未设 weight 硬性上限（理论上支持 0–65535），但过大权重（如 10000+）易引发整数运算精度偏差和统计失真。尤其当后端节点数量少、权重差异悬殊（如 weight=1 vs weight=5000）时，低权重节点可能连续数十轮都分不到请求。
- 建议将最大权重控制在 100 以内，各节点权重尽量保持同量级（例如 5 / 10 / 20，而非 1 / 100 / 5000）
- 用相对值代替绝对值：若某节点性能是其他节点的 5 倍，设为
weight=5即可，无需放大成 500 - 检查配置中是否存在重复或覆盖（如多个
upstream块同名，或 include 文件中权重被多次定义）
观察实际调度分布是否符合权重比例
仅看配置无法判断效果，必须结合实时请求分发数据验证。
- 启用
stub_status模块（需编译时含--with-http_stub_status_module），通过/nginx_status查看各 upstream server 的Active连接数和累计请求计数（需自行扩展日志或用第三方模块如nginx-module-vts） - 在 access_log 中记录 upstream 地址：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" $upstream_response_time';，再用 awk / grep 统计各 IP 出现频次 - 对比理论权重比与实际请求数比（例如权重 3:5:2 → 理论占比 30% / 50% / 20%），偏差超过 ±10% 就值得深挖
排除其他干扰因素对加权轮询的影响
权重只是加权轮询的一个输入，以下配置会覆盖或削弱其作用：
-
ip_hash或hash $request_uri等哈希策略启用时，weight完全无效 -
max_fails和fail_timeout导致节点被临时标记为 down，即使权重高也收不到新请求 -
slow_start使新上线节点权重从 0 逐步恢复，初期调度明显偏低 - 使用了
least_conn或random等非轮询算法，weight不生效
用最小化测试验证权重行为
绕过业务逻辑，快速验证 Nginx 自身调度逻辑是否正常：
- 搭建两个简单后端（如两个 netcat 监听端口或轻量 HTTP echo 服务），分别返回固定标识（如
server-a/server-b） - 配置 upstream 仅含这两个节点，设置差异明显但合理的权重（如 1 和 3）
- 用
ab或wrk发起 1000+ 请求：curl -s http://your-nginx/ | head -1循环调用，统计响应来源分布 - 若结果严重偏离 25% / 75%，说明配置或环境有隐性问题；若基本吻合，则原生产环境的问题大概率出在动态状态（如健康检查、连接复用、客户端重试等）
不复杂但容易忽略：权重影响的是“轮询序列的构造频率”，不是每秒请求数的硬性分配。Nginx 按内部累积权重生成一个虚拟队列（如权重 1:3 → 队列为 [a,b,b,b]），每次取一个并循环。因此小流量下可能连续几次都打到高权重点，属正常现象；评估必须基于足够样本量。
