На головну

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

Якщо мережа блокує WebSocket, чат автоматично продовжує працювати через звичайний HTTPS: умови переходу, примусове ввімкнення, Content Security Policy, проксі та усунення несправностей.

Зазвичай віджет підключається до сервера чату через 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: flushpackets=on у рядку ProxyPass для /rc_wss/,
Caddy: flush_interval -1 у reverse_proxy для /rc_wss/.

Шаблони на сторінці облікового запису та в посібнику з власного домену уже містять ці налаштування. Якщо ви скопіювали старішу конфігурацію, порівняйте її з поточним шаблоном.

Що зберігається в браузері

Після успішного підключення через 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