在 nginx 中使用 ip_hash 时，处理大局域网相同网段导致后端节点负载不均的核心做法是配置 hash $remote_addr consistent;。这能启用一致性哈希算法，当后端服务器增加或减少时，只有少量请求会重新分配，从而缓解因大量客户端共享同一公网出口 ip 而导致的单点过载问题。
为什么 ip_hash 会导致同网段负载不均
因为默认情况下 ip_hash 使用简单的取模算法，所有来自同一出口 IP 的请求都会固定映射到某一台后端服务器。在大局域网中，成百上千的用户共用一个 NAT 网关出口，导致该网关对应的后端节点压力巨大，而其他节点闲置。
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
上述配置中，如果用户 A、B、C 都通过网关 203.0.113.5 访问，他们的请求都会落在同一个后端节点上。这种静态映射在节点变动时会导致严重的缓存穿透和负载倾斜。
如何配置一致性哈希优化分布
通过在 upstream 块中添加 consistent 参数，Nginx 会使用 Ketama 一致性哈希算法。这使得即使后端节点数量变化，大部分请求仍能留在原节点，同时不同出口 IP 的分布更加均匀。
upstream backend {
hash $remote_addr consistent;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
修改后，网关 203.0.113.5 的请求会根据哈希环的位置分配到不同的后端。虽然同网段用户仍可能集中在少数几个节点，但相比取模算法，整体分布更平滑，且扩容时影响范围更小。
基于 $remote_addr 的具体行为分析
当使用 hash $remote_addr 时，Nginx 直接提取客户端的源 IP 地址作为哈希键。对于经过 NAT 的大局域网，这个值就是网关的公网 IP。这意味着所有内部用户的会话粘性是基于网关 IP 而非单个设备 IP，这是导致负载不均的根本原因。
