Практическое руководство экспертов Солар для администраторов коробочной версии Bitrix24
Срочно! Ошибка 500 или «белый экран» в Битрикс24 после обновления — пошаговый план восстановления за 20 минут
Наше руководство: как быстро вернуть портал к жизни без потери данных
Понедельник, 9:15 утра. Администратор только что нажал «Обновить» в админке, и теперь вместо портала — белый экран или «Error 500 Internal Server Error». В корпоративном чате уже падают сообщения: «CRM не работает!», «Битрикс лежит?», «Когда починят?».
Знакомая ситуация? Мы сталкиваемся с этим регулярно в нашей практике сопровождения. Хорошая новость: в 90% случаев наша команда решает проблему за 10–20 минут стандартными методами. Данные клиента никуда не деваются — они лежат в базе и ждут, когда причина сбоя будет устранена. В этой статье мы делимся своим пошаговым чек-листом — тем самым, который используем при экстренных вызовах.
Проверьте у себя — если:
- Сайт показывает чистый белый экран
- Появилось сообщение «500 Internal Server Error»
- CRM зависает или не грузится полностью
- Проблема началась сразу после обновления ядра или модулей
Эта инструкция для вас. Мы поможем разобраться.
Важно: В этой инструкции мы говорим о Битрикс24 Коробка (self-hosted). Для облачной версии большинство действий недоступно — в таких случаях мы рекомендуем сразу обращаться в техподдержку Битрикс24.
Наше золотое правило: сначала защитите данные
Портал уже не работает, но ситуацию можно усугубить. Поэтому перед любыми манипуляциями наша команда всегда фиксирует текущее состояние.
Делаем бэкап вместе:
- Файлы: Архивируем корневую папку сайта через панель хостинга или командой
tar -czvf backup_site.tar.gz /путь/к/сайту - База данных: Выполняем дамп через phpMyAdmin или командой
mysqldump -u пользователь -p имя_базы > backup_db.sql
Бэкап готов? Отлично. Теперь можно работать спокойно.
ЧАСТЬ 1: Наша методика быстрой диагностики (5 минут)
Прежде чем чинить, нужно понять причину. Белый экран — симптом, а не диагноз.
Шаг 1: Проверяем свободное место на диске
В нашей практике переполненный диск — одна из самых частых причин ошибки 500. Особенно после обновления, которое скачивает файлы.
df -h
Видим 100% на разделе с сайтом? Вот она, причина. Наши инженеры обычно делают так:
# Удаляем старые логи (предварительно проверив их) find /var/log -type f -name "*.log" -mtime +30 -delete # Очищаем временные файлы PHP rm -rf /tmp/php* # Ищем, что занимает больше всего места du -sh /* | sort -rh | head -20Освободили 1–2 ГБ? Пробуем открыть сайт. Не помогло — идём дальше.
Шаг 2: Включаем режим отладки
Белый экран — это PHP, который молча умирает. Мы заставляем его говорить. Редактируем файл /bitrix/.settings.php.
Находим или добавляем секцию exception_handling:
'exception_handling' => [ 'value' => [ 'debug' => true, // ВКЛЮЧАЕМ ОТЛАДКУ 'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_STRICT & ~E_USER_NOTICE, 'ignore_silence' => false, 'log' => ['settings' => ['file' => '/var/log/bitrix/error.log']], ], 'readonly' => false, ],Обновляем страницу. Теперь вместо белого экрана должна появиться конкретная ошибка.
Шаг 3: Изучаем логи
Даже если режим отладки не показал ошибку, она где-то записалась. Мы проверяем:
# Логи веб-сервера tail -100 /var/log/nginx/error.log tail -100 /var/log/apache2/error.log # Логи PHP tail -100 /var/log/php8.1-fpm.log # Логи Битрикс tail -100 /bitrix/modules/main/classes/general/error_log.txtНа что мы обращаем внимание:
| Ошибка в логах | Что это означает | Как мы решаем |
|---|---|---|
Fatal error
|
Критическая ошибка PHP | Ищем проблемный файл или модуль |
Class not found
|
Не загрузился модуль | Проверяем целостность модулей |
Permission denied
|
Проблемы с правами | Корректируем права доступа |
memory exhausted
|
Нехватка оперативной памяти | Увеличиваем memory_limit в PHP |
ЧАСТЬ 2: Наш пошаговый план восстановления (15 минут)
Теперь чиним. Порядок важен — от безопасного к более рискованному.
Шаг 4: Очистка кэша «грубой силой»
В нашей практике это решает 40% проблем. После обновления в кэше остаются старые данные, которые конфликтуют с новым кодом.
# Очищаем кэш через SSH rm -rf /bitrix/cache/* rm -rf /bitrix/managed_cache/* rm -rf /bitrix/stack_cache/* rm -rf /bitrix/html_pages/*Примечание: Удаляем только содержимое папок, не сами папки.
Шаг 5: Проверяем целостность ядра
Иногда обновление прерывается. Проверяем версию в /bitrix/modules/main/install/version.php. Если что-то не так, перезаписываем ядро из официального дистрибутива.
Шаг 6: Отключаем сторонние модули
Кастомный модуль может конфликтовать с обновлённым ядром. Мы переименовываем папку модуля:
mv /bitrix/modules/custom.module /bitrix/modules/custom.module.DISABLEDНаш метод поиска виновника:
- Отключаем ВСЕ нестандартные модули
- Если сайт заработал — включаем модули по одному, пока ошибка не вернётся
- Можно использовать бинарный поиск: отключаем половину, потом ещё половину
Шаг 7: Проверяем права на файлы и папки
Неправильные права — частая причина после обновления. Мы выставляем стандартные:
# Стандартные права для Битрикс find /путь/к/сайту -type d -exec chmod 755 {} \; find /путь/к/сайту -type f -exec chmod 644 {} \; chown -R www-data:www-data /путь/к/сайтуШаг 8: Проверяем версию PHP
Хостер мог обновить PHP. Проверяем совместимость:
- Битрикс24 последних версий: PHP 8.1–8.2 (рекомендуем)
- Старые версии могут требовать PHP 7.4
Проверяем версию в панели хостинга и при необходимости откатываемся на стабильную.
Шаг 9: Проверяем .htaccess (для Apache)
Одна ошибка в .htaccess — и сайт падает. Временно отключаем:
mv /путь/к/сайту/.htaccess /путь/к/сайту/.htaccess.backup
Если сайт заработал — проблема в этом файле. Восстанавливаем стандартный .htaccess из дистрибутива.
ЧАСТЬ 3: Если ничего не помогло (крайние меры)
Прошли все шаги, но сайт не работает? Время для крайних мер.
Восстановление из резервной копии
Если есть бэкап, сделанный до обновления — это самый надёжный способ.
# Восстанавливаем файлы tar -xzvf backup_site.tar.gz -C / # Восстанавливаем базу данных mysql -u пользователь -p имя_базы < backup_db.sqlКогда мы рекомендуем обращаться к нам или в техподдержку:
- Вы прошли все шаги и ничего не помогло
- Ошибка связана с лицензией
- Вы не уверены в своих действиях
Что подготовить для обращения:
- Скриншот ошибки
- Лог-файлы (error.log, php_error.log)
- Версию Битрикс и PHP
- Список действий, которые уже предприняли
Наша памятка на будущее
Большинство проблем решается двумя действиями: очистка кэша и включение режима отладки.
Чтобы не оказаться в такой ситуации снова, мы рекомендуем:
| Что сделать | Как мы это делаем для клиентов | Результат |
|---|---|---|
| Бэкап перед обновлением | Настраиваем автоматические скрипты | Возможность отката за 5 минут |
| Тестовое окружение | Разворачиваем копию сайта на поддомене | Безопасная проверка обновлений |
| Мониторинг места на диске | Настраиваем алерты при заполнении >80% | Предупреждение до сбоя |
| Актуальные модули | Проводим регулярный аудит совместимости | Снижение риска конфликтов |
Резюме от нашей команды
Ошибка 500 после обновления — не приговор, а стандартная ситуация, с которой мы регулярно работаем.
Наш алгоритм на 90% случаев:
- Включаем режим отладки (
debug => true) - Очищаем кэш в папках
/bitrix/cache/,/managed_cache/ - Проверяем логи на наличие конкретной ошибки
После восстановления мы всегда:
- Отключаем режим отладки на продакшене
- Восстанавливаем оптимальные настройки кэширования
- Анализируем причину сбоя, чтобы избежать её в будущем
Спокойствие и последовательность — главные союзники в решении любой технической проблемы. Если у вас остались вопросы или нужна помощь — наша команда экспертов всегда готова помочь.
Нужна профессиональная помощь с Битрикс24? Наши инженеры с опытом от 5 лет готовы провести диагностику, восстановить работоспособность или взять вашу CRM на полное сопровождение.
Статья подготовлена экспертами компании Солар — Золотого партнёра 1С-Битрикс24 с 2018 года.