WSS via Squid är inte samma sak som en vanlig WebSocket-uppgradering
Skilj krypterade WebSockets i CONNECT från hantering av vanlig HTTP Upgrade i en vidarebefordrande proxy.
Ser Squid en HTTP Upgrade-begäran, eller bara en tunnel som bär krypterad trafik? Det avgör om dess HTTP Upgrade-kontroller åtgärdar felet.
| Vanlig väg via explicit proxy | Vad Squid möter |
|---|---|
wss:// | Vanligtvis CONNECT, följt av målets TLS som bär WebSocket-handskakningen |
ws:// | En vanlig HTTP Upgrade-begäran som proxyn kan bearbeta |
Squids uppgraderingskontroll gäller begäranden som den bearbetar. Den avslöjar inte krypterade HTTP-huvuden i en vanlig ogenomskinlig WSS-tunnel. TLS-avlyssning eller annan särskild proxyhantering ändrar synligheten och kan medföra egna kompatibilitetskrav.
För WSS, ta reda på var sekvensen stannar: anslutning till proxyn, accepterad CONNECT, verifierad TLS, sedan applikationens handskakning. Ett avslag före TLS är ett annat fel än en avvisad vanlig Upgrade-begäran.
Om en ändring av uppgraderingspolicyn behövs, använd direktivet för den installerade Squid-versionen och tillåt det nödvändiga beteendet specifikt. Att tillåta alla uppgraderingsprotokoll vidgar policyn bortom den aktuella applikationen.
En lyckad HTTPS-sidbegäran etablerar bara en del av vägen. Långvarig WebSocket-trafik kan fortfarande misslyckas på grund av applikationskrav, anslutningens livslängd eller begränsningar hos mellanhänder, även för samma värdnamn.