要实现稳定分发，需用真实客户端ip、cookie或请求头替代默认$remote_addr做hash键，并通过map按业务维度分组调度，配合容错降级与监控。
IP Hash 本身只认 $remote_addr，但真实场景中客户端出口 IP 常被代理遮盖、NAT 合并或动态变化，直接用默认 ip_hash 容易失效。要真正靠“客户端标识”实现稳定分发，得跳出单纯依赖 IP 的思路，转而识别更可靠、可携带的标识，并让 hash 算法作用于它。
用真实客户端 IP 替代 remote_addr
政企客户走专线或统一出口网关时，$remote_addr 往往是最后一层代理（如 WAF 或 CDN 边缘节点）的地址，不是客户真实出口。必须还原真实 IP 才能保证 hash 结果一致：
- 确认前端透传机制：要求客户或中间设备在
X-Forwarded-For中带上原始出口 IP，且首项为真实值 - 配置
set_real_ip_from指定可信代理网段，再启用real_ip_header X-Forwarded-For和real_ip_recursive on - 验证日志：对比
$remote_addr和$http_x_forwarded_for，确保$realip_remote_addr（或自定义变量）稳定输出客户真实出口 IP
用 Cookie 或请求头做 hash 键
当客户能配合埋点（如登录态 Cookie 或定制 Header），就比 IP 更精准、更可控：
- 若客户系统支持写入唯一标识 Cookie（如
client_id=beijing-gov-001），可用hash $cookie_client_id替代ip_hash - 若调用方可在请求头中带
X-Client-Tag: gov-beijing，则配置hash $http_x_client_tag - 注意：这类标识需全局唯一且不变，否则 hash 会漂移；不建议用
$cookie_sessionid这类短期变动值
按业务维度做 map 分组 + 独立 upstream
单一 hash 无法区分客户等级或 SLA 要求。应把“标识识别”和“分组调度”解耦：
- 用
map指令将真实 IP 段、Cookie 值或 Header 内容映射到不同 upstream 名称（如beijing_gov_backend、shenzhen_finance_backend） - 每个 upstream 单独启用
ip_hash或hash $cookie_client_id，内部只挂该客户的专属后端节点 - 避免混用：普通用户流量走通用 upstream，政企客户走隔离组，防止哈希空间干扰
容错与降级设计
标识丢失或异常时，不能直接 502，要有兜底策略：
- map 中设
default分支指向通用 upstream，保证基本可用 - 对
hash类指令，加hash_method consistent可减少节点增减时的键重分布 - 监控
upstream_addr日志，发现某客户流量突然分散到多个后端，说明标识还原失败，需及时排查代理链路
