WSS Through Squid Is Not the Same as a Plain WebSocket Upgrade
Separate encrypted WebSockets inside CONNECT from plaintext HTTP Upgrade handling in a forward proxy.
Does Squid see an HTTP Upgrade request, or only a tunnel carrying encrypted traffic? That determines whether its HTTP Upgrade controls address the failure.
| Ordinary explicit-proxy path | What Squid encounters |
|---|---|
wss:// | Typically CONNECT, followed by destination TLS carrying the WebSocket handshake |
ws:// | A plaintext HTTP Upgrade request the proxy can process |
Squid's upgrade control concerns requests it processes. It does not reveal encrypted HTTP headers inside an ordinary opaque WSS tunnel. TLS interception or other special proxy handling changes visibility and can introduce its own compatibility requirements.
For WSS, find where the sequence stops: connection to the proxy, accepted CONNECT, verified TLS, then the application handshake. A rejection before TLS is a different failure from a denied plaintext Upgrade request.
If an upgrade policy change is needed, use the directive for the installed Squid release and permit the required behavior specifically. Allowing every upgrade protocol broadens policy beyond the particular application.
A successful HTTPS page request establishes only part of the path. Long-lived WebSocket traffic can still fail on application requirements, connection lifetimes or intermediary restrictions even for the same hostname.