轮询是nginx upstream默认策略，无需显式声明；权重必须用weight参数且仅在server行生效，值为整数并影响同健康服务器间的请求比例分配。
轮询是默认策略，不用写任何关键字；权重必须显式用 weight 参数，且只在 server 行生效，不能放在 upstream 块顶层。
轮询策略为什么“不写就是启用”
Nginx 的 upstream 模块只要没声明其他算法（如 ip_hash、least_conn），就自动走轮询。它不依赖任何配置项，也不需要加 round_robin 这类关键词。
常见错误是误以为要手动开启——比如写成 upstream backend { round_robin; server a; server b; }，这会导致 Nginx 启动失败，报错 unknown directive "round_robin"。
- 轮询按配置中
server出现的顺序循环分发，第一个请求到第一台，第二个到第二台，依此类推 - 某台服务器响应超时或返回 500/502/503/504，默认会标记为不可用 10 秒（由
fail_timeout=10s控制），期间跳过它 - 如果所有后端都失败，Nginx 会把请求转给最近一次“成功响应过”的服务器（哪怕它刚被标记为 down），这是 fallback 行为，不是 bug
weight 参数怎么设才有效
weight 必须紧跟在 server 地址之后，中间不能换行，也不能加空格以外的分隔符。它的值是整数，最小为 1，没有上限，但建议控制在 1–100 范围内便于估算比例。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
例如 server 192.168.1.10:8080 weight=3; 是合法的；而 server 192.168.1.10:8080; weight=3; 或 server 192.168.1.10:8080 weight = 3; 都会报错 invalid number of arguments in "server" directive。
- 权重不是绝对值，而是相对比值：两台服务器
weight=2和weight=1，实际请求分配比约为 2:1 - 权重不影响健康检查逻辑，
max_fails和fail_timeout仍需单独配置，否则宕机后不会自动剔除 - 权重与
ip_hash可共存（Nginx ≥ 1.3.1），但和backup冲突：带backup的 server 不能设weight
轮询 vs 权重轮询的实际影响
纯轮询适合后端能力一致、无状态服务；一旦机器性能差异大（比如一台 32C64G，另一台 4C8G），不加权重会导致小机器很快被打满，连接堆积、超时增多。
但权重不是万能解药：它只改变请求“数量分布”，不感知实时负载。比如某台高权重大机器 CPU 已 95%，Nginx 依然按比例继续派发新请求，直到触发 max_fails 才停。
- 若想按真实负载调度，得换
least_conn策略，它看的是当前活跃连接数，不是预设比例 - 权重值调太高（如 100）容易让流量过度集中，单点故障影响面变大；建议从 2–5 开始试，结合监控观察 RT 和错误率再调
- 修改权重后必须
nginx -s reload，不能只改配置文件就完事——旧 worker 进程仍按旧权重跑，直到处理完手头请求
真正容易被忽略的是：权重只在同一批次的健康服务器间起作用。一旦某台因失败被临时摘除，剩余服务器会按它们之间的权重重新归一化计算比例，而不是维持原始数值比。这意味着故障恢复期的流量倾斜可能比预期更剧烈。
