Ошибки при обновлении 1С-Битрикс и как их исправить

Обновление 1С-Битрикс ломается в 3 местах: обновления не скачиваются, установка обрывается на середине или сайт падает после успешной установки. Разбор кодов ошибок с причинами и порядком действий, сводная таблица и критерии, когда откатываться, а когда доводить до конца.

Обновление 1С-Битрикс ломается в 3 разных местах, и это принципиально разные поломки. Либо обновления не скачиваются вообще, и вы видите код ошибки на странице обновлений. Либо пакет скачался, установка пошла и оборвалась на середине. Либо все установилось без единого предупреждения, а сайт отдает белый экран.

Лечатся эти 3 случая по-разному, и первое, что нужно сделать при любой ошибке, — понять, на какой из стадий вы находитесь. Дальше в статье разобраны конкретные коды и сообщения: [110] Connection timed out, [SITE_LICENSE_VIOLATION], [ERROR_WRONG_CODE], Class 'CUpdateExpertMode' not found, требование удалить mbstring.func_overload, обрыв на апдейтере, фатальные ошибки после установки. Для каждой — причина и порядок действий.

Сразу оговорка, которая экономит время: подавляющая часть «ошибок обновления» на живых проектах вообще не в обновлении. Обновление просто вскрывает то, что было сломано раньше: правки в ядре, мертвый хостинг, PHP пятилетней давности. Поэтому в каждом разделе есть проверка, отделяющая одно от другого.

Сначала определите стадию обновления

Система обновлений работает в 4 такта: проверяет лицензию на сервере обновлений, скачивает архивы с изменениями, распаковывает их и выполняет апдейтеры, копирует файлы в ядро. Сообщение об ошибке нужно читать вместе с тактом, на котором оно появилось.

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

Что сделать до того, как искать текст ошибки

Порядок, который снимает половину бесполезных попыток:

1. Запишите точный текст ошибки целиком. Код в квадратных скобках, номер строки, путь к файлу. Не пересказ, а дословно: по обрывку «не удалось обновить» диагноз поставить нельзя.
2. Зафиксируйте текущую версию ядра. Она видна на странице обновлений в блоке ответа сервера. Пригодится и для отката, и для обращения в поддержку вендора.
3. Проверьте, есть ли рабочая резервная копия. Именно рабочая: файл архива, который вы открывали. Резервное копирование живет в «Настройки → Инструменты → Резервное копирование».
4. Загляните в журнал событий и в лог веб-сервера. Журнал событий в админке ловит фатальные ошибки PHP, лог хостинга — обрывы по памяти и таймауту.
5. Включите вывод ошибок на время работ. Белый экран без текста диагностировать невозможно. Отладочный режим включается в настройках главного модуля, на продакшене его потом обязательно выключить.

Пятый пункт пропускают чаще всего, а он самый полезный. Белый экран — это не отсутствие ошибки, это отключенный вывод ошибки.

Обновления не скачиваются: сервер не может выйти наружу

Самое частое сообщение этой группы вендор описывает дословно: «Ошибка соединения с сервером обновлений: [110] Connection timed out». Оно означает, что скрипт обновления не смог подключиться к серверу www.1c-bitrix.ru на порт 80. В документации 1С-Битрикс (страница обновлена 06.06.2025) названы 4 причины:

• Недоступны функции работы с сокетами. В первую очередь fsockopen(): ее часто отключают в общих тарифах хостинга через disable_functions.
• На сервере запрещены исходящие соединения к 80 порту. Типичная история для сайтов за корпоративным файрволом или в закрытом контуре.
• Недостаточно памяти на сервере. Вендор отдельно отмечает, что это часто проявляется на VPS с виртуализацией OpenVZ и 256 МБ RAM.
• Проблема в работе сети. Самый скучный вариант: временная недоступность, лечится повторной попыткой через час.

Что делать: первые 3 причины закрывает только администратор сервера или хостинг, своими силами из админки их не обойти. Обращаться нужно с дословным текстом ошибки и указанием адреса и порта — так заявку не отфутболят обратно.

Прежде чем писать хостеру, проверьте одну глупость. В настройках главного модуля есть поле «Имя сервера, содержащего обновления». Правильное значение — www.1c-bitrix.ru. Оно иногда оказывается затертым: кто-то экспериментировал, кто-то восстанавливал сайт из старой копии. Мы в Design Lab смотрим на это поле первым делом, когда сайт достался нам «по наследству» и обновления не работают с неизвестного момента.

Лицензионные коды: сайты, ключ и срок обновлений

