2026-09-07 · 6 min read · Rahul Chitturi
- websocket
- proxy
- debugging
A WebSocket begins as an HTTP request and switches protocols only after a valid handshake. A reverse proxy that routes ordinary HTTP correctly can still strip upgrade headers, select the wrong upstream, or close an idle upgraded connection.
Symptoms range from an immediate 400 or 502 to a healthy connection that disconnects at a fixed interval.
Separate handshake from connection lifetime
Capture the browser URL, scheme, request and response status, relevant handshake headers, proxy route, upstream result, negotiated subprotocol, and timestamps. A 101 response proves only that the protocol switched; it does not explain a later close.
- Use wss when an HTTPS page requires a secure connection
- Forward Upgrade and Connection according to proxy semantics
- Validate Origin with an explicit application policy
- Preserve supported subprotocol values end to end
Trace timeouts and close ownership
Compare disconnect timing with proxy idle timeouts, load balancer limits, application heartbeat intervals, deploys, and mobile network changes. Record close code and reason on both client and server whenever the protocol permits it.
Heartbeats should detect dead peers without creating synchronized traffic spikes. Reconnect with bounded backoff and jitter, and restore subscriptions using application-level state rather than assuming a resumed transport.
A Flashman workflow
Use the URL tool to verify ws and wss endpoints, timestamp converter to align disconnects, JSON formatter for sanitized event envelopes, diff for proxy configurations, and Base64 only for public binary-frame fixtures.
Test direct and proxied handshakes, wrong origins, subprotocol mismatches, idle and active connections, rolling deploys, reconnect storms, oversized messages, authentication expiry, and graceful shutdown.