IP hash is a load balancing algorithm that selects a backend server by applying a hash function to the client IP address, so that requests from the same address are consistently sent to the same server. In networking it is the simplest way to achieve session affinity without cookies or application changes, because the decision depends only on information present in every packet.
The method is deterministic and stateless: the load balancer does not need a table remembering which client went where, since recomputing the hash always gives the same answer while the server pool stays unchanged. That property is both its main strength and the source of its main weaknesses.
How the IP hash algorithm chooses a server
The load balancer extracts the source IP address of the incoming connection, feeds it into a hash function and maps the result onto the list of healthy servers. In the classic form the mapping is a modulo operation: the hash value divided by the number of servers N leaves a remainder between 0 and N minus 1, which indexes the chosen server.
Implementations differ in which bits they hash. Some use the full address, others only part of it; NGINX, for example, uses the first three octets of an IPv4 address, so all clients in the same /24 network land on one server. Weighted variants map more hash buckets to stronger servers, and some products hash a combination of fields, as the table shows.
| Hash key | Fields used | Typical use |
|---|---|---|
| Source IP | Client address only | Session affinity for web applications |
| Source and destination IP | Client and virtual service addresses | Firewall and gateway clusters |
| Five-tuple hash | Addresses, ports and protocol | Per-flow distribution, ECMP routing |
| Client prefix | Part of the address, such as a /24 | Grouping clients from one network |
Because the algorithm needs only addresses, it works at Layer 4 and does not require decrypting traffic. It is available as ip_hash in NGINX, as balance source in HAProxy and as the source hashing scheduler in Linux IPVS.
IP hash compared with other load balancing algorithms
IP hash belongs to the family of hash-based algorithms, which trade even distribution for predictability. The comparison shows where it fits among common choices.
| Algorithm | Distribution basis | Session affinity | Main weakness |
|---|---|---|---|
| IP hash | Hash of client address | Yes, while the pool is stable | Uneven load behind shared addresses |
| Round robin | Rotation through servers | No | Ignores session state and server load |
| Least connections | Fewest active connections | No | Needs connection tracking |
| Cookie-based sticky session | Cookie set by the load balancer | Yes, per browser | Requires Layer 7 and HTTP |
| Consistent hashing | Hash ring with virtual nodes | Yes, with minimal remapping | More complex to implement |
In practice, cookie-based stickiness is preferred for HTTP applications where the balancer terminates TLS, while IP hash remains useful for non-HTTP protocols, encrypted passthrough traffic and simple deployments where adding cookies is impossible.
What happens when the server pool changes
The weakest point of modulo-based IP hash is pool changes. When a server is added or removed, N changes, and the remainder changes for most clients. With simple modulo hashing, removing one of N servers remaps roughly (N minus 1) divided by N of all clients, not only those of the removed server, so sessions break across the entire service.
| Pool size | Clients remapped with modulo hashing | Clients remapped with consistent hashing |
|---|---|---|
| From 4 to 3 servers | About 75 percent | About 25 percent |
| From 10 to 9 servers | About 90 percent | About 10 percent |
| From 20 to 19 servers | About 95 percent | About 5 percent |
Consistent hashing solves this by placing servers and clients on a hash ring so that only clients of the affected server move. Many modern load balancers therefore implement IP-based affinity on top of a consistent hash or a lookup-table scheme such as Maglev hashing, even when the configuration option is still labeled IP hash.
When to use IP hash and how to configure it
IP hash is a sound choice when server-side session state cannot be shared and the client population is large and diverse. The decision table summarizes typical situations.
| Situation | Recommendation | Reason |
|---|---|---|
| Stateful TCP service without cookies | Use IP hash | Affinity with no protocol changes |
| Clients behind a CDN or reverse proxy | Hash the forwarded client address instead | All traffic otherwise shares proxy addresses |
| Many users behind carrier-grade NAT | Prefer cookies or least connections | Shared addresses create hot servers |
| Frequently autoscaled pools | Use consistent hashing | Limits remapping when servers change |
| Stateless application | Use round robin or least connections | Affinity adds no benefit |
Health checks remain essential: when a server fails, its clients must be redistributed, and they lose any session data held only on that server. Combining IP hash with connection draining during maintenance reduces disruption for active users.
Pitfalls that reduce the effectiveness of IP hash
- Shared addresses: offices, universities and mobile carriers place thousands of users behind one public IP, overloading a single server.
- Changing client addresses: mobile devices switching between Wi-Fi and cellular networks get new IPs and lose affinity.
- IPv6 privacy addresses rotate periodically, which breaks affinity unless the hash uses a prefix.
- Proxy blindness: behind another proxy, the balancer sees only the proxy address unless the PROXY protocol or forwarded headers are used.
- False sense of persistence: affinity is not a guarantee, so applications should tolerate a request reaching a different server.
Explained without jargon
Imagine a bank with five tellers and a rule: your account number decides which teller you visit. Every time you come back, you go to the same teller, who already knows your case. Nobody needs to write down where you went last time, because the rule always gives the same answer.
IP hash does this with internet addresses. The same address always reaches the same server. The catch is that a whole office sharing one address all queue at one teller, and hiring a new teller reshuffles almost everyone.
A typical use case
An online gaming company runs a matchmaking service over a custom TCP protocol on six servers. Each server keeps player session state in memory, and the protocol has no cookies, so the team configures the load balancer with source IP hashing to keep each player on the same server.
After launch, monitoring shows one server at 90 percent CPU while others idle near 30 percent. Investigation reveals that thousands of players from one mobile operator share a few carrier-grade NAT addresses. The team switches to a consistent hash on the client address and source port, and moves session state to a shared in-memory store. The outcome is balanced load within 10 percent across servers and sessions that survive server restarts.