负载均衡是高并发系统中不可或缺的一环，而iphash（IP哈希）则是众多负载均衡策略中最常被提起的会话保持方案。当业务需要把同一个用户的请求始终路由到同一台后端服务器时，iphash往往是配置成本最低、见效最快的选择。本文将从原理、配置、优缺点三个维度，带你系统了解iphash负载均衡。
一、iphash负载均衡的工作原理
iphash的核心思想非常直观：负载均衡器拿到客户端的IP地址后，通过固定的哈希算法将其映射成一个数值，再对这个数值按后端服务器数量取模，得到一台目标服务器。由于哈希算法是确定性的，只要客户端IP不变、后端服务器列表不变，每次计算的结果都指向同一台机器，这就实现了所谓的会话粘性（Session Sticky）。
以Nginx为例，当upstream中配置了ip_hash指令后，Nginx会对客户端IP执行哈希运算。对于IPv4地址，Nginx默认取IP地址的前三个字节参与哈希计算，这意味着同一个C类网段内的用户会被分发到同一台服务器。这么设计的原因是早期互联网中大量用户通过局域网共享公网IP上网，按C类网段哈希可以在一定程度上让同一企业、同一网吧的用户保持会话一致。
需要注意的一个关键点是：iphash基于的是直接与负载均衡器建立连接的那个IP。如果客户端和负载均衡之间还有CDN、反向代理或者LVS/NAT转发，那么负载均衡看到的IP将是代理设备的IP，此时所有请求可能全部被哈希到同一台后端服务器，导致负载严重不均，甚至让iphash彻底失效。这是实际部署中最常见的坑。
二、iphash在Nginx中的配置方法
iphash的配置非常简单，只需在upstream块中添加ip_hash指令即可。下面是一个典型的配置示例：
upstream backend {
ip_hash; # 开启iphash负载均衡
server 192.168.1.10:8080; # 后端服务器A
server 192.168.1.11:8080; # 后端服务器B
server 192.168.1.12:8080; # 后端服务器C
}
server {
listen 80;
server_name www.ipipp.com;
location / {
proxy_pass http://backend; # 将请求转发到后端集群
proxy_set_header X-Real-IP $remote_addr;
}
}配置中的ip_hash指令必须写在server指令之前，否则Nginx启动时会报配置错误。开启之后，Nginx会自动维护IP到服务器的映射关系，无需额外参数。如果某台后端服务器需要临时下线维护，但又不想让大量用户会话重新分布，可以使用down状态标记它：
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080 down; # 临时下线，不参与哈希分配
server 192.168.1.12:8080;
}标记为down的服务器会被排除在哈希计算之外，而剩余服务器之间的映射关系依然保持稳定。但如果直接从配置文件中删除某台服务器，那么哈希取模的基数发生变化，几乎所有用户的会话都会重新分配，这一点在扩容和缩容时要特别留意。
三、iphash与其他负载均衡算法的对比
默认的轮询（round robin）策略按顺序依次分发请求，配置最简单，但无法保持会话；加权轮询允许给性能强的服务器分配更高权重，适合后端机器配置不一致的场景；最少连接（least_conn）把请求发给当前连接数最少的服务器，适合请求耗时差异大的业务。iphash的独特价值在于会话保持，但代价是牺牲了分发均匀性。
| 算法 | 会话保持 | 分发均匀性 | 适用场景 |
|---|---|---|---|
| 轮询 | 不支持 | 好 | 无状态服务 |
| 加权轮询 | 不支持 | 按权重分布 | 后端性能不均 |
| 最少连接 | 不支持 | 较好 | 长连接、请求耗时不一 |
| iphash | 支持 | 依赖IP分布 | 有会话状态的业务 |
从表中可以看出，iphash并不是万能解。当客户端IP分布极不均匀时，比如大量用户集中在少数几个网段，某些后端服务器可能承载远超平均值的流量。因此iphash更适合作为会话保持的过渡方案，长期来看更稳妥的做法是把Session外置到Redis等共享存储中，让后端真正做到无状态。
四、使用体验与功能亮点总结
从实际使用体验来看，iphash最大的亮点是零改造成本。不需要修改应用代码，不需要引入外部Session存储，一行配置就能解决登录态丢失、购物车清空这类经典问题，对于中小型项目和老系统改造非常友好。同时它对后端完全透明，服务器不需要感知负载均衡的存在。
但它也有明显的局限。首先是前文提到的代理穿透问题，遇到多层代理时需要借助X-Forwarded-For头获取真实IP，而Nginx原生ip_hash并不支持按该头做哈希，此时需要改用第三方模块或商业版的sticky cookie方案。其次是宕机重新分发的问题：一旦某台后端服务器故障，原本路由到它的用户会全部被重新哈希到其他服务器，会话瞬间失效。最后是扩容灵活性差，增减服务器都会引起大面积会话迁移。
综合来看，iphash适合这些场景：后端有本地Session且改造困难、客户端直连负载均衡器（中间无代理）、服务器数量相对稳定的系统。如果你的架构中存在CDN或多层Nginx，建议改用基于Cookie的会话保持，或者直接将Session集中存储到Redis，通过proxy_set_header传递真实客户端IP，再配合一致性哈希实现更平滑的扩缩容。理解iphash的边界，才能在正确的场景里发挥它的最大价值。
iphash负载均衡nginx ip_hash修改时间：2026-09-02 02:18:30