Три сообщения, которые выглядят угрожающе, но лечатся из админки за несколько минут.

[SITE_LICENSE_VIOLATION] Превышено количество лицензированных сайтов

Ошибка говорит, что в системе либо не зарегистрировано ни одного сайта, либо все сайты деактивированы, либо активных сайтов больше, чем разрешает лицензия. Решение по документации вендора: зарегистрировать хотя бы 1 сайт, активировать существующий или деактивировать лишние до разрешенного количества. Путь: «Рабочий стол → Настройки → Настройки продукта → Сайты → Список сайтов».

На практике эта ошибка вылезает после переноса сайта или разворачивания копии для разработки, когда в списке сайтов внезапно оказывается 2 активные записи вместо 1. Второй частый сценарий — многосайтовость, которую когда-то настроили под поддомен и забыли.

[ERROR_WRONG_CODE]

Эта ошибка сложнее и пугает сильнее остальных. Система обновлений привязывается к конкретной установке и запоминает состояние системы после каждого обновления. Код появляется, когда текущее состояние не совпадает с тем, что было на момент последнего обновления. Механизм существует затем, чтобы на одном лицензионном ключе нельзя было обновлять неограниченное количество копий продукта.

Правило вендора, которое стоит выписать и повесить над столом: на каждый лицензионный ключ допускаются 2 установки — одна публичная и одна локальная для разработчика, недоступная из интернета. Система хранит данные о 2 установках. Пока вы не таскаете копию с локальной машины на сервер и обратно, обе можно обновлять независимо. Если копию переносите — обновляйте только одну из 2, на свой выбор.

При переезде на новый сервер вендор предписывает тот же порядок: скопировать файлы и базу на новый сервер, продукт на старом больше не обновлять и удалить сразу после переключения DNS. Если этот порядок нарушен, ключ считает, что установок стало больше, и обновления встают. Это, кстати, главный аргумент против привычки держать «на всякий случай» старую копию сайта на старом хостинге еще полгода после переезда. Про сам переезд у нас есть отдельный разбор: план перехода на MySQL 8 задевает ту же тему копий и версий.

Кнопка установки обновлений неактивна

Здесь ошибки как таковой нет, и именно поэтому люди застревают надолго. Вендор описывает 2 причины.

Первая: устарела сама система обновлений. На странице «Marketplace → Обновление платформы» нужно сначала нажать «Обновить систему SiteUpdate», и только после этого кнопка установки станет доступна. Вторая: закончился срок активности обновлений по лицензии.

Со сроком есть важная деталь про деньги. По условиям вендора, в течение 1 месяца после завершения активности обновлений продление покупается по льготному варианту — 22% от цены редакции, и срок продлевается на год с момента окончания предыдущего периода. Если прошло больше месяца, действует стандартный вариант — 60% от цены редакции, год считается от момента активации. Купон льготного продления не применяется, если прошло более 30 дней после окончания обновлений, и льготно продлить ключ можно только 1 раз в год (данные со страницы продления лицензий 1С-Битрикс, август 2026).

Разница между 22% и 60% — это буквально стоимость забытого напоминания в календаре. Проверить состояние ключа можно на странице проверки лицензии.

Часть обновлений в списке отсутствует

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

Сервер не пускает обновление: версии и настройки PHP

Отдельная группа ошибок появляется до всякой установки: продукт сообщает, что обновляться нельзя, пока не приведен в порядок сервер.

Самый известный случай — требование удалить параметр mbstring.func_overload. Продукт выводит уведомление, что для обновления его необходимо убрать, и до этого момента обновления не установятся. Причина в том, что этот механизм PHP объявлен устаревшим начиная с PHP 7.2, и в продуктах 1С-Битрикс его поддержка прекращена. Для виртуальной машины VMBitrix вендор дает точную инструкцию: удалить строку mbstring.func_overload=2 из /etc/php.d/bitrixenv.ini и перезапустить веб-сервер. На обычном хостинге правку вносит администратор сервера или служба поддержки хостинга.

Второй случай — устаревшие версии платформы. По техническим требованиям «1С-Битрикс: Управление сайтом» (актуально на август 2026) продукту нужны PHP 8.2, MySQL 8.0 и выше, PostgreSQL 11 и выше для лицензий уровня Энтерпрайз. Минимальная версия PHP 8.2 для всех продуктов вендора действует с 1 февраля 2026 года. Сайт на PHP 7.4 или MySQL 5.7 либо не получит новые обновления, либо получит их и перестанет работать.

