Nginx不支持运行时单个server的weight原地热改，所谓“动态”实为reload后生效；需确认reload成功、weight被正确解析且未被ip_hash等指令覆盖或健康检查剔除。
加权轮询的动态权重修改（如热更新 weight 值）后未生效，通常不是“动态不支持”，而是配置未真正加载、语义被静默忽略或行为被其他机制覆盖。Nginx 本身不支持运行时单个 server 的 weight 原地热改（需 reload），所谓“动态”实际指 reload 后新 weight 生效——排查重点是确认 reload 成功、weight 被正确解析、且未被干扰逻辑绕过。
确认 reload 是否真正完成且无静默失败
执行 nginx -s reload 后，不能只看终端无报错就认为成功：
- 用
ps aux | grep nginx检查 master 进程启动时间是否更新（对比 reload 前），若时间没变，说明 reload 信号未被接收或 worker 未重启 - 检查 error.log 是否有
signal process started或reopening logs日志，缺失则 reload 可能被阻塞（如磁盘满、权限不足） - 执行
nginx -t再次验证——有时 reload 前校验通过，但 reload 过程中因文件被覆盖/剪切导致实际加载的是旧内容或空配置
验证最终生效的 weight 值是否与预期一致
别依赖编辑后的文件，要看 Nginx 实际解析结果：
- 运行
nginx -T 2>/dev/null | sed -n '/upstream.*backend/,/}/p'（把 backend 替换为你的 upstream 名），直接提取生效的 upstream 块，确认每行 server 后的 weight= 数值是否是你改过的 - 特别注意：weight 必须写在 server 行末尾，且不能有空格分隔（如
server 1.1.1.1:80 weight = 3;是非法的，会被忽略） - 搜索拼写错误：
nginx -T 2>/dev/null | grep -i -A1 -B1 "weigth\|wight\|weights"，避免 weight 写成 weigth 导致整行被静默丢弃
排除干扰机制对权重行为的覆盖
即使 weight 正确加载，也可能不体现为流量比例，因为其他指令优先级更高：
- 检查 upstream 块是否混用了
ip_hash、hash $cookie_session或least_conn——只要存在任一非轮询类指令，weight 就完全失效 - 确认所有 server 都未被标记为
down或处于fail_timeout状态：用curl http://127.0.0.1:8080/nginx_status（需启用 stub_status）查看 active 连接数，若某节点 active=0 且 state=unavail，说明健康检查已将其剔除 - 检查是否有
backup或max_fails=0等非常规设置，它们会改变参与轮询的节点集合，使权重计算基准偏移
观测真实请求分发是否匹配权重比例
日志统计要避开重试干扰：
- 在 location 中添加唯一标识头：
add_header X-Upstream-Choice "$upstream_addr";，再用短连接压测（如wrk -c1 -d5s -t1 http://your-domain/），避免 keepalive 复用掩盖轮询效果 - 解析 access log：
awk '{print $NF}' /var/log/nginx/access.log | sort | uniq -c | sort -nr，其中 $NF 是 $upstream_addr 字段（需 log_format 包含它），观察 IP:port 出现频次比是否趋近 weight 比（如 weight=4 和 weight=1 应接近 4:1） - 若比例严重偏离，且无 error.log 报错，大概率是 weight 未生效，或某节点因响应超时被临时跳过（可临时关闭健康检查复测）
