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