nginx 的 ip_hash 不能实现跨机房流量调度，仅用于单机房内会话保持；正确做法是 gslb 做机房级路由，机房内用 ip_hash 保持会话，并配合兜底机制与更稳定标识哈希或应用层路由。
Nginx 的 ip_hash 不能真正实现跨机房流量调度，它只在单个 Nginx 实例（或同一集群内共享 session 状态的节点）内部做客户端 IP 的哈希绑定，目标是保证同一 IP 的请求始终落到同一台后端服务器——这是为会话保持设计的，不是为跨地域、跨机房的智能路由服务的。
把 ip_hash 用在跨机房场景，不仅达不到“调度”效果，反而容易引发问题：
- 它不感知机房地理位置，对北京用户和旧金山用户的 IP 做同样哈希，可能把两地请求都打到同一个远端机房；
- 多机房部署时，若每个机房都独立配
ip_hash，相同 IP 在不同机房会哈希出不同后端，导致会话不一致； - 公网 NAT、CDN、移动网络出口 IP 高度复用，
ip_hash绑定粒度粗、不准，易造成负载倾斜甚至单点过载。
真正需要的是分层协作：
-
上层做机房级路由：用 GSLB（如智能 DNS 或 Anycast）根据用户地理位置、延迟、健康状态，把请求先分发到最近的机房入口（例如
cn-north.yourapp.com→ 华北 Nginx 集群）； -
本机房内用
ip_hash做会话保持：在华北 Nginx 集群里，对进入该机房的流量启用ip_hash，确保用户后续请求落在同一台本地后端，提升缓存命中与状态一致性； -
配合 backup 或 proxy_next_upstream 做兜底：当本机房某台后端故障时，
ip_hash默认不自动漂移；需结合max_fails/fail_timeout和proxy_next_upstream error timeout，让失败请求尝试同机房其他节点，而非直接跨机房转发。
如果业务强依赖按 IP 路由且必须跨机房，可行替代方案包括：
- 提取并透传更稳定的标识，如
X-User-ID或登录态 Cookie，用hash $cookie_sessionid或hash $http_x_user_id替代ip_hash，再配合map指令将哈希结果映射到对应机房 upstream； - 在应用层或 API 网关层做路由决策，Nginx 仅作透明代理，避免在反向代理层强行承担跨域调度职责。
Nginx 的定位很明确：它是区域入口，不是全局调度器。跨机房流量调度靠的是架构设计，不是某个指令开关。
