iphash负载均衡原理是什么？入门知识、配置要点与常见疑问全解析

iphash（IP哈希）是负载均衡领域里最经典的会话保持方案之一。它的核心目标很明确：让来自同一个客户端IP的请求，始终被转发到同一台后端服务器上。这解决了一个非常实际的问题——当应用把用户登录状态、购物车数据保存在服务器本地内存或本地文件中时，如果负载均衡器把同一用户的请求随机分发到不同机器，用户就会莫名被登出。iphash通过“IP决定归属”的方式，让这种有状态部署依然能正常工作。下面我们从原理、配置、常见疑问三个层面把这个机制讲透。

iphash的工作原理：从哈希取模说起

iphash的底层逻辑可以用一句话概括：对客户端IP做哈希运算得到一个整数，再用这个整数对后端服务器数量取模，得到的结果就是目标服务器的编号。举个例子，假设有三台后端服务器，客户端IP经过哈希函数计算得到数值200，那么200 % 3 = 2，请求就会发给编号为2的那台服务器。只要服务器列表不变、哈希算法不变，这个IP的请求永远落在同一台机器上。

在nginx的实现中，ip_hash指令默认取的是客户端IP的前三个八位段参与计算，也就是说192.168.1.10和192.168.1.99会被认为是同一个来源。这个设计是有意为之的，因为在早期的网络环境中，同一个公司或校园网出口往往共享同一个C类网段，把整个网段哈希到同一台服务器，可以减少局域网内多用户请求分散的情况。但这也带来一个副作用：同一局域网内的所有用户都会被压到同一台后端上，如果这个局域网用户量大，负载就会严重不均。

还需要理解一点，iphash本质上是一种“确定性分发”而非“公平分发”。轮询（round robin）追求的是请求数量均等，least_conn追求的是连接数均衡，而iphash优先保证的是会话粘性。当后端某台服务器宕机被剔除出集群时，nginx会把原本发往该机器的请求按剩余服务器重新哈希分发，这个过程会造成部分用户的session丢失，这是取模类哈希的天然缺陷，后面我们会详细讨论。

nginx中ip_hash的配置方法与操作要点

配置iphash非常简单，只需要在upstream块中加入ip_hash指令即可。下面是一个典型的配置示例：

upstream backend {
    ip_hash;                     # 开启IP哈希负载均衡

    server 192.168.1.101:8080;   # 后端服务器A
    server 192.168.1.102:8080;   # 后端服务器B
    server 192.168.1.103:8080;   # 后端服务器C
}

server {
    listen 80;
    server_name www.ipipp.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

配置时有几个要点需要注意。第一，ip_hash指令必须写在server列表之前，写在后面会导致配置报错。第二，如果使用了多级代理，nginx拿到的客户端IP可能是上一级代理的IP而不是真实用户IP，此时需要结合real_ip_header和set_real_ip_from指令从X-Forwarded-For中还原真实IP，否则哈希的结果会失真——所有经过同一代理的请求都会被哈希到同一台服务器，负载均衡完全失效。

第三，权重参数weight在iphash模式下可以配合使用，但效果与轮询时不同。hash结果对权重求模后，权重高的机器会被分配到更多的哈希区间，从而承接更多不同的IP段。另外，如果希望手动控制某台服务器只接特定流量，可以用down参数临时摘除机器，被摘除机器上的IP会自动重新哈希到其他存活节点；backup参数标记的备份服务器只有在所有主服务器不可用时才会参与哈希计算。

iphash与其他负载均衡策略的对比

要真正理解iphash的适用场景，最好的方式是和其他常见策略放在一起比较。下面的表格概括了几种主流策略的核心差异：

从表中可以看出，iphash的不可替代性在于会话保持。如果你的应用已经改造为无状态（session集中存到Redis、数据库），那么轮询或least_conn通常比iphash更优，因为IP分布天然不均匀，某些大流量客户端会拖垮单台后端。而一致性哈希是对简单取模哈希的改进，它在服务器增减时只影响相邻区间的key，迁移量远小于取模哈希的全量重分布，在需要频繁扩缩容的集群中更值得选择。

常见疑问解答

疑问一：为什么用户换了网络session还是丢了？iphash的粘性建立在客户端IP不变的前提下。手机用户从WiFi切换到4G，IP会发生变化，哈希结果随之改变，请求被发到另一台服务器，本地session自然找不到了。同理，运营商动态IP、代理池都会打破粘性。如果业务对session连续性要求高，根本解法还是session集中存储，iphash只能作为辅助手段。

疑问二：后端服务器宕机后请求怎么处理？nginx的ip_hash会在检测到某台server不可用（默认通过失败次数判断，结合max_fails和fail_timeout）后将其剔除，原本属于该机器的IP会被重新哈希到剩余节点。此时这部分用户的session会丢失，属于预期行为。需要注意，剔除是暂时的，经过fail_timeout时间后nginx会再次尝试该服务器，如果它恢复了，部分流量又会切回来，这个来回切换的过程可能造成session反复丢失，排查问题时不要忽略这一点。

疑问三：iphash会不会导致负载严重不均？会的，尤其是客户端集中在大局域网或运营商出口IP复用严重的情况下。前文提到nginx取IP前三个八位段参与哈希，等于把整个C类网段绑定到一台后端。如果某个学校、企业几千人共享一个出口IP，所有请求都会打到同一台机器上。缓解办法包括：改用hash $remote_addr consistent做一致性哈希、对C类网段限流，或者干脆做session外置，回归轮询策略。

疑问四：ip_hash和hash指令有什么区别？ip_hash是早期的固定实现，只针对IP且算法固定；而hash指令更灵活，可以对任意变量计算哈希，比如hash $cookie_userid consistent可以按cookie中的用户ID做粘性，consistent参数启用一致性哈希算法。在新项目中，官方更推荐用hash指令替代ip_hash，功能上是超集关系。

总的来说，iphash是一个简单可靠、上手成本极低的会话保持方案，适合中小规模、后端数量相对稳定、客户端IP分散的场景。理解它的哈希取模本质和IP变化带来的局限性，再根据实际业务决定是继续使用还是升级到session集中存储加一致性哈希的架构，就能在负载均衡选型上少走很多弯路。

iphash负载均衡负载均衡原理nginx ip_hash修改时间：2026-09-13 21:57:11