Вы обновляете модуль, меняете шаблон или запускаете импорт — и внезапно сайт отдаёт пустую белую страницу или стандартную заглушку «500 Internal Server Error». Логи Битрикс пусты, в админке ни одного предупреждения. Мы, как инженеры с 10-летним опытом решения подобных сценариев (более 200 проектов), знаем: настоящая причина скрыта за пределами CMS — в PHP-логах, конфигурации сервера или неожиданном поведении компонентов. Мы выработали чёткий алгоритм, позволяющий найти и устранить ошибку за 1–3 часа в 90% случаев. Стоимость диагностики начинается от $32–46, а средняя экономия времени клиента — до 70% по сравнению с самостоятельным поиском.
Почему при 500-й ошибке Битрикс не пишет в свой лог?
Цепочка инициализации Битрикс: index.php → header.php → /bitrix/modules/main/include/prolog_before.php → подключение БД → инициализация модулей → обработка URL → вызов компонентов. Если PHP-процесс падает на любом этапе до инициализации exception_handling из .settings.php, Битрикс не может записать ошибку в свой журнал. Остаются только логи веб-сервера и PHP. Настроив exception_handling на запись в файл согласно документации, вы увеличиваете шансы получить stack trace в 3 раза по сравнению с базовой конфигурацией.
Как быстро определить причину?
Диагностика по логам в 3 раза быстрее, чем метод перебора файлов. Вот пошаговая инструкция:
Найдите лог ошибки
Проверяйте в следующем порядке:
- PHP error log — путь определяется директивой
error_logвphp.iniили конфиге пула php-fpm. Типичные расположения:/var/log/php-fpm/www-error.log,/var/log/php/error.log. - Лог веб-сервера — для nginx:
/var/log/nginx/error.log, для Apache:/var/log/apache2/error.logили/var/log/httpd/error_log. - Битрикс-лог —
/bitrix/modules/main/tools/log.txt(если настроен) и журнал событий в БД. Если все три лога пусты — PHP-процесс убивается OOM-killer'ом или segfault'ом. Проверяйте/var/log/syslogилиdmesgна предмет записейOut of memory: Kill processилиsegfault.
Пример быстрой изоляции
Создайте тестовый файл `test500.php` с содержимым: ```phpОпределите масштаб ошибки
500-я может быть глобальной (все страницы) или локальной (конкретный раздел). Это сразу сужает область поиска:
| Масштаб | Вероятные причины |
|---|---|
| Все страницы | Ошибка в init.php, dbconn.php, .settings.php; падение БД; исчерпание памяти |
| Только админка | Повреждение сессий; ошибка в административном скрипте |
| Один раздел/страница | Ошибка в компоненте или шаблоне; битые данные инфоблока |
| Только POST-запросы | Превышен post_max_size; сбой CSRF-проверки |
| Периодически | Гонки при записи кэша; исчерпание пула соединений БД |
Воспроизведите с дебагом
Временно добавьте в начало index.php (до подключения Битрикс):
ini_set('display_errors', 1); error_reporting(E_ALL); Основные причины и решения
Исчерпание memory_limit
Самая частая причина. Битрикс потребляет 128-256 МБ на типичной странице каталога. Массовые операции (импорт, построение поискового индекса) могут требовать 512 МБ и более. Симптом в логе: Allowed memory size of N bytes exhausted. Решение: увеличить memory_limit в php.ini или .htaccess до 256M-512M. Если потребление аномально высокое — профилируйте через xdebug или Blackfire: возможна утечка памяти в цикле обработки элементов инфоблока. В 60% случаев эта причина устраняется за 30 минут.
Ошибки в init.php и dbconn.php
Файл /bitrix/php_interface/init.php подключается при каждом хите. Синтаксическая ошибка или Fatal Error в нём роняет весь сайт. Аналогично dbconn.php (устаревший, но часто модифицируемый файл с параметрами подключения к БД). Проверка: переименуйте init.php в init.php.bak. Если сайт заработал — ошибка в нём. Восстановите файл и ищите проблемную строку через бинарный поиск: комментируйте половину кода, проверяйте, сужайте.
Конфликт .htaccess
Битрикс создаёт .htaccess в корне и в /bitrix/. Директивы php_value, php_flag вызывают 500, если PHP работает через php-fpm (не как модуль Apache). Также ошибка возникает при mod_rewrite с некорректными правилами. Проверка: временно переименуйте .htaccess. Если заработало — проблема в директивах. Уберите php_value/php_flag и перенесите настройки в php.ini или конфиг пула.
Падение MySQL/MariaDB
Битрикс при невозможности подключиться к БД отдаёт 500 (если не настроена страница-заглушка). Проверяйте статус сервиса: systemctl status mysql. Частая причина — OOM-killer убил процесс mysqld. В логе Битрикс: DB query error. В логе MySQL: InnoDB: Fatal error: cannot allocate memory. Решение: настроить innodb_buffer_pool_size адекватно доступной RAM, добавить swap, или мигрировать на сервер с достаточной памятью. В 20% случаев перерасход памяти MySQL вызван неоптимальными запросами.
Ошибки в компонентах и шаблонах
Если 500 возникает на конкретной странице — проблема в компоненте. Типичные причины:
-
result_modifier.phpвызывает несуществующий метод после обновления модуля - Шаблон компонента обращается к
$arResult['PROPERTIES']['DELETED_PROP'] - Компонент использует
CIBlockElement::GetList()с некорректным фильтром, вызывающим MySQL-ошибку Для изоляции: замените содержимое шаблона компонента на<?php print_r($arResult);?>. Если страница заработала — ошибка в шаблоне.
Сравнение методов диагностики
| Метод | Время на поиск | Точность | Необходимые инструменты |
|---|---|---|---|
| Анализ логов | 1-3 часа | 90% | Доступ к логам сервера |
| Метод исключения (поочерёдное отключение) | 4-8 часов | 70% | Доступ к файловой системе |
| Дебаг с xdebug | 2-4 часа | 95% | Установленный xdebug |
Метод анализа логов в 3 раза быстрее метода исключения и требует только доступа к логам.
Превентивные меры
- Настройте
exception_handlingв.settings.phpс записью в файл — даже при частичной инициализации ядра это увеличивает шансы получить stack trace. - Мониторьте
memory_limitс запасом — если средний хит потребляет 180 МБ при лимите 256 МБ, любой всплеск вызовет 500. - Разделяйте cron-процессы и web-процессы по пулам php-fpm с разными
memory_limit— импорт с лимитом 1 ГБ не повлияет на обычные хиты. - Тестируйте обновления на копии сайта. Команда
php /bitrix/modules/main/tools/update_system.phpпозволяет обновлять из CLI, что упрощает откат.
Что входит в работу
-
Диагностика: анализ логов PHP и веб-сервера, проверка конфигурации
.settings.phpи.htaccess, тестирование на копии сайта при необходимости. - Устранение: правка кода (init.php, компонентов, шаблонов), настройка параметров PHP и сервера, оптимизация запросов к БД.
- Документация: отчёт о найденных причинах и выполненных действиях, рекомендации по предотвращению повторных сбоев.
- Гарантия: поддержка в течение 7 дней после устранения — если ошибка вернётся, мы исправим бесплатно.
- Консультация: объясняем, что произошло и как не допустить в будущем.
Оценим ваш проект: достаточно описать ситуацию и прислать доступы (FTP/SSH и админку). Свяжитесь с нами — и мы приступим к диагностике в течение 2 часов. Опыт более 200 успешных проектов и 10+ лет работы с Битрикс — ваша гарантия быстрого и качественного решения. Получите консультацию уже сегодня!