Open a WebSocket handshake against a ws:// or wss:// endpoint and report whether the server accepts the upgrade, along with the HTTP status and negotiated subprotocol.
• WebSocket URL：Enter a ws:// or wss:// URL (a bare host defaults to ws:// and path /); http/https URLs are accepted and mapped to ws/wss
• What is checked：The opening handshake (HTTP Upgrade → 101 Switching Protocols) is completed, then the connection is closed immediately — no application frames are exchanged
• Result fields：connected (handshake accepted), handshake time in ms, the HTTP status code returned, and the negotiated subprotocol if any
• Node selection：Optionally select specific nodes; all available nodes are used by default
A WebSocket test performs only the opening handshake against a ws:// or wss:// endpoint: it sends the HTTP Upgrade request and confirms the server responds with 101 Switching Protocols, then closes the connection. This is the WebSocket analogue of a TCP connect check — a fast way to confirm the endpoint is live and speaking the WebSocket protocol without exchanging any application data.
Common uses include verifying that a real-time backend (chat, notifications, live dashboards, trading feeds) accepts connections, checking that a reverse proxy or load balancer correctly forwards the Upgrade header, and confirming that a wss:// endpoint presents a valid TLS certificate before the handshake.
No. It completes the handshake only and then closes the connection immediately. It confirms the endpoint accepts WebSocket upgrades but does not send or receive application frames, so it won't trigger any business logic on the server.
A successful WebSocket handshake returns HTTP 101 (Switching Protocols). Any other status — 400, 401, 403, 404, 426, 5xx — means the server refused the upgrade, often because of a missing header, authentication requirement, wrong path, or an endpoint that is not actually a WebSocket.
Yes. Use a wss:// URL and the probe negotiates TLS as part of the handshake. If the certificate is invalid or the TLS handshake fails, the check reports a handshake failure with the underlying error.
WebSocket connections can negotiate an application-level subprotocol (e.g. graphql-ws, mqtt) during the handshake. The result shows the subprotocol the server selected, if any — useful for confirming the endpoint speaks the protocol your client expects.