nginx加权轮询无隐式继承机制，所谓“冲突”实为配置覆盖、加载顺序错误或weight未显式声明所致；排查应聚焦upstream定义是否生效、名称是否匹配、语法是否规范及健康检查干扰。
加权轮询配置中所谓“隐式继承冲突”，其实并不存在真正的继承机制——Nginx 本身不支持权重或 upstream 指令在 location 或 server 块之间自动传递或叠加。所谓“冲突”，多是因配置结构误读、文件加载顺序混乱、或权重未显式声明导致的预期外行为。排查重点不在“继承”，而在“谁最终生效”。
确认 upstream 定义是否被覆盖或重复
多个 conf 文件中若都定义了同名 upstream（如 upstream backend），Nginx 会按字典序加载，后加载者完全覆盖前者，不会合并。看似“权重没起作用”，实则是你改的配置根本没生效。
- 运行 nginx -T 查看最终合并后的完整配置，搜索 upstream backend {，确认看到的是你期望的 server 行和 weight 值
- 检查 /etc/nginx/conf.d/ 下所有 .conf 文件名，避免出现类似 app.conf 和 z-proxy.conf 这类导致后者覆盖前者的命名
- 同一域名+端口组合下，不要在不同 server 块里重复定义相同 upstream 名；如需复用，统一抽到 http 块顶层，用 include 引入公共段
验证权重是否被隐式重置为 1
Nginx 对未写 weight 的 server 默认设为 1，但若 upstream 块里混用了带 weight 和不带 weight 的节点，容易误判“权重没生效”。更隐蔽的是：某些模板生成脚本或 Ansible 任务可能漏写 weight，或把 weight=3 错写成 weight 3（少等号），导致该行被忽略，降级为 weight=1。
- 逐行检查 upstream 内每台 server，确保格式统一：server 192.168.1.10:8080 weight=3;（分号不能少）
- 避免混用写法，例如不要在同一 upstream 中出现 server a weight=2; 和 server b;，应显式写 server b weight=1;
- 用 curl -s http://localhost/health 类接口（或自建简单响应头带节点标识的服务）发起 20+ 次请求，统计各节点命中次数，再对照总权重比（如 3:2:1 → 理论占比 50% : 33% : 17%）判断是否符合
排除 proxy_pass 转发路径干扰
加权轮询只作用于 upstream 组内节点调度，但如果请求没进对的 upstream，权重再准也白搭。常见干扰来自 location 匹配错位、proxy_pass 指向错误名称、或被 rewrite / return 提前截断。
- 确认 location 块中 proxy_pass http://backend; 的 backend 名称与 upstream 块名称**完全一致**（大小写、下划线、拼写）
- 检查是否有更高优先级的正则 location（如 location ~ ^/api/v\d+/）意外捕获了请求，却指向了另一个 upstream
- 禁用所有 rewrite、return、error_page 干预逻辑，先用最简配置验证权重分配，再逐步加功能
注意健康检查对权重表现的干扰
即使配置了 weight，若某节点连续失败触发 max_fails，它会被临时剔除出轮询队列——此时剩余节点会按比例“重新分摊”流量，看起来像权重失衡。
- 检查 upstream 中是否启用了 max_fails=3 fail_timeout=30s 等参数；如有，用 nginx -s reload 后立刻查 error.log，看是否有 no live upstreams 或 unhealthy 日志
- 临时注释掉健康检查参数，仅保留 weight，做纯净测试
- 用 curl -I http://192.168.1.10:8080 手动探测各后端连通性与响应码，确认无节点处于“假死”状态
