Nginx跨机房轮询需三层控制：按机房分组设weight加权（如北京3×10、广州4×4、成都2×1），用max_fails/proxy_next_upstream实现健康规避，通过hash/map/请求方法绑定路由避免抖动。
Nginx轮询本身不支持跨机房智能调度——它只是按配置顺序循环分发请求，完全不感知机房位置、网络延迟或服务能力差异。要实现真正可用的跨机房多节点轮询调度，必须在默认轮询基础上叠加三层关键控制：权重适配物理资源、健康状态自动规避、会话路由避免跨机房抖动。
用weight+zone做机房级加权分流
不能把北京、广州、成都的服务器混在一个upstream里直接轮询。应按机房划分逻辑组，并赋予反映实际承载力的权重：
- 为每个机房单独定义upstream，用zone参数声明共享内存区域（如
zone=beijing 64k），支撑后续健康检查与状态同步 - 北京机房带宽充足、节点性能强，单台server设
weight=10；广州机房出口受限，设weight=4；成都作为灾备节点，设weight=1 - 总流量分配比例由各机房总权重决定，例如北京（3×10=30）、广州（4×4=16）、成都（2×1=2）→ 理论占比约62% : 33% : 4%
靠proxy_next_upstream+max_fails保障基础可用性
跨机房链路更脆弱，需让Nginx主动跳过临时异常节点，而不是等超时后才失败重试：
- 在server行中配置
max_fails=3 fail_timeout=30s，连续3次连接失败或500/502/503响应即标记为不可用 - 在location块中启用
proxy_next_upstream error timeout http_500 http_502，允许在当前节点失败时自动尝试下一节点 - 注意：该机制只在同upstream内生效，所以机房级fallback需靠更高层策略（如DNS切换或全局调度）
用upstream_hash或map模块绑定业务维度
纯轮询会导致用户登录态、缓存、文件上传等依赖本地环境的场景频繁跨机房跳转，引发错误或延迟飙升：
- 对需要亲和性的接口，用
hash $cookie_sessionid consistent;固定同一用户始终落到同一机房的某组节点 - 按地域分流：用
map提取请求头X-Forwarded-For或Cookie中的region字段，动态选择对应机房upstream - 写操作强制路由：识别
POST /api/v1/order类请求，统一代理到主写机房；读请求则可走就近机房，降低RT
不复杂但容易忽略：轮询只是起点，跨机房调度的本质是“用配置表达物理约束”，而不是交给算法自动猜。
