30-Second Fix: Check the Cookie Name and Scope
Most times, session persistence dies because the cookie name doesn't match between the load balancer and the app. Or the cookie path is wrong. I've seen this with HAProxy and AWS ALB more times than I can count.
If you're using cookie-based persistence, hop into your load balancer config. Look for something like cookie SERVERID insert indirect nocache or stickiness.enabled = true in AWS. Then check your app returns the same cookie name in the response header. If they don't match — fix it.
Also check the cookie path. If your app sets a cookie with path /app but your load balancer expects /, sessions will bounce. Change the path to match. Test with a simple curl:
curl -I http://your-app.example.com/login | grep -i set-cookieIf you see the cookie, and the load balancer picks it up, you're done. If not, move on.
5-Minute Fix: Validate Health Check Configuration
Here's a sneaky one. Had a client last month whose session persistence kept failing. Turns out their health check was pointing to a static page that didn't exist on every backend server. When a server failed health check, the load balancer dumped it — and all active sessions with it.
Make sure your health check endpoint returns a 200 response from every backend server. Use a simple path like /health that returns OK. Don't use a dynamic page that takes database calls — that adds latency and can fail under load.
In HAProxy, check option httpchk GET /health is set. In Nginx, ensure health_check uri=/health is configured. In AWS ALB, the health check path must exist on every target.
Also check the interval. If your health check interval is too short (like 5 seconds), and one server hiccups for 10 seconds, it gets marked down and all sessions are redirected. Set interval to 15 seconds with 3 healthy thresholds before marking down.
15+ Minute Fix: Dive into Persistence Algorithm and Backend Consistency
If the first two steps didn't fix it, you've got a deeper issue. Let's break it down.
Check the Persistence Algorithm
You're using ip_hash in Nginx or source algorithm in HAProxy? Those rely on the client IP staying constant. But if clients are behind a proxy (like corporate VPN or mobile carrier NAT), the IP changes between requests. Your sessions will bounce. Switch to cookie-based persistence instead — it's more reliable for those scenarios.
In Nginx, change from ip_hash; to sticky cookie session_id;. In HAProxy, use cookie SERVERID insert indirect nocache instead of balance source. Test again.
Verify Backend Server Consistency
Each backend server must store session data in a shared location (like Redis or database), not in local memory. If you're using PHP sessions stored locally on each server, your persistence config doesn't matter — the user will lose session as soon as they hit a different server. Happens with load balancers that lack true stickiness.
Check your app's session storage. If it's local files or local memory, move to a shared Redis cluster or MySQL. Then update your load balancer's persistence to work with the shared store. This is the real fix for sticky sessions that don't stick.
Check Timeout Settings
Session persistence has its own timeout in some load balancers. In HAProxy, timeout client and timeout server must be long enough to cover your session duration. If your session timeout is 30 minutes but load balancer's client timeout is 5 minutes, the session cookie gets dropped after 5 minutes.
Set timeout client 30m and timeout server 30m in HAProxy. In Nginx, check proxy_read_timeout and proxy_send_timeout — set them to match your app's session timeout.
Test with a Controlled Scenario
Set up two backend servers. Use a browser to hit the app and capture the cookie. Then manually kill one server (stop the service). Watch if the session persists on the remaining server. If it drops, you've got a mismatch between persistence config and backend session storage.
Use browser dev tools to inspect the cookie: its domain, path, expiration. Compare with what the load balancer expects. If they don't align, adjust your config.
That's the whole flow. Start with the cookie, then health checks, then algorithm and storage. 90% of the time, it's the cookie or health check. But when it's not, the deeper fix handles it.