Nginx 不支持跨机房链路优选，需分层协作实现：用 geo/map 识别用户地域并动态路由至本机房 upstream，各机房内部用加权轮询+健康检查，异地节点仅作 backup 灾备。
Nginx 本身不支持跨机房链路优选——它没有网络延迟感知、地域识别或跨中心健康状态同步能力。所谓“轮询跨机房”，不是配置问题，而是架构误用。真正可行的链路优选，必须靠分层协作，Nginx 只承担其中一层：本地精细分发。
轮询只是本地分配策略，不能替代跨机房调度
在 upstream 中直接写两个机房的 IP（比如 server 10.1.1.10 和 server 192.168.5.20），再配 weight 或默认轮询，看似“跨机房”，实则风险极高：
- 广州用户请求被轮到北京节点，首包 RT 可能从 15ms 暴涨到 60ms+，HTTP 超时频发
- Nginx 不主动探测异地节点延迟，仅靠连接失败才剔除，响应慢但未断连的节点会持续吸流
- 一旦某地链路抖动，
proxy_next_upstream可能反复重试，放大故障影响
链路优选必须靠前置地理识别 + 动态 upstream 切换
让 Nginx “感知”链路优劣，关键不是改轮询参数，而是让它根据用户来源，只把请求发给本机房或更优机房的 upstream：
- 用
geo指令或map $http_x_real_region识别用户属地（推荐配合 CDN 透传真实区域头） - 用
map将地域映射为 upstream 名称，例如：map $region $backend_pool {<br> default backend_gz;<br> cn_beijing backend_bj;<br> cn_shanghai backend_sh;<br>} - 在
location块中引用：proxy_pass http://$backend_pool;
每个机房 upstream 内部才用轮询/加权轮询
各机房的 upstream 独立定义，专注本中心资源调度：
- 北京 upstream 配加权轮询：
server 10.2.1.10 weight=3 max_fails=2 fail_timeout=20s; - 广州 upstream 同样配置，但权重按实测 QPS 设定（如单节点吞吐比北京低 30%，weight 就设为 2）
- 所有节点开启主动健康检查（需 nginx-plus 或 lua_healthcheck），路径用
/health?site=bj避免业务接口干扰
异地机房只作灾备，不参与日常轮询
若需保留跨机房兜底能力，严格限制异地节点的启用条件：
- 异地节点显式标记为
backup，例如：server 192.168.5.20 backup; - 或单独定义
upstream backend_fallback，并在 server 块中启用：proxy_next_upstream error timeout http_500; - 禁用
ip_hash，改用hash $remote_addr consistent;防止 fallback 切换后会话漂移
