CertMon
WEBSOCKETS & PROXIES
Fix WebSocket and HMR Connection Failed Behind HTTPS Reverse Proxy
Seeing WebSocket connection to 'wss://myapp.test/' failed: WebSocket is closed before the connection is established in your browser console? Here is what causes it and how to fix it.
Start in Terminal: Nginx & Caddy configurations
When placing an HTTPS reverse proxy in front of a development server (Vite, Webpack, Turbopack, or Astro), HTTP/1.1 connection upgrade headers are stripped by default unless explicitly preserved:
# Nginx config fix for WebSocket reverse proxying
location / {
proxy_pass http://127.0.0.1:5173;
proxy_http_version 1.1;
# Mandatory WebSocket upgrade headers:
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# Prevent proxy read timeout during idle dev periods:
proxy_read_timeout 86400s;
proxy_send_timeout 86400s;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $remote_addr;
}Why it happens
WebSocket starts life as an HTTP/1.1 GET request with two special headers: Upgrade: websocket and Connection: Upgrade. The upstream dev server replies with HTTP status 101 Switching Protocols.
Standard reverse proxies treat client connections as request-response pairs. If the proxy fails to forward the Upgrade headers, or closes the socket when the initial HTTP handshake completes, the WebSocket connection terminates immediately, killing Hot Module Replacement.
How CertMon handles WebSockets automatically
CertMon's built-in reverse proxy inspects incoming HTTP request headers. When it detects an Upgrade: websocket header, it automatically transitions the connection into a raw, full-duplex TCP tunnel.
Framed WebSocket messages flow bidirectionally between your browser and backend dev server with zero packet buffering, zero timeouts, and full TLS encryption.
