Nginx 不具备跨机房流量调度能力，仅负责本地机房内精细分流；跨机房调度需 GSLB（如智能 DNS）前置决策，各机房 Nginx 专注本中心负载均衡与健康检查。
Nginx 本身不直接实现跨机房的流量调度——它只负责单机房（或单区域）内的请求分发，不具备跨地域网络状态感知能力。所谓“Nginx 轮询跨机房”，本质是误用概念；真正可行的做法，是让 Nginx 在**本地机房内做好精细分流**，再把跨机房决策交给上层系统协同完成。
明确 Nginx 的边界：只管本中心，不管跨中心
Nginx 是七层反向代理，擅长基于 HTTP 协议做路由、限流、健康检查和会话保持。但它：
- 无法实时感知广州节点到北京用户的 RT 或丢包率
- 不维护其他机房节点的存活状态（除非你主动配置健康检查）
- 默认轮询完全无视物理距离、带宽差异和故障传播风险
强行在一个 upstream 里混写两地 IP（如 server 10.0.1.10 weight=5 和 server 192.168.5.20 weight=3），看似“跨机房轮询”，实则极易因广州链路抖动导致大量请求超时，触发 proxy_next_upstream 频繁重试，反而加剧雪崩。
正确做法：三层协同架构
跨机房流量调度必须靠分层设计：
-
GSLB 层（全局调度）：如 PowerDNS + GeoIP 或云厂商智能 DNS，按用户地理位置解析到最近的入口域名（
bj.example.com→ 北京 Nginx 集群，gz.example.com→ 广州 Nginx 集群） - 区域入口层（Nginx 集群）：每个机房部署独立 Nginx 集群，只代理本机房后端服务，做加权轮询、一致性哈希或 least_conn
-
本地负载层（upstream 内部）：在
upstream backend_bj中配置北京各节点，设合理 weight 和 health_check；同理建upstream backend_gz
这样，Nginx 不再“跨机房轮询”，而是专注把进来的请求，在本地资源池里分得又快又稳。
如果必须在单 Nginx 实例中接入多地后端
仅限小规模验证或灾备兜底场景，需严格控制风险：
- 用
geo+map按用户 IP 归属地选择 upstream：cn_beijing → backend_bj，cn_guangdong → backend_gz - 两地 upstream 各自配置
health_check interval=5 fails=2 passes=2，避免被动等待连接超时 - 异地节点显式标记为
backup，仅当本地全部失败时才启用，不参与日常轮询 - 禁用
ip_hash或$request_uri哈希，改用hash $remote_addr consistent防漂移
关键提醒：别拿轮询当调度策略
跨机房的核心矛盾从来不是“怎么分”，而是“分给谁更可靠”。轮询只是最基础的分配方式，它解决不了延迟、带宽、故障域隔离等问题。真正的调度能力来自：
- 前置 DNS/GSLB 的地理识别与缓存控制
- 各机房 Nginx 对自身后端的健康探测与权重反馈
- 业务层对多活数据一致性的保障（如最终一致性同步机制）
Nginx 是执行者，不是决策者。把它用对位置，比调参更重要。
