nginx平滑加权轮询（swrr）生效需满足：显式配置max_fails和fail_timeout，禁用down标记，避免reload；否则effectiveweight不变化，调度不平滑。
直接测试加权轮询在动态调整权重时的平滑过渡表现，关键不是改完 weight 就 reload，而是观察 Nginx 内部 effectiveWeight 和 currentWeight 的实际调度行为。Nginx 1.10.1+ 默认已启用平滑加权轮询（SWRR）算法，但“平滑”是否生效，取决于你是否触发了它的运行机制。
验证前先确保基础配置合规
不满足以下条件，测出来的根本不是平滑行为：
- 每个
server行必须显式配置max_fails和fail_timeout（例如max_fails=2 fail_timeout=5s），否则effectiveWeight不会衰减/回升，权重就是静态硬切 - 不能使用
down标记临时下线节点——这会让该节点完全退出调度池，effectiveWeight停滞，失去渐进恢复逻辑 - 避免频繁
nginx -s reload，每次 reload 都会重置所有节点的currentWeight和effectiveWeight到初始值，等于打断整个平滑过程
用 curl + 日志快速验证调度序列
准备三台后端服务（如返回各自 host 或编号），配置如下：
upstream backend {server 192.168.1.10:8080 weight=5 max_fails=2 fail_timeout=5s;
server 192.168.1.11:8080 weight=1 max_fails=2 fail_timeout=5s;
server 192.168.1.12:8080 weight=1 max_fails=2 fail_timeout=5s;
}
然后执行 7 次请求并记录后端响应：
理想平滑序列应接近 a, a, b, a, c, a, a（a 占 5 次，b/c 各 1 次，且不连续堆积）。若看到 a,a,a,a,a,b,c，说明 effectiveWeight 未参与调度——大概率是健康检查没生效或节点被误标为 down。
模拟节点故障与恢复，观察权重回升节奏
这是测“动态平滑”的核心场景：
- 手动停掉 192.168.1.11（b 节点），发若干请求，确认它从调度中消失（日志无访问）
- 等待超过
fail_timeout（如 5s），再重启 b 节点的服务 - 立刻开始连续发请求（每秒 1–2 次），观察 b 是否被选中：最初几次大概率不会被选中；第 3–5 次成功响应后，
effectiveWeight开始从 0 缓慢回升（每次成功 +1），b 出现频率逐步上升 - 对比：如果 b 一恢复就立刻承接和 a 相当的流量，说明
effectiveWeight没起作用——检查是否漏配max_fails，或是否用了down
进阶：用 stub_status 或第三方模块观测内部状态
Nginx 开源版不暴露 currentWeight 和 effectiveWeight 的实时值，但可通过间接方式判断：
- 开启
stub_status，配合持续压测，统计各节点在固定请求数（如 1000 次）内的实际分配比例，看是否随时间从偏离态回归到权重比（如 5:1:1） - 若需精确观测，可编译安装
nginx_upstream_check_module，配合自定义探针和日志，把每次调度选择、effectiveWeight变化写入 access_log，再用脚本解析 - OpenResty 用户可直接在
balancer_by_lua_block中读取并打印peer.effective_weight和peer.current_weight，实现透明可观测
