Діагностика та усунення помилок 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, що спрощує откат.