WebSocket устанавливает двусторонний и постоянно открытый канал между браузером и сервером. Панели с данными в реальном времени, чат-приложения и мгновенные уведомления используют эту технологию. Будет ли она работать через прокси, зависит от типа прокси и его конфигурации.
Как начинается WebSocket?
WebSocket не является отдельным протоколом; он начинается с HTTP-запроса и Upgrade меняет протокол с помощью этого механизма:
После ответа 101 соединение перестаёт быть HTTP, и начинают передаваться кадры WebSocket. Поэтому каждый промежуточный уровень должен понимать upgrade.
Поведение в зависимости от типа прокси
Самая надёжная комбинация wss:// + туннель CONNECT. Поскольку трафик шифрован, прокси не может вмешаться в содержимое и нарушить upgrade.
Если вы собираетесь запускать приложение с WebSocket через прокси, отдавайте предпочтение wss:// (шифрованному). Туннель прокси передаёт только байты, поэтому он вообще не вмешивается в процесс upgrade, и проблема совместимости исчезает.
Почему некоторые прокси всё ломают?
В обычном ws:// трафике прокси читает запрос. Устаревшие или жёстко настроенные прокси могут допускать следующие ошибки:
Последнюю строку часто упускают из виду: если вы используете ротируемые прокси, соединение WebSocket обрывается при смене IP. В этом сценарии статический IP — он обязателен.
Как избежать обрывов: ping/pong
Прокси и промежуточные маршрутизаторы закрывают соединения, по которым долго не идут данные. Протокол WebSocket предусматривает для этого кадры ping/pong. Большинство библиотек делают это автоматически, но интервал может потребоваться настроить:
Держите интервал ping короче тайм-аута простоя прокси. 20–25 секунд — безопасное значение для большинства конфигураций.
WebSocket через SOCKS5
Поскольку SOCKS5 вообще не анализирует данные приложения, он естественным образом передаёт WebSocket. Upgrade-рукопожатие, смена протокола и поток кадров — всё это для SOCKS5 просто поток байтов. Это делает SOCKS5 самым надёжным вариантом в сценариях с WebSocket.
Об общем поведении SOCKS5 см. как работает SOCKS5 смотрите нашу статью.
Долгоживущие соединения и стабильность IP
WebSocket по своей природе долгоживущий, а ротация стремится менять IP. Эти два подхода конфликтуют. В таком сценарии нужен статический IP или очень длительный срок sticky-сессии.
Стратегия переподключения
Если вы используете WebSocket через прокси, считайте обрыв не исключением, а ожидаемой ситуацией:
- Экспоненциальная задержка: нарастающее ожидание вида 1, 2, 4, 8 секунд.
- Добавьте jitter: Предотвращает одновременное возвращение множества клиентов, отключившихся в один момент.
- Синхронизация состояния: после переподключения запрашивайте пропущенные сообщения.
- Ограничение числа попыток: не уходите в бесконечный цикл; уведомите пользователя.
- Следите за состоянием соединения: если частота обрывов растёт, пересмотрите конфигурацию прокси.
Резюме
WebSocket начинается с механизма HTTP upgrade, поэтому промежуточные уровни должны понимать смену протокола. wss:// (шифрованный) и выбор туннеля CONNECT либо SOCKS5 в значительной мере устраняют проблемы совместимости. Долгоживущие соединения конфликтуют с ротируемыми прокси; в этом сценарии нужен статический IP. Держите интервал ping/pong короче тайм-аута прокси и продумайте надёжную стратегию переподключения. Варианты со статическим IP см. ISP-прокси смотрите на нашей странице.