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 усе одно може збоїти через вимоги застосунку, час життя з'єднання або обмеження посередників, навіть для того самого імені хоста.