HTTP 200, но Bitrix24 не работает: что проверить после переноса через restore.php

На новой BitrixVM после restore.php зелёная главная ещё не рабочий портал: как сверить сессии, поднять Push Server и починить WebSocket в nginx.

Перенесли коробочный Bitrix24 на новую BitrixVM через restore.php. Главная открывается, HTTP 200, страницы отдаются. Люди не входят, чат и уведомления молчат, в браузере — «Отсутствует соединение с сервером» и WebSocket connection failed.

Снаружи всё выглядит живым. Внутри уже лежат авторизация и realtime. HTTP 200 по главной — не полный рабочий Bitrix24. Ниже — три уровня одной миграции: Memcached в .settings.php → конфиги Push Server → маршрутизация /bitrix/subws/ в nginx.

Речь про коробочный Bitrix24 на BitrixVM, не про витрину CMS «1С-Битрикс: Управление сайтом» — стек и точки контроля другие.

Как проявляется проблема

Типичный сценарий: новая VM → обновления → reboot → restore.php → ожидание конца восстановления. После этого одновременно:

RuntimeException: Could not start session by PHP;
не стартовал Push Server;
в UI — «Отсутствует соединение с сервером»;
в консоли — WebSocket connection failed;
часть пользователей не могла войти.

ICMP, доступный TCP-порт и ответ главной подтверждают лишь отдельные уровни доступности. Они не гарантируют вход, сессии и realtime. Состояние degraded — не то же самое, что down.

Обычно дело не в самом скрипте восстановления, а в инфраструктурных настройках, перенесённых со старого окружения: host Memcached/Redis, Push, DNS-имена. Скрипт их не сверяет с новой VM и не поднимает сервисы за вас.

Что делает restore.php — и чего не делает

Официально restore.php с 1c-bitrix.ru — способ переноса и восстановления, когда нет админки или меняется хостинг: файл в корень сайта, открыть /restore.php, владелец — пользователь bitrix. Восстанавливает файлы, БД и настройки приложения.

Не проверяет memcached/redis, push-server и nginx-location под WebSocket на новой машине и не переписывает host’ы под неё. После успеха локальную копию и служебные скрипты нужно удалить из docroot. То же для отдельного queue-сервера Push.

Смежный угол: после восстановления возможны сбои входа при AD/LDAP или OTP. В рассматриваемом разборе основной причиной проблем со входом оказалось хранилище сессий в Memcached, а причиной сбоя realtime — контур Push/WebSocket.

Перед любыми правками сохраните копии .settings.php, конфигов nginx и Push. После правок nginx:

nginx -t
# затем reload

Сессии: старый host в .settings.php

Почему старый адрес Memcached ломает авторизацию

В восстановленном bitrix/.settings.php в блоках cache и session часто остаётся host старой VM. Здесь — имя вроде bitrix_test на порту 11211; на новой машине такого хоста нет.

PHP при этом «живой». Падает старт сессии из‑за недоступного memcache-handler.

По курсу Bitrix24 про session storage ядро поддерживает handlers file / redis / memcache / database. Для memcache типично host => 127.0.0.1, port => 11211 (или список servers). На проде host может быть другим DNS/IP, вместо memcache — Redis: смотреть свой блок.

systemctl enable memcached
systemctl start memcached
ss -lntp | grep 11211

После host → 127.0.0.1 ошибка сессий ушла, но UI про соединение с сервером ещё молчал — дальше смотрим Push.

Push Server: шаблоны conf вместо рабочих json

Как связаны шаблоны conf Push Server и MODULE_NOT_FOUND

После входа осталось «Отсутствует соединение с сервером».

systemctl status push-server
journalctl -u push-server -n 100

Error: Cannot find module '/etc/push-server/push-server-sub-8015.json' (MODULE_NOT_FOUND);
в /etc/push-server лежали только шаблоны push-server-pub-1005PORT.json / push-server-sub-1006PORT.json — рабочих json не было.

Путь к утилите зависит от поставки BitrixVM. Сначала найдите бинарник, затем генерируйте конфиги:

command -v push-server-multi
# часто /usr/bin/push-server-multi или /usr/local/bin/push-server-multi
push-server-multi configs

В официальной документации встречаются отдельные вызовы configs pub / configs sub. Результат — рабочие json в /etc/push-server/.

По официальной схеме Push-server: nginx проксирует /bitrix/sub и /bitrix/subws на node (порты sub 8010–8015); pub — с 127.0.0.1:8895 на pub 9010–9011. В /etc/sysconfig/push-server-multi задаются SECURITY_KEY, USER/GROUP, RUN_DIR; тот же ключ — в настройках модуля Push and Pull.

