I came across this stackoverflow question & then to this article through that question.
From what I understand, both encrypted / non-encrypted websocket connections are dependent on the proxy servers sending across the proper header/s.
From the article on unencrypted websocket connections
In case the unencrypted WebSocket traffic flows through a transparent proxy on its way to the WebSocket server, the connection is likely to fail in practice, since the browser does not >issue the CONNECT method in this case. When a proxy server forwards a request to the >(WebSocket) server, it is expected to strip off certain headers, including the Connection >header. Therefore, a well-behaved transparent proxy server will cause the WebSocket >upgrade >handshake to fail almost immediately.
Not all proxy servers conform to the HTTP standard regarding expected proxy behavior. For example, some proxy servers are configured not to remove the Connection: Upgrade header and pass it on to the WebSocket server, which in turn sends the 101 Web Socket Protocol Handshake response. Problems then arise when the client or the server starts sending the first WebSocket frame. Since the frame does not resemble anything the proxy server might expect (such as regular HTTP traffic), some exception will likely occur, unless the proxy server is specifically configured to handle WebSocket traffic.
On encrypted web socket connections
In the case of transparent proxy servers, the browser is unaware of the proxy server, so no HTTP CONNECT method is sent. However, since the wire traffic is encrypted, intermediate transparent proxy servers may simply allow the encrypted traffic through, so there is a much better chance that the WebSocket connection will succeed if Web Sockets Secure is used.
If unencrypted connections are expected to fail & encrypted connections only have a better chance of success, how does it even work?!!
I have most likely got this whole thing wrong, but am curious to understand how this works.
In an encrypted connection, proxies doesn’t see the HTTP-content so they simply pass the messages through. But in a non-encrypted connection HTTP-messages (e.g. headers) may be inspected and changed (in some cases) by the Proxies, so in some cases they need to have support for WebSockets as WebSocket-messages doesn’t look like HTTP-messages (e.g. no HTTP-headers).