Как писали ранее данные порты и адреса должны быть открыты и доступны: порты: 443 TCP, 1935 TCP, 1935 UDP, 19350-19360 UDP, 8000-48000 UDP. адреса: 38.122.236.126, 149.11.34.27, 149.11.44.91, 62.152.58.99, 62.152.58.100. порты 3478, 30000-40001 UDP на адрес: turn.calls.bitrix24.com
В файлах конфигурации php есть код подпись. Файлы конфигурации располагаются по адресу /etc/push-server. Нужно скопировать ее в настройки модуля php на сайте. Настройки модуля P&P доступны по ссылке: https://ВАШДОМЕН/bitrix/admin/settings.php?lang=ru&mid=pull&mid_menu=1 Ищите в нес строку «Код-подпись для взаимодействия с сервером» и вставляете туда то, что было в строке в файлах.
в консоли выскакивает предупреждение Запрос из постороннего источника заблокирован: Политика одного источника запрещает чтение удаленного ресурса на http://127.0.0.1/bitrix/sub/?CHANNEL_ID=e1795eb21a0790300add096ca7a8665f/e7a19ec62bbec61b10a5623beb0.... (Причина: отсутствует заголовок CORS «Access-Control-Allow-Origin»).[Подробнее] а потом и ошибка Firefox не может установить соединение с сервером ws://127.0.0.1/bitrix/subws/?CHANNEL_ID=e1795eb21a0790300add096ca7a8665f/e7a19ec62bbec61b10a5623beb00d512&tag=1&time=Fri,%2018%20Mar%202022%2019:00:00%20GMT.
Да, причем ошибка ошибка всплывает каждые 10-11 минут: ========= PULL INFO =========== time: Wed Oct 17 2018 10:09:03 GMT+0500 time: Wed Oct 17 2018 10:19:25 GMT+0500 time: Wed Oct 17 2018 10:25:02 GMT+0500 time: Wed Oct 17 2018 10:35:07 GMT+0500 time: Wed Oct 17 2018 10:45:46 GMT+0500 time: Wed Oct 17 2018 10:56:04 GMT+0500 это чего сервер ложит?
Так как по гуглению [site:1c-bitrix.ru WebSocket 1006] в мировом разуем только эта страница, наречем ее мини базой знаний
У нас Bitrix Push server (aka NodeJS) тоже работал с этой ошибкой. Все привело к тому, что нужно правильно настраивать гейтвей, если виртуальная машина битрикс живет за NAT-ом. В нашем случае nginx. Чтобы работал WebSocket, настраиваем правильную секцию upgrade ( https://nginx.org/en/docs/http/websocket.html). Проверять можно по Chrome-у, он должен зацепить в network-секции средств разработчика WS соединение и показывать, что на запрос ответ получен и соединение живо.Был тайм-аут, который в нашем случае крутился вокруг 75 секунд. Это подозрительно совпадает с дефалтовым keepalive_timeout у nginx-а (http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout), но увеличение явно не помогло. Но зато помог proxy_read_timeout, при этом если его поставить скажем 300 секунд (5 минут), то видно, что код страницы стучится домой (на сервер) где-то раз в четыре минуты, поэтому 5 минут никогда не иссякают.
Лучше бы конечно документация упоминала особенности связанные с житием за гейтвеем и NAT-ом.
поставил последние обновления, все заработало.... больше ошибки нет! тайну сию мы так никогда и не узнаем, вряд ли разрабы сюда косяки выложат )))))))))))))
При переходе с Nginx-PushStreamModule на NodeJS-PushServer, эта проблема связана с настройками модуля Push and Pull. При установке Nginx-PushStreamModule настройки выставляются правильно. Путь для публикации команд: http://127.0.0.1:8895/bitrix/pub/ А при установке NodeJS-PushServer путь для публикации команд меняется на http://domain.ru:8895/bitrix/pub/ Нужно поменять в настройках на http://127.0.0.1:8895/bitrix/pub/ и соединение с сервером будет нормальным.
Подпись. Та же проблема с Nginx-PushStreamModule Постоянно появляются сообщения "Отсутствует соединение с сервером", все зависает. Через несколько секунд восстанавливается связь "Соединение с сервером установлено"
Уже устали разбираться. 1. Порты проверили 2. Увеличили память доступную для p&p модуля в /etc/nginx/bx/conf/im_settings.conf 3. Авто продление сессии отключили
Временное решение проблемы: удалить папку /tmp/php_session/ext_www/"ваш домен", если сайт установлен по дефолтному пути (/home/bitrix/www), то папку /tmp/php_session/www. После этого перезагрузить службы или сразу сервер. Обычно помогает на несколько дней.
UPD: Это лишнее, сейчас иногда просто перезагружаю push сервер, пока ищу решение проблемы. systemctl restart push-server
У нас проблема была в том, что слетела синхронизация с LDAP. Сообщение об ошибке один в один такое же. Исправили параметры синхронизации - все заработало.
Подскажите, пожалуйста, что именно правили? У нас, похоже, такая же ситуация.
Модуль выдаёт в терминале ошибку доступа для типа пользователей "LDAP#1".
Если данная проблема появилась на корпоративном портале и выше описанные варианты вы уже сделали, а проблема осталась, то стоит сотруднику с такой проблемой задать "Подразделение". Такая вот у битрикса логика. ¯\_(ツ)_/¯
написал: Если данная проблема появилась на корпоративном портале и выше описанные варианты вы уже сделали, а проблема осталась, то стоит сотруднику с такой проблемой задать "Подразделение". Такая вот у битрикса логика. ¯\_(ツ)_/¯
Заработало! Это просто :facepalm какой-то - какая может быть связь между включением сотрудника в подразделение и ошибкой сервера? Откуда растут руки у того разраба, кто так придумал...