Nginx不支持混合云跨机房算力精准配比，仅负责本地机房内按weight精细分流；跨机房调度须由GSLB/智能DNS前置决策，各机房Nginx专注本中心负载均衡与健康检查。
Nginx 本身不支持混合云跨机房的算力精准配比——它不是跨地域调度系统，而是本地流量分发器。所谓“在 Nginx 里配 weight 实现混合云跨机房”，属于常见误解。真正可行的做法，是让 Nginx 专注本机房内按权重精细分配，而跨机房决策交给上层全局系统。
加权轮询只管本中心，不管跨中心
Nginx 的 weight 参数作用范围仅限于同一个 upstream 块内的服务器，且所有 server 必须能被当前 Nginx 实例直连（或通过可控网络可达）。它：
- 不感知异地节点的延迟、丢包、带宽瓶颈
- 不自动规避跨公网链路抖动引发的超时重试风暴
- 无法区分“广州云主机”和“北京IDC物理机”的网络域差异
如果你强行在一个 upstream 里写：
upstream hybrid {
server 10.0.1.10:8080 weight=5; # 广州VPC内网
server 192.168.5.20:8080 weight=3; # 北京IDC内网（经公网打通）
}
结果往往是：北京节点一丢包，Nginx 就反复重试，触发 proxy_next_upstream，加剧雪崩，反而破坏“精准配比”。
混合云场景下，加权轮询的正确用法
把“跨机房”和“加权轮询”拆成两层职责：
-
GSLB / 智能DNS 层：根据用户地理位置、运营商、健康状态，将请求解析到最近/最稳的入口域名（如
shard-gz.example.com或shard-bj.example.com） -
各机房 Nginx 入口层：每个入口只配置本机房后端，用
weight按真实算力比例分配upstream backend_gz { server 10.0.1.10:8080 weight=4; # 32核云主机 server 10.0.1.11:8080 weight=2; # 16核云主机 server 10.0.1.12:8080 weight=1; # 8核备用机（backup） # 配 max_fails、slow_start 确保高可用 }
如何实现“算力精准配比”
精准 ≠ 直接填数字，而是基于可观测数据动态对齐：
- 初始权重参考硬件指标：CPU核心数比、实测稳定QPS比（例如压测得 A=1200 QPS、B=600 QPS → weight=2:1）
- 上线后持续采集各节点 CPU 使用率、平均响应时间、5xx 错误率
- 若某节点长期 CPU > 80% 但权重偏高，说明预估偏乐观，可
nginx -s reload动态调低 weight - 若某云厂商突发限频或弹性缩容，需同步调整对应 weight，避免过载
注意：weight 必须是正整数，不支持小数、变量或表达式；未设 weight 默认为 1，整个 upstream 自动进入加权轮询模式——不存在“混合轮询与加权轮询”。
特殊兜底需求：单 Nginx 接两地后端（慎用）
仅限灾备切换或灰度验证，必须满足：
- 用
geo+map按客户端 IP 主动选 upstream，而非让轮询随机打穿 - 异地节点显式声明为
backup，不参与日常调度 - 各地 upstream 独立启用
health_check（如interval=5 fails=2 passes=2） - 关闭
ip_hash，改用hash $remote_addr consistent防止会话漂移
不复杂但容易忽略
