WSS преку Squid не е исто како обично надградување на WebSocket
Одделете ги шифрираните WebSocket во CONNECT од обработката на обичен HTTP Upgrade во напреден прокси.
Дали Squid гледа барање HTTP Upgrade или само тунел што носи шифриран сообраќај? Тоа одредува дали неговите контроли за HTTP Upgrade го решаваат дефектот.
| Обична патека преку експлицитно прокси | Со што се среќава Squid |
|---|---|
wss:// | Обично CONNECT, потоа TLS на одредиштето што го носи ракувањето на WebSocket |
ws:// | Обично барање HTTP Upgrade што проксито може да го обработи |
Контролата за надградување на Squid се однесува на барањата што ги обработува. Таа не ги открива шифрираните HTTP заглавија во обичен непроѕирен WSS тунел. Пресретнувањето на TLS или друга специјална обработка во проксито ја менува видливоста и може да донесе сопствени барања за компатибилност.
За WSS, пронајдете каде запира низата: поврзување со проксито, прифатен CONNECT, проверен TLS, потоа ракувањето на апликацијата. Одбивање пред TLS е различен дефект од одбиено обично барање Upgrade.
Ако е потребна промена на политиката за надградување, користете ја директивата за инсталираната верзија на Squid и конкретно дозволете го потребното однесување. Дозволувањето на сите протоколи за надградување ја проширува политиката надвор од конкретната апликација.
Успешното барање на HTTPS страница воспоставува само дел од патеката. Долготрајниот WebSocket сообраќај сè уште може да не успее поради барања на апликацијата, времетраење на врската или ограничувања на посредници, дури и за истото име на домаќин.