加权轮询是轮询的增强形式，非独立算法；nginx在upstream中配置weight即自动启用，未设weight者默认为1，所有节点统一纳入加权调度，不支持部分加权与部分纯轮询混用。

加权轮询本身不是“加权”和“轮询”的混合或冲突模式，而是轮询的一种增强形式——它在轮询顺序基础上引入权重因子，不存在配置冲突。所谓“冲突”，通常是因误解默认行为、遗漏关键语法，或混用不兼容参数导致的异常表现。

加权轮询的本质是带权重的轮询调度

轮询（Round Robin）是 Nginx 的默认策略；加权轮询（Weighted Round Robin）是其自然扩展，并非独立算法。只要你在 upstream 块中为任意一台 server 显式指定 weight=，Nginx 就自动启用加权逻辑，其余未设 weight 的服务器默认 weight=1。

• 权重决定每轮中该节点被选中的次数比例，不是绝对优先级
• 例如：server a:80 weight=3; server b:80 weight=1; → 每4个请求中，a处理3个、b处理1个，按固定循环序列（a,a,a,b）轮进
• 不支持“部分加权 + 部分纯轮询”这种割裂配置；所有节点统一纳入加权轮询框架

常见误配及修正方式

所谓“冲突”，多出现在以下几种实际配置错误中：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 混用 ip_hash 或 least_conn 等其他算法指令：一个 upstream 块内只能启用一种主调度算法。若同时存在 ip_hash; 和 weight=，Nginx 启动会报错或忽略 weight
• 权重值为 0 或负数：weight 必须是正整数（如 1、2、5），设为 0 相当于临时下线该节点，但不会触发“冲突”，只是剔除
• 误加 round_robin 关键字：Nginx 不需要也不识别 round_robin 指令；加了反而报错。加权轮询无需开启任何开关，写 weight 即生效
• 与健康检查参数逻辑混淆：如 max_fails 和 fail_timeout 是容错机制，和权重正交共存，不冲突。但若某节点因故障被临时摘除，其权重在剩余节点中重新归一化计算

验证加权是否真正生效

不能只看配置写了 weight，要通过实际流量分布确认：

• 用 curl 连续发起 20+ 次请求，记录每次响应头中的自定义标识（如后端返回 X-Server-ID: node-a）
• 统计各节点出现频次，应接近权重占比（如 weight=3 和 weight=1 → 比例约 75% : 25%）
• 注意：单次请求或低并发下可能因缓存、TCP复用等产生偏差，建议用 ab -c 10 -n 100 或 wrk 测试

合理设置权重的实用建议

权重不是拍脑袋定的数字，需结合真实负载能力：

• 以 CPU 核心数为基准参考：4核服务器 weight=4，2核设为2，1核设为1
• 若某节点内存更大、磁盘更快，可适度上浮权重（如 4核+SSD 可设为5）
• 避免权重差距过大（如 100 vs 1），易造成小权重节点长期空闲或大权重节点过载；建议最大比值控制在 5:1 内
• 上线前做压测，根据平均响应时间反推调整：若某节点 RT 是其他节点的 2 倍，权重可减半