加权轮询需显式配置weight参数于upstream块内，排除ip_hash等覆盖策略；验证须统计≥500次请求的实际占比是否接近权重比例（如3:2:5对应30%/20%/50%），并确认容器环境使用dns名而非硬编码ip以支持动态扩缩容。
加权轮询在云原生环境下不是“配置完就生效”的黑盒，而是需要验证流量分配是否符合权重预期、能否响应实例动态变化、是否与容器生命周期协同。排查重点不在语法对错，而在行为是否可观察、可验证、可收敛。
确认权重是否真正参与调度决策
NGINX 默认启用的是轮询（round robin），加权轮询需显式声明 weight 参数且后端必须使用 upstream 块定义。常见疏漏是：只在 server 指令里写 weight，但没放在 upstream 内；或用了 upstream 却漏掉 least_conn 等其他指令导致权重被忽略。
- 检查 nginx.conf 中 upstream 块是否形如：
upstream backend {<br> server 10.0.1.10:8080 weight=3;<br> server 10.0.1.11:8080 weight=2;<br> server 10.0.1.12:8080 weight=5;<br>} - 确保未启用
ip_hash或least_conn—— 这两类策略会覆盖 weight 行为 - 用
nginx -t验证语法，再用nginx -T输出完整生效配置，确认 weight 值被正确加载
验证实际流量分布是否匹配权重比例
权重本质是概率分配，不是严格按次数切分。短期请求可能偏差大，需统计足够样本（建议 ≥500 次请求）并计算各后端的响应占比。
- 在容器中启用 access_log 并记录 $upstream_addr 字段：
log_format upstream_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr"'; - 用
docker exec -it nginx-container tail -n 1000 /var/log/nginx/access.log | awk '{print $13}' | sort | uniq -c | sort -nr快速统计上游地址命中次数 - 若权重为 3:2:5，总权重 10，则期望占比应接近 30% / 20% / 50%，误差超过 ±8% 需进一步排查
检查容器化部署对权重行为的隐性干扰
云原生环境中的网络、健康检查、服务发现机制可能绕过或弱化 weight 控制逻辑。
- 确认后端服务注册地址是真实 Pod IP 或 Service ClusterIP，而非 localhost —— 容器内 localhost 指向自身，会导致所有流量打到同一实例
- 若使用 Kubernetes Ingress-Nginx，注意它默认开启
service-upstream: "true"，会将 upstream 直接指向 Endpoints，此时 weight 需在 Service 的spec.externalTrafficPolicy或 EndpointSlice 中配置，而非 NGINX 配置文件 - Docker Compose 网络中，避免用 host 网络模式：host 模式下容器共享宿主机网络命名空间，DNS 解析和连接行为可能跳过 NGINX 的 upstream 调度逻辑
观察权重是否随实例扩缩容动态适应
真正的云原生适配要求权重策略能容忍后端实例增减，而不是每次扩容都要手动改配置、重启容器。
- 在 docker-compose.yml 中挂载配置时，不要把 upstream 写死 IP，改用 DNS 名称（如
backend-svc:8080），配合 Docker 内置 DNS 实现自动解析 - 若用 Consul 或 Nacos 做服务发现，需集成
nginx-upstream-check-module或使用 OpenResty + Lua 动态更新 upstream，否则 weight 只在 reload 时生效 - 测试方法：启动 2 个后端容器 → 发 200 次请求 → 记录分布 → 再启动第 3 个 → 不 reload NGINX → 继续发 200 次 → 观察新实例是否逐步承接流量（即使 weight=1，也应有非零占比）
