websocat (WebSocket probe)
Send a WebSocket Upgrade handshake and verify the Sec-WebSocket-Accept response, subprotocols, and extensions.
Monitor this automatically
NetTests can run this check on a schedule, preserve historical results, compare changes over time, and alert you the moment something breaks.
Start monitoring free → See all monitoring productsFrequently Asked Questions
What does the WebSocket Probe check?
It sends an HTTP Upgrade request (Connection: Upgrade, Upgrade: websocket, Sec-WebSocket-Key) and verifies that the server responds with a valid 101 Switching Protocols status. The result shows the negotiated subprotocol, accepted extensions (e.g. permessage-deflate), and the computed Sec-WebSocket-Accept header for validation.
What is the WebSocket handshake?
A WebSocket connection starts as an HTTP/1.1 request with an Upgrade header. The client sends a base64-encoded random nonce as Sec-WebSocket-Key. The server concatenates it with a fixed magic GUID, computes SHA-1, base64-encodes the result, and returns it as Sec-WebSocket-Accept. This tool verifies the computation to confirm the server is a real WebSocket endpoint.
What are WebSocket subprotocols?
Subprotocols are application-level agreements on the message format over the WebSocket connection: graphql-ws, stomp, mqtt, chat, etc. The client proposes subprotocols via Sec-WebSocket-Protocol; the server picks one and echoes it back. If no match, the server may omit the header or close the connection.
How do I test a WebSocket behind authentication?
Add an Authorization header in the form. WebSocket connections can carry HTTP headers during the initial Upgrade handshake — Bearer tokens and API keys work the same way as in regular HTTP. Cookie-based auth is not directly testable here, but most token-based WebSocket APIs accept an Authorization header.