ip_hash通过客户端IP哈希取模实现请求与后端服务器固定绑定，IPv4取前三段、IPv6用完整地址计算，确保相同IP始终路由至同一节点；需配合real_ip配置还原真实IP，避开代理干扰、NAT复用及节点变动导致的映射偏移。
IP Hash 是 Nginx 实现客户端请求与后端服务器“绑定”的核心机制，它不靠 Cookie 或 Session，而是用客户端 IP 做哈希计算，确保相同 IP 的请求始终落到同一台后端——这正是精准流量引导的基础。
ip_hash 如何实现“精准”路由
它对 IPv4 地址取前三个字节（如 192.168.1.100）、对 IPv6 使用完整地址进行哈希运算，再对当前可用后端数量取模。结果固定，路径就固定。
- 只要后端列表没增删、服务器没 down，同一个 IP 永远走同一台机器
- 哈希过程不可逆、无配置干预点，所以没有“误分配”或“随机跳转”问题
- 它天然兼容故障转移：某台 server 不可用时，Nginx 自动剔除它，剩余节点重新取模，IP 会稳定迁移到新映射位置（不是乱跳）
真实环境中的精准性保障要点
精准不是默认生效的，得避开几个典型陷阱：
- 多层代理下，
$remote_addr是上一跳（比如 CDN 或 LVS）的 IP，不是用户真实 IP → 必须配set_real_ip_from+real_ip_header X-Forwarded-For提前还原 - 内网 NAT 或运营商共享出口，大量用户共用一个公网 IP → 此时“精准”是按出口 IP 绑定，不是按人，需结合
hash $cookie_session_id等补充策略 - 扩容缩容会改变取模基数，导致原有 IP 映射关系整体偏移 → 若业务强依赖长期粘性，建议搭配一致性哈希（
hash $remote_addr consistent）用于 stream 模块，或在 HTTP 层用外部 session 存储解耦
配置写法与常见错误
ip_hash 必须放在 upstream 块的第一行或紧随其后，且不能和其它 hash 类指令并存：
- ✅ 正确：
upstream app { ip_hash; server 10.0.1.10:8080; server 10.0.1.11:8080; } - ❌ 错误：加了
weight=2—— ip_hash 不支持权重，该参数会被忽略 - ❌ 错误：写成
hash $remote_addr;在 HTTP upstream 中 —— 这是通用 hash，不是 ip_hash，行为不同（比如不自动处理 IPv4 截断） - ❌ 错误：在 stream 模块里用 ip_hash —— stream 不支持，得换
hash $remote_addr consistent;
什么场景下它最“精准”，什么场景会打折
精准性取决于你的流量特征和基础设施设计：
- 对 PC 端直连用户、企业专线用户、IPv6 原生用户，IP 变化少，粘性极强，效果最好
- 对移动网络用户（尤其开启 IPv6+IPv4 双栈或频繁切换基站），IP 可能分钟级变动 → 粘性变弱，此时更推荐基于 Cookie 或 token 的会话保持
- 若后端服务本身有状态（如内存缓存用户数据），ip_hash 是低成本保状态的首选；若服务已无状态，反而可能因负载不均带来瓶颈（比如某 IP 流量突增压垮单台）
