На главную

Резервный канал HTTP

Если сеть блокирует WebSocket, чат автоматически продолжает работать через обычный HTTPS: когда это происходит, как включить этот режим принудительно, что нужно настроить в CSP и прокси и как устранить неполадки.

Обычно виджет подключается к серверу чата через WebSocket. В некоторых сетях это запрещено. Для таких случаев предусмотрен резервный канал HTTP: чат продолжает работать через обычные HTTPS-запросы, а вам и вашим посетителям ничего не нужно делать.

Что такое резервный канал HTTP

Подключение через WebSocket обычно не удаётся:

в корпоративных сетях, где прокси или межсетевой экран пропускает только обычные HTTP(S)-запросы;
у хостинг-провайдеров, CDN или балансировщиков нагрузки, которые не передают WebSocket;
за обратным прокси, который не передаёт заголовки Upgrade и Connection.

В резервном режиме HTTP виджет получает сообщения сервера через Server-Sent Events (длительный HTTPS-поток). Если по этому потоку ничего не поступает, он переключается на длинный опрос. Для отправки используется HTTPS POST. Оба способа передают те же сообщения, что и WebSocket: посетители пишут, получают ответы ИИ-ассистента и операторов, а несколько открытых вкладок, как обычно, используют одно подключение. Вложения в любом случае загружаются по HTTPS и от типа подключения не зависят.

Резервный режим применяется к виджету чата на вашем сайте. Интерфейс операторов по-прежнему подключается через WebSocket.

Когда он включается

Виджет использует резервный канал HTTP, если

браузер не поддерживает WebSocket;
две попытки подключения через WebSocket подряд завершаются неудачей; попытка, которая за 8 секунд не привела ни к подключению, ни к отказу, тоже считается неудачной;
вы включили этот режим принудительно (см. ниже).

Переключение происходит только до первого успешного WebSocket-подключения на странице. Если уже установленное подключение WebSocket обрывается, например из-за смены сети, виджет снова подключается через WebSocket.

После включения резервного режима виджет остаётся в нём на этой странице. Чтобы на следующих страницах не тратить время ещё на две попытки, он запоминает переключение: страницы, открытые в той же вкладке в течение 30 минут, сразу подключаются по HTTPS. При этом на каждой странице виджет один раз в фоне проверяет, доступен ли теперь WebSocket. Если да, следующая страница снова использует WebSocket, а текущая остаётся на резервном канале HTTP.

Принудительное включение резервного режима

Для тестов или сред, в которых WebSocket заведомо не работает, можно включить резервный канал HTTP с самого начала. Проще всего добавить атрибут data-rc-transport="http" к тегу скрипта виджета:

<script src="https://cdn.reactive.chat/loader.js"
        data-rc-site-key="SITE_KEY"
        data-rc-transport="http"
        async></script>

Виджет ищет этот атрибут во всём документе, поэтому он работает и на другом элементе, если тот уже присутствует в документе при запуске виджета.

Другой вариант — задать параметр в JavaScript перед тегом скрипта виджета:

<script>
  window.ReactiveChatSettings = { transport: 'http' };
</script>
<script src="https://cdn.reactive.chat/loader.js"
        data-rc-site-key="SITE_KEY"
        async></script>

Более поздний вызов ReactiveChat('boot', { transport: 'http' }) на это не влияет: тип подключения определяется при запуске виджета.

Content Security Policy

Server-Sent Events, длинный опрос и отправка используют тот же адрес, что и подключение чата, но с https:// вместо wss://. Если на вашем сайте задана Content Security Policy, директива connect-src должна разрешать обе формы:

connect-src 'self' wss://ws.reactive.chat https://ws.reactive.chat

Офлайн-форма и загрузка файлов тоже используют https:// в адресе. При работе через собственный домен здесь указываются адреса вашего поддомена:

connect-src 'self' wss://chat.your-domain.com https://chat.your-domain.com

Остальные директивы политики остаются без изменений. Другие необходимые разрешения описаны в разделе Встраивание виджета.

При работе через собственный домен

Если чат работает через поддомен вашего сайта, резервный канал HTTP использует тот же путь /rc_wss/, что и WebSocket. Дополнительный путь в прокси не нужен, но ответы по этому пути должны передаваться без буферизации:

nginx: proxy_buffering off и proxy_cache off в разделе /rc_wss/;
Apache: в строке ProxyPass для /rc_wss/ укажите flushpackets=on;
Caddy: в reverse_proxy для /rc_wss/ укажите flush_interval -1.

Шаблоны на странице аккаунта и в руководстве по собственному домену уже содержат эти настройки. Если вы использовали старую конфигурацию, сравните её с текущим шаблоном.

Что хранится в браузере

После успешного подключения по HTTPS виджет создаёт запись rc_http в sessionStorage браузера. Она содержит только время этого подключения, без персональных данных. Благодаря ей следующие страницы в течение 30 минут сразу используют резервный канал HTTP; как только WebSocket снова становится доступен, виджет удаляет запись. Как и любая запись sessionStorage, она исчезает не позднее закрытия вкладки. Если sessionStorage недоступно, например в некоторых приватных окнах, каждая страница снова начинает с WebSocket.

Какой способ подключения активен

Откройте инструменты разработчика в браузере и перейдите на вкладку «Сеть»:

WebSocket: есть подключение типа WebSocket к wss://ws.reactive.chat/rc_wss/ (при собственном домене — к вашему поддомену).
Резервный канал HTTP: есть запросы к https://ws.reactive.chat/rc_wss/h/… — сначала h/auf, затем длительный поток по адресу …/sse (при длинном опросе — повторяющиеся запросы к …/poll) и по одному запросу к …/tx на каждое отправленное сообщение.

В разделе «Приложение» или «Хранилище» также можно проверить наличие записи rc_http.

Устранение неполадок

Content Security Policy блокирует адрес https

Если в connect-src указан только адрес wss://, браузер блокирует запросы резервного канала. В консоли браузера появляется сообщение CSP об адресе https://…/rc_wss/h/auf. Там, где WebSocket доступен, вы ничего не заметите, но в сетях без WebSocket подключение вообще не установится. Добавьте https:// в адрес, как показано выше.

Прокси буферизует ответы

Если промежуточный прокси буферизует поток, события Server-Sent Events приходят с задержкой, пачками или не приходят вовсе. Виджет ждёт первое сообщение по потоку 5 секунд, а затем переключается на длинный опрос. Чат работает и так, но установление подключения занимает на несколько секунд больше. При собственном домене отключите буферизацию для /rc_wss/ (см. выше).

Длительные запросы обрываются

При длинном опросе сервер держит запрос открытым до 25 секунд, если сообщать нечего. По открытому потоку он отправляет сигнал поддержания соединения каждые 15 секунд. Межсетевые экраны или прокси, обрывающие запросы раньше, заставляют виджет часто переподключаться. Разрешите запросам к адресу чата длиться не менее 30 секунд.

Чат вообще не подключается

Если не работают ни WebSocket, ни резервный канал HTTP, виджет продолжает попытки в фоне. Проверьте, доступен ли вообще адрес чата по HTTPS из сети посетителей и не блокирует ли его Content Security Policy или фильтр.

Подробнее в документации

Подробное описание: Транспорт: WebSocket, резервный канал HTTP и повторное подключение. Все главы собраны в документации.

Обновлено: 2026-10-25