WSS a través de Squid no es lo mismo que una actualización WebSocket simple
Separe los WebSocket cifrados dentro de CONNECT del tratamiento de HTTP Upgrade en texto plano en un proxy directo.
¿Squid ve una solicitud HTTP Upgrade o solo un túnel que transporta tráfico cifrado? Eso determina si sus controles de HTTP Upgrade abordan el fallo.
| Ruta ordinaria de proxy explícito | Con qué se encuentra Squid |
|---|---|
wss:// | Normalmente CONNECT, seguido del TLS de destino que transporta el handshake de WebSocket |
ws:// | Una solicitud HTTP Upgrade en texto plano que el proxy puede procesar |
El control de actualización de Squid afecta a las solicitudes que procesa. No revela las cabeceras HTTP cifradas dentro de un túnel WSS opaco ordinario. La interceptación TLS u otro tratamiento especial del proxy cambia la visibilidad y puede introducir sus propios requisitos de compatibilidad.
Para WSS, encuentre dónde se detiene la secuencia: conexión al proxy, CONNECT aceptado, TLS verificado, luego el handshake de la aplicación. Un rechazo antes del TLS es un fallo distinto de una solicitud Upgrade en texto plano denegada.
Si se necesita un cambio de política de actualización, use la directiva para la versión de Squid instalada y permita específicamente el comportamiento requerido. Permitir todos los protocolos de actualización amplía la política más allá de la aplicación concreta.
Una solicitud correcta de una página HTTPS establece solo parte del camino. El tráfico WebSocket de larga duración aún puede fallar por requisitos de la aplicación, duración de la conexión o restricciones de intermediarios, incluso con el mismo nombre de host.