Проверять это лучше инструментом. В админке есть страница «Настройки → Инструменты → Проверка системы» с закладками «Тестирование конфигурации» и «Проверка доступа к диску». Первая гоняет комплексный тест конфигурации сервера: параметры, выделенные красным, обязательны к исправлению, иначе, как пишет вендор, работоспособность сайта не гарантируется. Вторая проверяет права на запись — без них система обновлений просто не сможет заменить файлы ядра, и вы получите обрыв на копировании.

Отдельно есть скрипт bitrix_server_test.php: вендор рекомендует прогонять им хостинг и постоянно обновляет сам скрипт под выявляемые проблемы. Полезно прогнать его на потенциальном хостинге до переезда.

Мое мнение, за которое иногда прилетает: «Проверка системы» с красными строками — достаточная причина отменить обновление на этот вечер и заняться сервером. Обновление поверх несоответствующей конфигурации не станет успешным от вашей решимости.

Class 'CUpdateExpertMode' not found и другие «класс не найден»

Ошибка выглядит так, как ее приводит вендор:

Class 'CUpdateExpertMode' not found (0)
/app/www/bitrix/modules/main/admin/update_system.php:50
#0: require_once /app/www/bitrix/admin/update_system.php:2

Причем сам класс на месте, он определен в /bitrix/modules/main/classes/general/update_client.php. Разгадка не в коде продукта: виноват OPcache. Параметр opcache.validate_timestamps выставлен в 0, а должен быть включен. При нулевом значении PHP не проверяет, изменились ли файлы, и продолжает выполнять закешированный старый байт-код, в котором нового класса еще нет.

Что делать: включить opcache.validate_timestamps в конфигурации PHP (обычно /etc/php.d/opcache.ini) и перезапустить веб-сервер. Если доступа к конфигурации нет, помогает полный сброс OPcache, но это лечение симптома: при следующем обновлении история повторится.

Тот же механизм объясняет целый класс похожих сбоев. После обновления сайт ругается на класс или метод, которого «нет», хотя файл с ним лежит на диске. Причина одна: старый кеш байт-кода. Поэтому в регламент обновления полезно вписать сброс OPcache сразу после установки.

Установка обрывается на середине

Чтобы понимать, что происходит при обрыве, нужно знать про апдейтеры. Апдейтер — это скрипт, который приходит вместе с обновлением модуля и выполняется перед копированием файлов в ядро: он меняет структуру таблиц, переносит настройки, чистит старые данные. По документации вендора у него 3 важных свойства.

• Выполняется на одном хите. Апдейтер запускается один раз, непосредственно перед копированием файлов обновления в ядро. Если хит не доживает до конца, часть работы уже сделана, а часть нет.
• Порядок между модулями не определен. Если за 1 хит обновляются несколько модулей, апдейтеры выполнятся у всех, но межмодульная последовательность не гарантирована. Версии одного модуля идут по порядку версий, а вот кто раньше — магазин или каталог — вопрос без ответа.
• Новый API в апдейтере недоступен. Код, который приходит с этим же обновлением, из апдейтера использовать нельзя: будет ошибка вида Class 'Имя\Класса' not found. При циклических межверсионных зависимостях недоступен API всех этих обновлений.

Отсюда 2 практических вывода. Обрыв на середине установки — еще не катастрофа: при повторном запуске система продолжает с того же места, а апдейтер при этом может выполниться повторно. И обновлять 40 накопившихся версий одним нажатием — плохая идея просто потому, что все они лезут в один хит.

Чем обычно обрывается хит:

1. Таймаут PHP. Апдейтер с ALTER на таблице заказов в миллион строк не укладывается в 30 секунд. Лечится увеличением max_execution_time и обновлением мелкими шагами.
2. Нехватка памяти. Классический Allowed memory size exhausted в логе. Поднимаем memory_limit, повторяем установку.
3. Нет прав на запись в ядро. Файлы не копируются, обновление считает себя незавершенным. Проверяется закладкой «Проверка ядра» на странице проверки системы.
4. Закончилось место на диске. Архивы обновлений распаковываются в /bitrix/updates/, и на забитом диске распаковка падает с ошибкой формата файла.
5. Обрыв соединения на длинной операции. Прокси или балансировщик закрывает запрос раньше, чем сервер закончил работу.

Порядок действий при обрыве: не трогая ничего руками, перезапустить установку обновлений. Если тот же модуль падает на том же месте 2 раза подряд — искать причину в логе веб-сервера. И только после этого лезть в базу.

Обновление прошло, а сайт не открывается

