Архивная заметка описывала портал в UTF‑8, который при восстановлении сообщал, что конфигурация сервера не соответствует требованиям. Сегодня при переносе коробочного Bitrix24 нужно проверить не только кодировку, но и параметры инфраструктуры, возвращённые вместе с проектом.

Как выглядела исходная проблема

Старый мастер восстановления требовал значения mbstring.func_overload=2 и mbstring.internal_encoding=UTF-8. В заметке предлагалось открыть /bitrix/php_interface/dbconn.php и закомментировать строку:

define("BX_UTF", true);
Не повторяйте это решение автоматически.Если база и файлы действительно находятся в UTF‑8, отключение BX_UTF может замаскировать причину и привести к повреждённым строкам, поиску и обменам.

Что проверять перед восстановлением

  1. Кодировку базы данных, дампа и файлов исходного проекта.
  2. Наличие define('BX_UTF', true) в исходной конфигурации.
  3. Фактически загруженный php.ini и дополнительные ini‑файлы.
  4. Версии PHP, ядра 1С‑Битрикс и скрипта восстановления.
  5. Результат проверки системы в административной панели.

Работайте на копии и сохраняйте исходный архив. Если ошибка появляется только в старом restore.php, сначала получите актуальный скрипт восстановления и сопоставьте требования с версией продукта.

Что изменилось в современных версиях PHP

Директивы mbstring.func_overload и mbstring.internal_encoding устарели, а затем были удалены из PHP. Поэтому инструкция 2018 года применима только к историческим окружениям.

Для современного переноса правильнее подготовить совместимое UTF‑8‑окружение, обновить ядро на поддерживаемой версии PHP и сохранить согласованность базы, файлов и BX_UTF. Если портал старый, безопаснее сначала восстановить его в совместимом временном окружении, обновить и только потом переносить дальше.

Ошибка Could not start session by PHP

После восстановления вместе с файлами и базой возвращается .settings.php. В нём могут остаться адреса Memcached или Redis из старой инфраструктуры. PHP работает, но Bitrix пытается хранить сессии на узле, которого в новом окружении уже нет.

Проверьте секции cache и session:

grep -A20 "'cache'" /home/bitrix/www/bitrix/.settings.php
grep -A20 "'session'" /home/bitrix/www/bitrix/.settings.php

Если указан старый внутренний хост, сопоставьте конфигурацию с новой схемой. Для локального Memcached это часто 127.0.0.1:11211, но менять адрес вслепую нельзя: сначала убедитесь, где сервис должен работать.

systemctl status memcached
ss -lntp | grep 11211
restore.php не адаптирует инфраструктуру. Он возвращает настройки приложения, но не знает, какие DNS‑имена, кеши и сервисы доступны на новом сервере.

Почему не работают Push и WebSocket

После устранения ошибки сессий отдельно проверьте Push Server. В конфигурации могут сохраниться старый адрес, порт, сертификат или внутреннее имя. В браузере это проявляется сообщением «Отсутствует соединение с сервером» и ошибками WebSocket connection failed.

  1. Проверьте состояние push‑сервиса и его журналы.
  2. Сопоставьте публичное имя портала с настройками HTTPS и WebSocket.
  3. Проверьте reverse proxy в Nginx и доступность нужного порта.
  4. Откройте консоль браузера и исключите ошибки сертификата и mixed content.
  5. Очищайте кеш после проверки конфигурации: кеш не исправит неверный адрес сервиса.

Чек‑лист после восстановления Bitrix24

systemctl status nginx
systemctl status httpd
systemctl status mysql
systemctl status memcached
systemctl status push-server

ss -lntp

Дополнительно проверьте PHP‑сессии, права на файлы, подключение к базе, cron‑задачи, почту, доменные имена, сертификаты, агенты, очередь уведомлений и тест Web Push. Затем выполните проверку системы в административной панели.

Главный принцип: сначала найти настройку старого окружения, которая больше не соответствует новой инфраструктуре, и только затем менять конфигурацию. Так восстановление остаётся воспроизводимым, а исправления — объяснимыми.