Test your WebSocket connection.

What this WebSocket test does

The check opens wss://netokay.net/v1/control/ws from this browser, sends one short challenge, and waits for a byte-identical echo. After the echo arrives the page closes the connection with code 1000 and records whether the close was clean. The whole exchange has a 15-second limit.

It is a browser-to-NetOkay control check: it shows that this browser can complete a WebSocket handshake, one message round trip, and a normal close through its current network path. It never connects to your application's server and cannot see your protocol.

Run the same WebSocket test from your own code

Paste this into a browser console or a small script to reproduce the check outside this page. The control endpoint echoes any text message and closes the socket itself after a bounded time.

const socket = new WebSocket('wss://netokay.net/v1/control/ws');
socket.onopen = () => socket.send('hello');
socket.onmessage = (event) => {
  console.log('echo:', event.data);
  socket.close(1000, 'done');
};
socket.onclose = (event) => console.log('closed:', event.code, event.wasClean);

From a terminal, the NetOkay CLI runs the same bounded template with --transport wss; see the CLI reference.

Reading the result

• Passed: the handshake, the echo, and a clean close with code 1000 were all observed from this browser.
• Failed: the connection did not open, the reply did not match the challenge, or the close was not clean. The page shows the observed close code when the browser exposes one.
• Timed out: nothing conclusive arrived within 15 seconds. That is a missing observation, not a proven failure.
• Stopped: you cancelled the check; no result is recorded.

A passed check does not verify a long-lived session, reconnect behaviour, authentication, or your application's own message protocol.

Why a WebSocket works here but fails in your app

The same network can pass this check and still break another WebSocket. These are the usual reasons; the check cannot tell them apart.

• A proxy or load balancer in front of your server drops the Upgrade and Connection headers, so the handshake never completes.
• Corporate TLS inspection or a firewall allows HTTPS but blocks wss://, or blocks every port except 443.
• An idle timeout on a proxy or load balancer closes quiet connections; the client then sees code 1006 with no close frame.
• A browser extension, VPN, or DNS override routes your application's hostname differently from netokay.net.

If this check passes and your application fails, continue with WebSocket connection failed: what to check.

WebSocket test FAQ

Does this test my own WebSocket server?

No. It only reaches NetOkay's echo endpoint. To check your server's HTTP reachability from NetOkay, use the website and API check; to compare this browser with your terminal, use Compare environments.

What does close code 1006 mean?

Code 1006 means the connection ended without a close frame. Browsers report it for any abrupt end: a dropped TCP connection, a proxy timeout, or a crashed server. It does not say which. See the WebSocket close codes reference.

Is the message stored?

The challenge is a random string generated by this page, echoed back, and discarded. The NetOkay Worker has no storage binding, so message content is not persisted; see Privacy.