Самая неприятная группа. Обновление отчиталось об успехе, а публичная часть или админка отдают белый экран, ошибку 500 или фатальную ошибку PHP. Здесь важна очередность проверок, потому что паника обычно уводит в сторону.

Шаг 1. Получите текст ошибки. Включите отображение ошибок или откройте лог веб-сервера. Дальше все решает первая строка трейса.

Шаг 2. Посмотрите, чей файл в трейсе. Тут обычно и находится ответ.

• Путь внутри /bitrix/modules/. Если файл ядра кто-то правил руками, обновление затерло правку своей версией — и вместе с ней ту логику, на которой держался сайт. Обратная ситуация тоже бывает: правка сохранилась и конфликтует с новым кодом.
• Путь в /bitrix/php_interface/ или init.php. Обработчики событий, написанные под старый API. После обновления сигнатура изменилась, обработчик падает и роняет вместе с собой весь сайт.
• Путь в /local/ или в шаблоне. Скопированный когда-то шаблон компонента. Компонент в ядре обновился, шаблон остался прежним и обращается к переменной, которой больше нет.
• Путь в /bitrix/modules/ сторонних решений. Решение из Маркетплейса, несовместимое с новой версией ядра.

Шаг 3. Отключите подозреваемого точечно. Обработчик из init.php комментируется за минуту. Модуль сторонней разработки отключается в списке модулей. Скопированный шаблон компонента переключается на системный. Полный откат из резервной копии — тяжелая операция, к ней переходят, когда быстрые способы не сработали.

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

И главное наблюдение по этой группе целиком: ломается не то, что обновилось, а то, что кто-то когда-то поправил в ядре. Правки в /bitrix/modules/ — единственная причина, по которой обновление Битрикса заслуженно считают рискованным. На сайте без таких правок оно скучное и предсказуемое. Если вы не знаете, правили ли ядро на вашем проекте, это выясняется в ходе технического аудита, который делается до обновления.

Сайт работает, но выглядит сломанным

Эта группа выглядит страшнее, чем есть. Верстка разъехалась, кнопки в админке не нажимаются, в консоли браузера ошибки JavaScript, часть страниц отдает старое содержимое. Кода ошибки нет, в логах чисто.

Проверяйте по порядку, от дешевого к дорогому:

1. Кеш компонентов и управляемый кеш. Сбрасывается из админки, в «Настройки → Настройки продукта → Автокеширование». После обновления ядра это первое действие.
2. Композитный сайт. Если композит включен, посетители какое-то время получают статические копии страниц, собранные до обновления. Кеш композита сбрасывается там же, в настройках модуля.
3. Статика в браузере. CSS и JS ядра меняются вместе с версией, а браузер держит старые. Проверяется жестким обновлением страницы и приватным окном.
4. OPcache. Тот же механизм, что в разделе про CUpdateExpertMode. Перезапуск веб-сервера снимает вопрос.
5. CDN и внешний кеш. Если перед сайтом стоит кеширующий слой, старые файлы могут жить в нем.

Если после всех 5 пунктов картина не изменилась, дело в шаблоне: обновление принесло новую версию компонента, чья разметка не совпадает со старыми стилями.

Решения из Маркетплейса после обновления ядра

Сторонние модули обновляются отдельно от ядра и своим темпом. Разработчик решения выпускает совместимую версию тогда, когда выпускает, и на старом сайте легко получить связку из свежего ядра и модуля двухлетней давности.

Симптомы узнаваемые: страница настроек модуля отдает ошибку, компонент решения перестал выводиться, в журнале событий висят однотипные фатальные ошибки с путем внутри папки этого модуля.

Порядок разбора:

• Обновите само решение. В «Marketplace → Установленные решения» видно, есть ли для него новая версия. Часто этого достаточно.
• Проверьте, поддерживается ли решение вообще. Брошенные модули — обычная история. Если последнее обновление было 3 года назад, планируйте замену.
• Отключите модуль и оцените ущерб. Если без него сайт живет, у вас есть время на спокойное решение вместо ночного.
• Напишите разработчику решения. Дословный текст ошибки и версия ядра — все, что ему нужно.

Вывод, который стоит принять заранее: каждое установленное решение — это чужой код в вашем ядре, и он делает обновления сложнее. Ставить их стоит осознанно, а перед обновлением — пересматривать список установленных.

Сводная таблица: что означает и что делать

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

Когда откатываться, а когда доводить до конца

Откат — штатная процедура, ничего постыдного в нем нет. Но применять ее нужно по критериям, иначе вы будете откатываться от каждой мелочи и никогда не обновитесь.

