WSS über Squid ist nicht dasselbe wie ein normales WebSocket-Upgrade
Trennen Sie verschlüsselte WebSockets in CONNECT von der Behandlung einfacher HTTP-Upgrades in einem Forward-Proxy.
Sieht Squid eine HTTP-Upgrade-Anfrage oder nur einen Tunnel mit verschlüsseltem Datenverkehr? Das entscheidet, ob seine HTTP-Upgrade-Steuerung den Fehler adressiert.
| Üblicher Pfad über expliziten Proxy | Womit Squid konfrontiert wird |
|---|---|
wss:// | Üblicherweise CONNECT, gefolgt vom TLS des Ziels, das den WebSocket-Handshake trägt |
ws:// | Eine einfache HTTP-Upgrade-Anfrage, die der Proxy verarbeiten kann |
Die Upgrade-Steuerung von Squid betrifft Anfragen, die er verarbeitet. Sie legt verschlüsselte HTTP-Header in einem gewöhnlichen undurchsichtigen WSS-Tunnel nicht offen. TLS-Interception oder eine andere besondere Proxy-Behandlung verändert die Sichtbarkeit und kann eigene Kompatibilitätsanforderungen mitbringen.
Suchen Sie bei WSS, wo die Abfolge abbricht: Verbindung zum Proxy, akzeptiertes CONNECT, verifiziertes TLS, dann der Handshake der Anwendung. Eine Ablehnung vor TLS ist ein anderer Fehler als eine abgelehnte einfache Upgrade-Anfrage.
Wenn eine Änderung der Upgrade-Richtlinie nötig ist, verwenden Sie die Direktive für die installierte Squid-Version und erlauben Sie das erforderliche Verhalten gezielt. Alle Upgrade-Protokolle zu erlauben, erweitert die Richtlinie über die betreffende Anwendung hinaus.
Eine erfolgreiche HTTPS-Seitenanfrage belegt nur einen Teil des Weges. Langlebiger WebSocket-Verkehr kann dennoch an Anwendungsanforderungen, Verbindungslebensdauer oder Einschränkungen von Zwischenstellen scheitern, selbst bei demselben Hostnamen.