WebSocket in production: proxies, security, and distributed architecture

You deploy your WebSocket server. Everything works in testing. In production, connections randomly drop after 60 seconds of silence, browsers report 1006s during idle periods, and your load balancer occasionally returns 502 on the upgrade. None of these are bugs in your application. They are proxy misconfigurations that are invisible until you know where to look.

Proxy and load-balancer misconfigurations

Proxies like Nginx, HAProxy, and AWS ALB were designed for HTTP — short-lived request-response conversations measured in milliseconds. A persistent WebSocket connection is alien to them. Common misconfigurations:

Problem 1 — Idle timeout closes quiet connections.

• Nginx default: proxy_read_timeout 60s (closes if no data in 60 seconds).
• AWS ALB default: idle_timeout.timeout_seconds = 60.
• Fix: raise to at least 3,600 seconds (1 hour).

location /ws {
  proxy_pass http://backend;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "Upgrade";
  proxy_read_timeout 3600s;
  proxy_send_timeout 3600s;
  proxy_buffering off;
}

Problem 2 — L7 buffering delays the 101 response. Nginx buffers HTTP responses by default. The 101 Switching Protocols response is held in the buffer until it is “complete” — but a WebSocket never completes its response. This can delay the upgrade by hundreds of milliseconds. Fix: proxy_buffering off.

Problem 3 — Proxy doesn’t understand the Upgrade header. Some proxies strip or ignore Connection: Upgrade headers. The backend sees the request without Upgrade headers and returns a regular HTTP response instead of 101. Fix: explicitly set both headers as shown above.

Problem 4 — HTTP/2 proxy doesn’t forward WebSocket upgrades. If the proxy is HTTP/2 but the backend is HTTP/1.1, the proxy may not know to handle WebSocket extended CONNECT. Fix: test WebSocket through the proxy stack explicitly during deployment, not just HTTP traffic.

Security: Origin checks, DoS, and slow-reader attacks

Origin check. The browser always sends an Origin header on WebSocket upgrades. The server must validate it:

if request.headers["Origin"] not in ALLOWED_ORIGINS:
    respond 403 Forbidden
    return

A WebSocket client outside the browser does not send an Origin header by default — if your server requires it, non-browser clients must add it. This is the primary defense against cross-site WebSocket hijacking (CSWSH), where a malicious page on attacker.com opens a WebSocket to api.yoursite.com using the victim’s cookies.

Rate limiting at the handshake. Botnets can exhaust the TCP SYN backlog with connection attempts. Rate-limit at the load balancer: maximum connection attempts per IP per second (typically 5–20). Apply TCP SYN cookies at the OS level (net.ipv4.tcp_syncookies = 1).

Slow-reader (Slow Loris) attack. A malicious client completes the WebSocket handshake but never reads from its socket. The server’s send queue fills for that connection. Mitigation: close connections with no data activity within 30 seconds (no message sent or received, no pong reply to a ping).

Per-message size limits. A client sending a 100 MB message forces the server to buffer 100 MB per subscriber. Enforce a maximum message size (typically 64 KB–1 MB) and close the connection with code 1009 (“message too big”) if exceeded.

Horizontal scaling: pub/sub and sticky sessions

A single WebSocket server hits its scale ceiling at 500 k–2 M connections. Beyond that, you need multiple servers with a shared messaging backbone.

Pub/sub (Redis Streams or RabbitMQ). Each server subscribes to the relevant channel(s). When the application publishes a message, all subscribed servers broadcast it to their local connected clients:

User A (connected to Server 1) sends a chat message.
Server 1 publishes { roomId, message, msgId } to Redis stream "room:42".
Server 2 (also subscribed to "room:42") reads from the stream.
Server 2 broadcasts to its locally connected users in room 42.

This decouples senders from receivers and allows horizontal scale without requiring all clients to be on the same server.

Sticky sessions. When a load balancer routes the same client to the same server across reconnects, in-flight state (unACK’d messages, partial subscriptions) is preserved without requiring full Redis replication. AWS ALB implements this as target group stickiness (1-hour cookie by default). The downside: server failures send all sticky clients to reconnect to other servers simultaneously — a mini thundering herd per failed instance.

Observability: metrics you must export

A WebSocket service without these metrics will OOM silently:

Tools: netstat -an / ss -s for socket state counts, tcpdump for packet-level traces, Prometheus for application metrics, eBPF programs for socket buffer sizes and retransmit rates.