WSS a través de Squid non é o mesmo ca unha actualización WebSocket simple
Separe os WebSocket cifrados dentro de CONNECT do tratamento de HTTP Upgrade en texto claro nun proxy directo.
Squid ve unha solicitude HTTP Upgrade ou só un túnel que transporta tráfico cifrado? Iso determina se os seus controis HTTP Upgrade abordan o fallo.
| Ruta habitual de proxy explícito | Con que se atopa Squid |
|---|---|
wss:// | Normalmente CONNECT, seguido do TLS de destino que transporta o handshake de WebSocket |
ws:// | Unha solicitude HTTP Upgrade en texto claro que o proxy pode procesar |
O control de actualización de Squid afecta as solicitudes que procesa. Non revela as cabeceiras HTTP cifradas dentro dun túnel WSS opaco habitual. A interceptación TLS ou outro tratamento especial do proxy cambia a visibilidade e pode introducir os seus propios requisitos de compatibilidade.
Para WSS, atope onde se detén a secuencia: conexión ao proxy, CONNECT aceptado, TLS verificado, despois o handshake da aplicación. Un rexeitamento antes de TLS é un fallo distinto dunha solicitude Upgrade en texto claro denegada.
Se fai falta un cambio de política de actualización, use a directiva para a versión de Squid instalada e permita especificamente o comportamento necesario. Permitir todos os protocolos de actualización amplía a política máis aló da aplicación concreta.
Unha solicitude correcta dunha páxina HTTPS só establece parte do camiño. O tráfico WebSocket de longa duración aínda pode fallar por requisitos da aplicación, duración da conexión ou restricións de intermediarios, mesmo co mesmo nome de host.