Why this connects directly, with no server in the middle

Unlike the DNS/WHOIS/ping-style tools on this site, a WebSocket connection opened here goes straight from your browser to the endpoint you enter — this site's server is never involved. That's possible because, unlike raw DNS resolution or ICMP, WebSocket is a protocol browsers are allowed to speak natively, so there's no sandbox restriction to work around with a backend proxy. The practical consequence is that this tool can only reach endpoints that are actually reachable from your own network and browser — an internal service on a private network your browser can't route to will fail here for the same reason it would fail in any other browser tab, not because of anything wrong with the tool.

The wss:// vs ws:// restriction isn't optional

Browsers enforce mixed-content rules for WebSockets the same way they do for regular HTTP requests: a page loaded over HTTPS (which this site is) can only open secure wss:// connections, never plain ws://. This isn't a limitation specific to this tool — it's the same restriction that would apply in any script running on any HTTPS page. If the endpoint you're testing only supports plain ws://, testing it from this page isn't possible; it would need to be tested from a page served over plain HTTP, or with a local script that isn't subject to browser mixed-content policy.