A WSS Squiden keresztül nem ugyanaz, mint egy egyszerű WebSocket-frissítés
Válassza szét a CONNECT-en belüli titkosított WebSocketeket a sima HTTP Upgrade kezelésétől egy forward proxyban.
HTTP Upgrade kérést lát a Squid, vagy csak egy titkosított forgalmat hordozó alagutat? Ez dönti el, hogy a HTTP Upgrade vezérlői kezelik-e a hibát.
| Szokásos explicit proxy útvonal | Mivel találkozik a Squid |
|---|---|
wss:// | Általában CONNECT, majd a cél TLS, amely a WebSocket kézfogást hordozza |
ws:// | Sima HTTP Upgrade kérés, amelyet a proxy feldolgozhat |
A Squid frissítésvezérlése az általa feldolgozott kérésekre vonatkozik. Nem tárja fel a titkosított HTTP fejléceket egy szokásos átlátszatlan WSS-alagútban. A TLS-elfogás vagy más különleges proxykezelés megváltoztatja a láthatóságot, és saját kompatibilitási követelményeket hozhat.
WSS esetén keresse meg, hol áll meg a sorrend: kapcsolódás a proxyhoz, elfogadott CONNECT, ellenőrzött TLS, majd az alkalmazás kézfogása. A TLS előtti elutasítás más hiba, mint egy elutasított sima Upgrade kérés.
Ha a frissítési szabályzat módosítása szükséges, használja a telepített Squid-verzió direktíváját, és kifejezetten engedélyezze a szükséges viselkedést. Az összes frissítési protokoll engedélyezése a szabályzatot az adott alkalmazáson túlra tágítja.
Egy sikeres HTTPS-oldalkérés csak az útvonal egy részét igazolja. A hosszú életű WebSocket-forgalom továbbra is meghiúsulhat az alkalmazás követelményei, a kapcsolat élettartama vagy a köztes felek korlátozásai miatt, még ugyanazon hosztnév esetén is.