WebSocket Tester
Open a real WebSocket connection from your browser, measure handshake time, optionally send a message and see what comes back.
Result
About WebSocket Tester
WebSocket problems usually turn out to be infrastructure problems: a proxy that strips the Upgrade header, an idle timeout that closes the connection, or a TLS failure. Opening a real connection from the browser separates those from application faults quickly.
Keeping a connection alive through middleboxes
WebSocket connections idle silently, and NAT devices, load balancers and firewalls reap idle sessions regardless of the standard. Send an application-level ping every 20 to 30 seconds, and set the reverse proxy read timeout comfortably above that — nginx defaults to 60 seconds, which is why so many deployments see a connection drop exactly one minute in. On the client, reconnect with exponential backoff and jitter, or a server restart will produce a thundering herd from every client at once.
Where WebSockets break
The handshake is an HTTP request with Upgrade: websocket; any proxy in the path must be configured to pass it through and to hold the connection open. Reverse proxies default to short read timeouts - nginx needs proxy_read_timeout raised and the Upgrade and Connection headers set explicitly. Idle connections also need application-level ping frames, because middleboxes reap idle TCP sessions regardless of what the standard says.
Common use cases
- Confirming a WebSocket endpoint is reachable from a user network.
- Measuring handshake latency to a realtime service.
- Proving a corporate proxy is blocking the Upgrade handshake.
Edge cases and gotchas
- Browsers block ws:// from an HTTPS page - always test wss://.
- The endpoint may reject connections based on Origin, so a failure here does not always mean the service is down.