WSS a través de Squid no és el mateix que una actualització WebSocket simple
Separeu els WebSocket xifrats dins de CONNECT del tractament d'HTTP Upgrade en text pla en un proxy directe.
Squid veu una sol·licitud HTTP Upgrade o només un túnel que transporta trànsit xifrat? Això determina si els seus controls d'HTTP Upgrade aborden la fallada.
| Camí ordinari de proxy explícit | Què troba Squid |
|---|---|
wss:// | Normalment CONNECT, seguit del TLS de destinació que porta l'handshake de WebSocket |
ws:// | Una sol·licitud HTTP Upgrade en text pla que el proxy pot processar |
El control d'actualització de Squid afecta les sol·licituds que processa. No revela les capçaleres HTTP xifrades dins d'un túnel WSS opac ordinari. La intercepció TLS o un altre tractament especial del proxy canvia la visibilitat i pot introduir requisits de compatibilitat propis.
Per a WSS, trobeu on s'atura la seqüència: connexió al proxy, CONNECT acceptat, TLS verificat, i després l'handshake de l'aplicació. Un rebuig abans del TLS és una fallada diferent d'una sol·licitud Upgrade en text pla denegada.
Si cal un canvi de política d'actualització, feu servir la directiva per a la versió de Squid instal·lada i permeteu específicament el comportament necessari. Permetre tots els protocols d'actualització amplia la política més enllà de l'aplicació concreta.
Una sol·licitud correcta d'una pàgina HTTPS només estableix part del camí. El trànsit WebSocket de llarga durada encara pot fallar per requisits de l'aplicació, durada de la connexió o restriccions d'intermediaris, fins i tot amb el mateix nom d'amfitrió.