Битрикс · 05.10.2026 · 5 мин чтения

Ошибки 1С-Битрикс: как включить журнал и найти причину

При ошибке в 1С-Битрикс начни с журнала: в нём указаны сообщение, файл и строка. На рабочем сайте подробности лучше записывать в лог, а вывод в браузер включать на тестовой копии.

Ниже — настройка exception_handling, диагностика SQL-запросов и причины частых ошибок 500, 404 и 403.

Перед правкой системных файлов сохрани их копию. Ошибка в .settings.php или dbconn.php положит весь сайт.

Настройка ошибок через exception_handling

Обработку ошибок ядра настраивает раздел exception_handling в файле /bitrix/.settings.php. Он выглядит так:

'exception_handling' => [
    'value' => [
        'debug' => false,
        'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_STRICT & ~E_USER_NOTICE,
        'exception_errors_types' => E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_USER_WARNING & ~E_USER_NOTICE & ~E_COMPILE_WARNING & ~E_DEPRECATED,
        'ignore_silence' => false,
        'assertion_throws_exception' => true,
        'assertion_error_type' => 256,
        'log' => [
            'settings' => [
                'file' => 'bitrix/modules/error.log',
                'log_size' => 1000000,
            ],
        ],
    ],
    'readonly' => false,
],

debug — показывать ли подробности ошибки в браузере: текст, файл, строку и стек вызовов. Значение true подходит только для разработки. На рабочем сайте стек вызовов и пути к файлам увидят все посетители.
handled_errors_types — какие ошибки PHP ядро обрабатывает, exception_errors_types — какие из них превращаются в исключения и останавливают выполнение.
log — запись ошибок в файл. Путь указывается от корня сайта, log_size — максимальный размер файла в байтах. Без этого раздела журнал обработчика не настроен; при этом PHP или веб-сервер могут вести собственный лог.

Если раздела exception_handling в файле нет, добавь его внутрь возвращаемого массива целиком.

Как включить журнал на рабочем сайте

На рабочем сайте используй 'debug' => false и настрой запись в журнал через log. Повтори действие с ошибкой и найди соответствующее время в файле журнала.

Проверь, что лог нельзя скачать по прямому URL. Если он доступен, закрой доступ настройками веб-сервера или используй подходящее защищённое расположение.

Править .settings.php руками не обязательно. Рядом можно создать /bitrix/.settings_extra.php с тем же форматом. Битрикс объединяет его с основным файлом, а основной файл остаётся нетронутым, и временные настройки легко убрать:

<?php
return [
    'exception_handling' => [
        'value' => [
            'debug' => false,
            'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_STRICT & ~E_USER_NOTICE,
            'exception_errors_types' => E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_USER_WARNING & ~E_USER_NOTICE & ~E_COMPILE_WARNING & ~E_DEPRECATED,
            'ignore_silence' => false,
            'assertion_throws_exception' => true,
            'assertion_error_type' => 256,
            'log' => [
                'settings' => [
                    'file' => 'bitrix/modules/error.log',
                    'log_size' => 1000000,
                ],
            ],
        ],
        'readonly' => false,
    ],
];

Диагностика ошибок базы данных

Ошибки SQL-запросов настраиваются в старом файле /bitrix/php_interface/dbconn.php двумя переменными:

$DBDebug = true;        // показывать полный текст ошибок БД в браузере
$DBDebugToFile = false; // писать все запросы в /mysql_debug.sql

С $DBDebug = false полный текст ошибки базы видит только администратор, остальные — общее сообщение. Значение true используй на тестовой копии: подробности SQL-ошибки могут стать видны посетителям.
$DBDebugToFile = true записывает в файл все запросы и время их выполнения. Это инструмент для поиска медленных запросов, а не ошибок. Он заметно замедляет сайт, поэтому включай его на несколько минут.

Запись переменных в лог через Debug::writeToFile

Чтобы понять, что происходит в своём коде, например в обработчике события или шаблоне компонента, выведи значение переменной в файл:

\Bitrix\Main\Diag\Debug::writeToFile(
    ['ID' => $id, 'fields' => $fields],
    'Перед сохранением заказа',
    'local/logs/debug.log'
);

Путь задаётся от корня сайта. Если его не указать, запись попадёт в __bx_log.log в корне. Такие вызовы нужно убирать после отладки, а файлы удалять: в них часто оказываются данные клиентов.

Проверка системы и базы данных

В админке открой «Настройки → Инструменты → Проверка системы». Она помогает найти несовместимые настройки PHP, проблемы веб-сервера и прав на файлы.

Проверка таблиц находится в разделе «Диагностика → Проверка БД». Перед восстановлением таблиц сохрани резервную копию. После переноса сайта сначала выполни диагностику, затем исправляй конкретные найденные проблемы.

Белый экран, 500, 404 и 403: где искать причину

Белый экран или ошибка 500 без сообщения. Ошибка случилась раньше, чем загрузилось ядро, и обработчик Битрикса не успел сработать. Смотри журнал ошибок PHP или веб-сервера в панели хостинга. Частая причина — смена версии PHP: старые версии ядра и модулей не работают на PHP 8.
MySQL query error, Table doesn’t exist. Таблицы нет или у неё другая структура. Обычно так бывает после неполного переноса базы или прерванного обновления. Проверь таблицы на странице «Проверка БД».
404 на существующих страницах. Человекопонятные адреса в Битриксе работают через обработку 404: запрос несуществующего файла попадает в urlrewrite.php, а тот находит нужный компонент по правилам. После переноса на nginx или другой хостинг эта связка часто теряется. Проверь, что веб-сервер передаёт такие запросы в Битрикс, а в файле urlrewrite.php в корне есть правила для нужного раздела. Если раздел новый, проверь ещё настройки ЧПУ у компонента.
«Доступ запрещён» или 403. Права на разделы Битрикс хранит в файлах .access.php. Если файл потерялся при переносе, права могут измениться с учётом наследования от родительских разделов. Ещё причины — права на файлы на сервере или модуль «Проактивная защита», который заблокировал запрос.
Ошибка при обновлении. Чаще всего не хватает места на диске, запрос не укладывается в таймаут сервера или закончилась лицензия: обновления устанавливаются только при активной лицензии.
Ошибка в своём компоненте или шаблоне. Журнал укажет файл в /local/ или в шаблоне сайта. Как устроен компонент и где искать его код, разобрано в статье о создании компонента.

После исправления

Верни 'debug' => false и $DBDebug = false, если включал их.
Убери добавленные отладочные параметры из .settings_extra.php. Удаляй весь файл только если создал его для этой проверки и в нём нет других настроек.
Удали отладочные журналы и вызовы writeToFile.
Проверь страницы, на которых была ошибка, и соседние разделы.

Похожая логика работает и в WordPress — там это сообщение о критической ошибке. Разбор в статье о критической ошибке WordPress.