How to Implement Advanced HAProxy Sticky Sessions for Scalable Websocket Infrastructure

Why WebSocket Load Balancing Breaks Without Sticky Sessions

At Zentara, real-time collaboration tools are the heartbeat of our platform. Therefore, a steady WebSocket connection is the foundation of the user experience. 

However, scaling stateful protocols like WebSockets behind a high-performance load balancer presents a unique architectural challenge. The default nature of standard load balancing is where every request is a roll of the dice simply just doesn’t cut it. 

Why Traditional Load Balancing Fails for Stateful WebSocket Sessions

If a client’s handshake hits Server A but their next requests are routed to Server B, the session fragments, and the user sees a connection lost alert. To solve this, we needed a solution that was resilient, granular, and capable of horizontal scalability.

Standard algorithms like round-robin or least-connections are perfect for stateless REST APIs. But WebSockets are different. They are long-lived and often rely on local server memory to track the state of a live session.

In a distributed system without persistence:

1. User A connects and establishes a WebSocket session on Server 1.
2. A network blip occurs, or a new tab is opened.
3. The load balancer sends the new request to Server 2.
4. Server 2 has no record of User A, forcing a full re-authentication and state rebuild.

This creates massive overhead and latency spikes. We needed to ensure that once a client finds the correct backend server and stays there. Our team realized that we needed to move beyond simple hashing. 

While balance source (IP hashing) is a common quick fix. But it creates a hotspot when thousands of users connect from a single corporate NAT IP, pinning them all to one overworked server.

The solution is using HAProxy Stick Tables. By using in-memory key-value stores, we can track sessions with surgical precision using either the client’s IP or, more elegantly, a custom application-level identifier like X-Session-ID.

Layer 4 Sticky Sessions with HAProxy (IP-Based Persistence)

For endpoints where we can’t or don’t want to inspect the application layer, we implement IP-based persistence. But we don’t just use standard hashing. We use Consistent Hashing.

backend websocket_cluster
    mode tcp
    balance source
    hash-type consistent
    server srv_1 10.0.0.1:8080 check
    server srv_2 10.0.0.2:8080 check

Why this works: In standard hashing, adding a third server (srv_3) would change the hash result for everyone, causing a global session disconnect. With hash-type consistent, only the users mapped to a failing or newly added server are redistributed.

Layer 7 Sticky Sessions with Custom Headers

To achieve true granularity that survives mobile network handovers for example where a user’s IP changes from Wi-Fi to 5G, we moved to Custom Header Persistence. We track a unique X-Session-ID generated before handshake.

Step 1: Create a Stick Table for Session Tracking

We allocate a string-based table in HAProxy’s memory to store the mapping.

Step 2: Match and Store Session IDs in HAProxy

We configure HAProxy to match the header on incoming requests and store the session ID from the response.

backend ws_api_service
    mode http
    # 64-char limit, 30-minute expiration for inactive sessions
    stick-table type string len 64 size 100k expire 30m
    
    # On the way in: Check if we already know this session
    stick match hdr(X-Session-ID)
    
    # On the way out: Record which server handled this session ID
    stick store-response hdr(X-Session-ID)
    
    server ws_node_alpha 10.1.0.10:80 check
    server ws_node_beta  10.1.0.11:80 check

This bypasses the load balancer’s algorithm entirely once a connection is established. It tracks the session, not the connection.

Performance Impact of HAProxy Sticky Sessions

Since migrating specific service to this synchronized stick table architecture, the results have been transformative:

• 99.9% Session Stability: Re-authentication events during backend scaling decreased by 85%.
• Zero-Downtime Reloads: We can now push infrastructure updates without kicking users off their live sessions.
• NAT Efficiency: Load distribution is now perfectly balanced based on active sessions, rather than skewed by corporate proxy IPs.

Implement HAProxy Sticky Sessions with Zentara

Ready to build resilient real-time infrastructure that keeps user sessions stable even at scale?

Zentara’s cloud security and infrastructure engineering team helps organizations design high-availability architectures that support demanding workloads like WebSockets, real-time collaboration platforms, and distributed systems.

Whether you’re optimizing load balancing, strengthening session persistence, or securing cloud-native environments, our specialists can help you implement solutions that scale without sacrificing reliability.

Contact Zentara today to discuss your infrastructure goals or explore our services to harden and optimize your platform.