要让政企B端客户流量稳定黏滞到指定后端服务器，需结合map模块精准路由与专用ip_hash upstream：先通过map按客户IP段映射至专属upstream名称，再在该upstream中仅配置目标服务器并启用ip_hash，同时配置real_ip_from还原真实IP，避免NAT干扰和哈希偏移。
要让特定政企B端客户的流量稳定黏滞到指定后端服务器，ip_hash本身不支持“按客户筛选”，它默认对所有客户端IP一视同仁做哈希绑定。但结合政企客户网络特征（如固定出口IP段、无NAT、直连或可控代理），可通过精准配置实现定向黏滞——关键不在“改ip_hash”，而在“控输入”和“调分组”。
明确客户IP范围，单独划分upstream
政企客户通常有固定公网出口IP段（例如：203.107.128.0/20、112.64.192.0/18）。不要把它们混在通用upstream里，而是为这批客户新建专用upstream块：
- 每个客户或客户群对应一个独立upstream，名称体现业务含义，如upstream client_a_gov、upstream bank_b_core
- 在该upstream中只写目标后端服务器（即你希望黏滞到的那台或几台），例如：
server 10.10.5.20:8080;
server 10.10.5.21:8080; - 紧接声明ip_hash; ——此时哈希仅在这两台之间计算，客户IP必然落在其中一台，且长期稳定
用map模块精准路由到专属upstream
仅靠upstream不够，还需把客户请求“导流”过去。使用Nginx内置map模块，根据$remote_addr匹配客户IP段，映射到对应upstream名称：
- 在http块顶部添加map定义：
map $remote_addr $backend_group {
default "common_backend";
~^203\.107\.128\. client_a_gov;
~^112\.64\.192\. bank_b_core;
} - location中proxy_pass动态指向：
proxy_pass http://$backend_group; - 这样，客户A的请求进来就进client_a_gov这个含ip_hash的upstream，天然锁定；其他用户走默认common_backend（可用轮询或其他策略）
确保真实IP可用，绕过中间层干扰
政企环境常经过防火墙、网闸或省级政务云负载均衡器，$remote_addr易被覆盖为内网地址。必须还原原始IP：
- 在http块中配置可信源：
set_real_ip_from 10.200.0.0/16; # 示例：政务云LB网段
set_real_ip_from 192.168.254.0/24; # 示例：本地网闸出口
real_ip_header X-Forwarded-For;
real_ip_recursive on; - 同时要求上游设备（如WAF、网关）必须在X-Forwarded-For头部追加原始客户IP，且不伪造
- 验证方式：在log_format中加入$realip_remote_addr，确认日志记录的是客户真实出口IP
规避常见失效点
政企场景下这几个细节极易导致黏滞失败：
- IPv6需显式支持：若客户已启用IPv6双栈，确保Nginx ≥1.19，并在map中补充IPv6正则匹配（如~^240e:3b2:.*$）
- 避免upstream节点变动：客户专用upstream中服务器数量、顺序不能随意增减；临时下线某台，应使用down标记而非直接删除，否则哈希映射整体偏移
- 不混用weight或backup：ip_hash与weight、backup互斥，一旦启用就自动忽略，还可能引发Nginx启动报错
- 灰度验证要真IP实测：用客户实际出口IP（非办公内网）发起curl -v请求，观察后端access.log是否始终命中同一台机器
