加权轮询权重未生效，首要确认配置是否真正加载：检查语法和路径正确性、upstream块作用域及模块启用状态，验证reload是否真实触发进程更新，并排除健康检查、其他负载策略及缓存干扰。
加权轮询权重改了但 reload 后没生效，不是配置写错了就是加载没到位。重点不在“怎么写”，而在“有没有真正换上新配置”。
先确认配置语法和路径是否正确
加权轮询依赖 upstream 块里的 weight= 参数，但这个参数只在 upstream 模块启用时有效。如果 nginx 编译时没带该模块，或配置写在了错误作用域（比如放在 location 里而非 http 或 upstream 块内），权重会直接被忽略。
- 运行
nginx -t，检查输出是否为 syntax is ok 和 test is successful - 确认你修改的是 nginx 实际加载的配置文件——用
nginx -V 2>&1 | grep "conf-path"查默认路径，或看启动命令中-c指定的文件 - 检查 upstream 块是否被
include正确引入，常见遗漏是改了 conf.d 下的文件，但主配置里没 include 它
验证 reload 是否真成功执行
reload 不报错 ≠ 配置已更新。Nginx 的 reload 是向 master 进程发 HUP 信号，由它拉起新 worker 并通知旧 worker 优雅退出。若 master 进程异常、PID 文件损坏或权限不足，reload 表面成功，实则未触发更新。
- 执行
nginx -s reload后，立刻运行ps -eo pid,cmd | grep nginx（Linux）或tasklist /fi "imagename eq nginx.exe"（Windows），观察是否有新 worker 进程出现 - 查看
nginx.pid文件内容是否为当前 master 进程的真实 PID；若为空或非法数字，说明进程管理已紊乱 - 检查 error.log，搜索
reloading或HUP关键字，确认 reload 日志是否完整记录
排除长连接与缓存干扰
加权轮询效果需要多次请求才能体现统计趋势，单次访问看不出变化。更麻烦的是：旧连接仍走老 worker，而老 worker 可能持续服务几十秒甚至几分钟，导致“明明 reload 了，流量却还在老节点上”。
- 用
netstat -anp | grep :80 | grep ESTABLISHED | grep nginx查看活跃连接归属的 worker PID，对比 reload 前后是否切换 - 临时把
keepalive_timeout调小（如设为 5s），加速连接释放，让新配置更快显现 - 浏览器或 CDN 缓存可能复用旧响应头（如
Set-Cookie或Location），建议用curl -v直连后端，绕过所有中间缓存验证真实分发结果
检查 upstream 实际生效状态
权重只是调度策略的一部分。如果后端服务器健康检查失败（max_fails/fail_timeout 触发）、被手动 down 掉（down 指令），或设置了 ip_hash 等其他负载策略，权重将完全不参与决策。
- 在配置中确认没有和其他负载算法共存，例如同一个 upstream 块里同时写了
ip_hash和weight，后者会被忽略 - 访问
/status（需启用 stub_status）或使用第三方模块（如 nginx-module-vts）查看各 server 的实时请求计数，比对是否符合权重比例 - 用
nginx -T（大写 T）输出全部生效配置，搜索你的 upstream 名称，确认最终合并后的块里 weight 值是你改过的数值
