Диагностика и устранение ошибок 500 на 1С-Битрикс

Диагностика и устранение ошибок 500 на 1С-Битрикс

HTTP 500 — Internal Server Error — означает, что сервер не смог обработать запрос, но не сообщает почему. В контексте Битрикс это самый частый и самый раздражающий тип сбоя: пользователь видит стандартную страницу ошибки, а в админке может не быть ни одной записи. Причина в том, что 500-я ошибка возникает до того, как Битрикс успевает инициализировать свою систему логирования. Разберём, где искать реальную причину и как её устранять.

Почему Битрикс молчит при 500

Цепочка инициализации Битрикс: index.php → header.php → /bitrix/modules/main/include/prolog_before.php → подключение БД → инициализация модулей → обработка URL → вызов компонентов. Если PHP-процесс падает на любом этапе до инициализации exception_handling из .settings.php, Битрикс не может записать ошибку в свой журнал. Остаётся только лог веб-сервера и PHP.

Алгоритм диагностики

Шаг 1. Найдите лог ошибки.

Проверяйте в следующем порядке:

1. PHP error log — путь определяется директивой error_log в php.ini или конфиге пула php-fpm. Типичные расположения: /var/log/php-fpm/www-error.log, /var/log/php/error.log.
2. Лог веб-сервера — для nginx: /var/log/nginx/error.log, для Apache: /var/log/apache2/error.log или /var/log/httpd/error_log.
3. Битрикс-лог — /bitrix/modules/main/tools/log.txt (если настроен) и журнал событий в БД.

Если все три лога пусты — PHP-процесс убивается OOM-killer'ом или segfault'ом. Проверяйте /var/log/syslog или dmesg на предмет записей Out of memory: Kill process или segfault.

Шаг 2. Определите, какой URL вызывает ошибку.

500-я может быть глобальной (все страницы) или локальной (конкретный раздел). Это сразу сужает область поиска:

Шаг 3. Воспроизведите с включённым дебагом.

Временно добавьте в начало index.php (до подключения Битрикс):

ini_set('display_errors', 1);
error_reporting(E_ALL);

Или создайте отдельный тестовый файл test500.php с минимальным подключением ядра:

require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';
echo 'Kernel loaded';

Если этот файл выдаёт 500 — проблема в ядре или конфигурации. Если работает — проблема в конкретном шаблоне или компоненте.

Основные причины и решения

1. Исчерпание memory_limit.

Самая частая причина. Битрикс потребляет 128-256 МБ на типичной странице каталога. Массовые операции (импорт, построение поискового индекса) могут требовать 512 МБ и более.

Симптом в логе: Allowed memory size of N bytes exhausted. Решение: увеличить memory_limit в php.ini или .htaccess до 256M-512M. Если потребление аномально высокое — профилируйте через xdebug или Blackfire: возможна утечка памяти в цикле обработки элементов инфоблока.

2. Ошибки в init.php и dbconn.php.

Файл /bitrix/php_interface/init.php подключается при каждом хите. Синтаксическая ошибка или Fatal Error в нём роняет весь сайт. Аналогично dbconn.php (устаревший, но часто модифицируемый файл с параметрами подключения к БД).

Проверка: переименуйте init.php в init.php.bak. Если сайт заработал — ошибка в нём. Восстановите файл и ищите проблемную строку через бинарный поиск: комментируйте половину кода, проверяйте, сужайте.

3. Конфликт .htaccess.

Битрикс создаёт .htaccess в корне и в /bitrix/. Директивы php_value, php_flag вызывают 500, если PHP работает через php-fpm (не как модуль Apache). Также ошибка возникает при mod_rewrite с некорректными правилами.

Проверка: временно переименуйте .htaccess. Если заработало — проблема в директивах. Уберите php_value/php_flag и перенесите настройки в php.ini или конфиг пула.

4. Падение 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, или мигрировать на сервер с достаточной памятью.

5. Ошибки в компонентах и шаблонах.

Если 500 возникает на конкретной странице — проблема в компоненте. Типичные причины:

• result_modifier.php вызывает несуществующий метод после обновления модуля
• Шаблон компонента обращается к $arResult['PROPERTIES']['DELETED_PROP']
• Компонент использует CIBlockElement::GetList() с некорректным фильтром, вызывающим MySQL-ошибку

Для изоляции: замените содержимое шаблона компонента на <?php print_r($arResult);?>. Если страница заработала — ошибка в шаблоне.

Превентивные меры

• Настройте 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, что упрощает откат.