Ви оновлюєте модуль, змінюєте шаблон або запускаєте імпорт — і раптом сайт віддає порожню білу сторінку або стандартну заглушку «500 Internal Server Error». Логи Бітрікс порожні, в адмінці жодного попередження. Ми, як інженери з 10-річним досвідом вирішення подібних сценаріїв (більше 200 проєктів), знаємо: справжня причина прихована за межами CMS — у PHP-логах, конфігурації сервера або неочікуваній поведінці компонентів. Ми виробили чіткий алгоритм, що дозволяє знайти та усунути помилку за 1–3 години в 90% випадків. Вартість діагностики визначається після аналізу, а середня економія часу клієнта — до 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+ років роботи з Бітрікс — ваша гарантія швидкого та якісного рішення. Отримайте консультацію вже сьогодні!