How to Fix WebSocket "Connection Closed Before Established" Errors

A WebSocket "connection closed before established" error means the connection failed during the initial handshake phase — before the WebSocket protocol upgrade completed — which means the problem is almost never in your application's message-handling code, since that code never gets a chance to run. The failure happens at a lower level: networking, proxy configuration, or server setup.

The most common cause in production deployments is a reverse proxy or load balancer that isn't configured to support the WebSocket upgrade handshake. WebSocket connections start as a regular HTTP request with special upgrade headers, and if an intermediary proxy (Nginx, a cloud load balancer, an API gateway) doesn't explicitly pass through those upgrade headers, the connection gets treated as a normal HTTP request and closed rather than upgraded, from the client's perspective looking exactly like a connection that closed immediately.

This is exactly why a WebSocket connection that works perfectly in local development (talking directly to your server with no proxy in between) can fail immediately once deployed behind a production reverse proxy — the difference isn't your application code at all, it's whatever sits in front of it in production that local development doesn't have.

Mixed content and protocol mismatches cause a related but distinct failure — attempting a plain `ws://` connection from a page served over HTTPS is blocked by browsers for the same mixed-content reasons that block plain HTTP resources on an HTTPS page. The fix is using `wss://` (the WebSocket equivalent of HTTPS) consistently whenever the page itself is served over HTTPS, which is effectively always in production.

CORS-adjacent origin restrictions can also close a WebSocket connection during the handshake if the server explicitly validates the request's origin header and rejects connections from origins it doesn't recognize — this is a legitimate security measure, but it fails in exactly this way (an immediately closed connection, not a clear origin-rejected error) if the allowed-origins configuration doesn't include the actual domain the client is connecting from, particularly easy to miss when a staging or preview domain isn't included alongside production.

Server-side connection limits and timeout settings occasionally cause this too, particularly under load — if a server is configured with an aggressive handshake timeout or has hit a maximum concurrent connection limit, new connection attempts fail at the handshake stage rather than being queued, and this can look identical to a proxy or protocol issue until server-side logs or metrics rule it in or out.

To debug systematically: first confirm the connection works when talking directly to the server with no proxy involved (isolating whether the issue is proxy configuration), then check the browser's network tab for the specific handshake request and its response code and headers (a 101 Switching Protocols response means the handshake succeeded; anything else means it failed before your WebSocket code ever ran), which usually narrows the cause to one of the categories above quickly.