Юнит уже был active, а сообщение в UI не исчезло. Поднять systemd — ещё не конец: проверяем nginx.

WebSocket: /bitrix/subws/ уходит в PHP

Почему /bitrix/subws/ ошибочно попадает в PHP

Сюрприз разбора: запрос к /bitrix/subws/ вернул страницу авторизации Bitrix, а не ответ Push. Location WebSocket не отрабатывал — запрос ушёл в PHP.

curl -sI https://server/bitrix/subws/

Обычный curl не выполняет полноценный WebSocket-handshake, но ловит грубую ошибку маршрутизации: эндпоинт не должен отдавать HTML логина Bitrix. Для полной проверки — DevTools (Console) или специализированный клиент вроде websocat, если известны endpoint и параметры.

В nginx у location ^~ /bitrix/subws/ директивы оказались закомментированы; на новой VM уже нет старого модуля nginx-push-stream. Цепочка: Push работает → запрос в nginx → location не обрабатывается → PHP → страница логина → WebSocket connection failed.

Современный контур по докам: nginx проксирует sub/subws на NodeJS Push, а не через push_stream_subscriber. Старые include’ы с push_stream_* на свежей BitrixVM без модуля — ложный «как будто настроен» location. Не смешивать legacy nginx-push-stream и Push server 2.0.

Что проверить после restore

Уровень	Что проверить	Признак проблемы
Сервисы	nginx, httpd, БД, Memcached/Redis, push-server	сервис не запущен или перезапускается
Сессии	блоки cache и session в `bitrix/.settings.php`	указан host старой VM
Порты	`ss -lntp`	нужный сервис не слушает порт
Push	рабочие JSON в `/etc/push-server/`	есть только шаблоны `*PORT.json`
WebSocket	`/bitrix/subws/`	возвращается HTML-страница Bitrix
Модуль Push and Pull	адреса WSS/HTTPS и signature key	ключи или адреса не совпадают

В админке модуля (если чинили сервер): Restore defaults, Use local server / BitrixVA 7.3+ (Push server 2.0), HTTPS/WSS URL и signature key из json в /etc/push-server/ — по официальному курсу, без раздувания в полную установку с нуля. Отдельный queue: см. курс Push 2.0 на отдельном сервере.

Типичные ошибки

Считать миграцию успешной по факту открытия главной.
Чинить «PHP сломан», не глядя в host memcache/redis в .settings.php.
Поднять push-server и не проверить nginx location для /bitrix/subws/.
Оставить только шаблоны *PORT.json без генерации рабочих конфигов.
Тащить конфиг nginx-push-stream на VM, где модуля уже нет.
Оставить restore.php в корне сайта после успеха.

Частые вопросы

Почему после restore.php главная открывается, а войти в Bitrix24 нельзя?

Часто в bitrix/.settings.php остаётся host Memcached или Redis со старой VM. PHP жив, но session handler не достучится до хранилища — получаете ошибку старта сессии. Сверьте host/port с сервисом на новой машине.

Push Server в status active, а в UI всё ещё «нет соединения с сервером». Это нормально?

Да, так бывает. Юнит мог подняться, но в /etc/push-server лежат только шаблоны *PORT.json, либо nginx не проксирует /bitrix/subws/ на node. Проверьте рабочие json и location WebSocket, а не только systemd.

Достаточно ли curl к /bitrix/subws/, чтобы проверить WebSocket?

Обычный curl не делает полный WebSocket-handshake. Он полезен как быстрый тест маршрутизации: эндпоинт не должен отдавать HTML страницы входа Bitrix. Полную проверку смотрите в DevTools или специализированным клиентом.

Нужно ли удалять restore.php после успешного переноса?

Да. Оставлять скрипт в docroot небезопасно. После восстановления удалите локальную копию и служебные файлы восстановления.

Итог

После миграции смотрите цепочку целиком: PHP-сессии → Memcached/Redis → Push Server → nginx → WebSocket. Если любой участок недоступен, коробочный Bitrix24 может отдавать страницы и при этом оставаться фактически нерабочим.

Внешняя доступность и внутренний снимок сервисов — разные слои. Такой подход мы закладываем в BX Pulse.

BX Pulse
Мониторинг и диагностика сайтов на 1С-Битрикс и коробочных порталов Битрикс24.
Заявка на ранний доступ

Источники:

Почему после восстановления Bitrix24 через restore.php перестают работать сессии, Push и WebSocket (Хабр, 07.08.2026)
Почему «живой» мониторинг врёт: deep healthcheck для Bitrix (Хабр, 03.08.2026)
Восстановление из резервной копии (курс 1С-Битрикс)
Session storage в .settings.php
Конфигурация Push-server
Отдельный queue Push 2.0
Скрипт restore.php (download 1c-bitrix.ru)