Source-address persistence (also called simple persistence) keys entirely on the client's IP address: the first connection from an address picks a pool member, and every later connection from that same address goes to the same member. It needs nothing from the application, which is its appeal, and it rests on one assumption, which is its weakness: that one IP means one client.
When many clients share one address
That assumption fails behind a large (network address translation) or proxy, the classic mega-proxy case. When thousands of users sit behind one corporate NAT, a -grade NAT, or a big proxy farm, they all arrive with the same source IP. Source-address persistence sees one address and pins every one of those users to a single pool member. The result is the opposite of load balancing: one member is buried while the others sit idle, and if that member fails, a huge block of users is affected at once. Carrier-grade NAT has made this common enough that source-address persistence can quietly wreck the distribution you expected.
When one client changes address
The mirror-image failure is a client whose address changes during a session. A mobile device roaming between networks, or a client behind a pool of proxies that rotates its outbound IP, presents a new source address partway through and loses its persistence, landing on a different member and dropping whatever session state lived on the first one. The persistence timeout does not help here; the key itself moved.
What to do about it
Source-address persistence is still fine where the assumption holds: internal traffic with known, stable, one-per-client addresses, or protocols where there is nothing better to key on. Where clients are behind shared NATs or change address, a method that keys on something tied to the actual session is more reliable, cookie persistence for HTTP being the usual choice, since it identifies the client rather than the address it happens to arrive from. The decision comes down to whether IP address is a trustworthy stand-in for identity in your traffic, and increasingly, on the public internet, it is not.
Source-address persistence assumes an address means a user
It did, once. Carrier-grade NAT, corporate egress and mobile networks have made a single address mean thousands of unrelated clients, and a persistence method keyed on it sends them all to the same member.
The result is not a failure; it is an imbalance nobody attributes correctly. One pool member carries a disproportionate share, its metrics look like a capacity problem, and adding members does not help because the distribution key has fewer distinct values than there are members to spread across.
And the opposite failure runs alongside it: a client whose egress address changes mid-session — a phone moving between networks — loses its persistence and lands somewhere new. One address, many users; one user, many addresses. Both break the assumption in the same method, and the cure is a persistence key that identifies the session rather than the path it arrived by.