Откатывайтесь, если выполняется хотя бы одно условие:

• сайт полностью недоступен, и причина не найдена за 15 минут;
• сломано оформление заказа или оплата, то есть идет прямая потеря денег;
• апдейтер изменил структуру таблиц и упал, а вы не понимаете, в каком состоянии база;
• ошибка воспроизводится, но трейс уводит в чужой код, который вы не готовы править прямо сейчас.

Доводите до конца, если ошибка локальная: не работает 1 компонент, съехал блок в шаблоне, ругается один модуль. Откат ради косметики обойдется дороже самой косметики, потому что резервная копия не содержит заказов и заявок, пришедших после обновления.

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

Как не встречаться с этим списком

Почти все перечисленное предотвращается регламентом на 1 страницу. У нас в Design Lab он выглядит так и входит в поддержку сайтов на 1С-Битрикс:

1. Проверка системы и требований до обновления, красные строки закрываются заранее.
2. Свежая резервная копия, которую скачали и открыли.
3. Обновление сначала на тестовой копии — той самой второй установке, которую разрешает лицензия.
4. Окно в часы наименьшего трафика с предупреждением ответственных.
5. Обновление шагами, если версий пропущено много.
6. Сброс кешей и OPcache сразу после установки.
7. Короткий смоук-тест: главная, каталог, карточка, корзина, оформление заказа, форма обратной связи, вход в админку.
8. Запись в журнал работ: дата, версии до и после, что сломалось, как чинили.

Восьмой пункт кажется бюрократией ровно до того момента, пока похожая ошибка не повторится через полгода. Тогда журнал экономит вечер.

Регулярность тоже имеет значение. Сайт, который обновляют раз в месяц, ставит несколько обновлений за подход и почти не ломается. Сайт, который не обновляли 2 года, набирает десятки версий, среди которых обязательно окажутся смена требований к PHP и изменение структуры таблиц. Почему это опасно и с точки зрения безопасности, разбирали в материале про обновление 1С-Битрикс и последствия отказа от него.

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

Можно ли обновлять 1С-Битрикс без резервной копии, если обновление мелкое?

Технически можно, и чаще всего ничего не случится. Проблема в том, что мелким обновление выглядит только в списке: апдейтер модуля вполне может изменить структуру таблицы. Стоимость копии — несколько минут, стоимость ее отсутствия — восстановление сайта из того, что осталось. Копия делается в «Настройки → Инструменты → Резервное копирование».

Что делать, если сайт не обновляли 3 года и обновлений накопилось несколько десятков?

Не ставить их одним нажатием. Сначала привести сервер к текущим требованиям: PHP 8.2, MySQL 8.0. Затем развернуть тестовую копию и обновляться на ней шагами, фиксируя, на каком модуле что сломалось. Только после того, как копия обновилась целиком и прошла проверку, повторять сценарий на боевом сайте. Времени это занимает больше, чем один вечер, зато без сюрпризов.

Обновление встало на модуле и не идет дальше. Можно ли пропустить этот модуль?

Если в настройках главного модуля включен экспертный режим, на странице обновлений появляется отдельная закладка, где можно выбрать конкретные модули и версию, до которой обновляться. Это законный способ обойти проблемный модуль и вернуться к нему отдельно. Но связанные модули система выбирает целиком, разорвать связку не получится.

После обновления пропали правки, которые делал прошлый подрядчик. Их можно вернуть?

Если правки были в файлах ядра, обновление их затерло, и вернуть можно только из резервной копии или из системы контроля версий. Правильное решение — перенести логику в /local/, в обработчики событий или в собственный модуль. Возвращать правку в ядро смысла нет: следующее обновление повторит историю. Оценить объем такой переработки помогает расчет стоимости доработок.

Сколько стоит, если обновление сломало сайт и чинить придется не своими силами?

У нас разовые работы считаются по 5000 руб./ч., в абонементе ставка ниже — от 3500 руб./ч. при минимуме 10 ч./мес. Разбор упавшего после обновления сайта обычно укладывается в несколько часов, если есть резервная копия и известен текст ошибки. Дольше и дороже выходит там, где ядро правили руками, а журнала изменений никто не вел.

Ошибки при обновлении 1С-Битрикс редко бывают загадочными: у каждой есть код, причина и описанный вендором способ починки. Тяжелым обновление делает не сама платформа, а накопленная история проекта — правки в ядре, забытые модули и хостинг, который никто не трогал 5 лет. Если ваш сайт из таких, начните с проверки системы и резервной копии. Нужна пара рук на этот вечер — напишите нам, разберемся вместе.