На одном сайте это может быть фатальная ошибка PHP после обновления. На другом — закончившаяся память, неправильная директива в .htaccess, проблема с правами, базой данных или свободным местом на диске.
Поэтому ошибка 500 в 1С-Битрикс диагностируется не перебором настроек. Сначала нужно получить первую реальную ошибку, которая появилась в момент запроса, и уже по ней искать источник сбоя.
Если сайт нужен посетителям прямо сейчас
Если ошибка появилась на рабочем сайте:
- Не обновляйте подряд PHP, ядро, модули и серверное окружение в надежде, что ошибка исчезнет.
- Зафиксируйте страницу, на которой появляется 500, точное время и действие перед ошибкой.
- Вспомните последнее изменение: обновление платформы, PHP, модуля, шаблона, компонента,
.htaccess, серверных настроек. - Перед изменением файлов сохраните их текущие версии или сделайте резервную копию.
- Получите журнал ошибок сервера или PHP за нужное время.
- Если проблема началась сразу после конкретного изменения, сначала проверяйте именно его.
Удаление кеша, увеличение памяти и изменение прав без понимания причины могут на время изменить симптом, но не обязательно исправят сам сбой.
1. Что означает ошибка 500 в 1С-Битрикс
HTTP 500 — это ответ сервера о внутренней ошибке при обработке запроса.
Это не отдельная ошибка 1С-Битрикс и не диагноз вроде «сломалась база» или «не работает PHP».
Цепочка запроса обычно выглядит примерно так:
браузер → Nginx/Apache → PHP → ядро 1С-Битрикс → модули и пользовательский код → база данных и другие сервисы
Сбой на любом из этих этапов может закончиться одинаковой страницей:
500 Internal Server Error
Поэтому главный вопрос при диагностике:
какая ошибка появилась в логах в тот момент, когда сервер вернул 500?
Именно она обычно даёт первую полезную точку для дальнейшей проверки.
↑ К оглавлению2. Сначала определяем масштаб проблемы
Перед изменением настроек полезно понять, какая часть сайта перестала работать.
Ошибка 500 на всём сайте
Если не открывается публичная часть и административный раздел, проверяем в первую очередь:
- PHP;
- глобально подключаемый код;
/local/;init.php;- сторонние модули;
.settings.php;- соединение с базой данных;
- конфигурацию веб-сервера;
- права;
- ресурсы сервера.
Ошибка только на одной странице
Если остальные разделы работают, вероятность глобальной серверной проблемы ниже.
Проверяем:
- компонент этой страницы;
- его шаблон;
- пользовательский обработчик;
- подключаемый файл;
- запрос к базе;
- код стороннего модуля, который запускается именно здесь.
Ошибка только в административном разделе
Смотрим конкретный URL и действие перед ошибкой.
Например, сбой может происходить только:
- при сохранении элемента;
- при открытии списка заказов;
- во время импорта;
- при обновлении модуля;
- при выполнении определённого административного обработчика.
Ошибка появляется после отправки формы, импорта или загрузки файла
Проверяем обработчик этого запроса, ограничения памяти и времени, права на запись, временные каталоги и код, который обрабатывает данные.
Чем точнее воспроизводится ошибка, тем меньше участок системы, который приходится проверять.
↑ К оглавлению3. Где искать настоящую причину ошибки
Первое полезное действие при 500 — открыть журналы ошибок.
В зависимости от окружения нужная запись может находиться:
- в error log веб-сервера;
- в журнале PHP или PHP-FPM;
- в журнале обработчика ошибок 1С-Битрикс;
- в панели управления хостингом;
- в системном журнале сервера.
Если сайт находится на обычном хостинге и доступа к серверным логам нет, передайте поддержке:
- домен;
- URL с ошибкой;
- точное время возникновения;
- действие, после которого сервер возвращает 500.
Попросите именно запись из error log за это время, а не общий ответ «на сайте ошибка PHP».
Что искать в журнале
Типичные полезные сообщения:
PHP Fatal error
Uncaught Error
Uncaught Exception
Parse error
Allowed memory size exhausted
Call to undefined function
Class ... not found
Permission denied
No space left on device
ошибки mysqli, SQLSTATE и соединения с базой.
Важна не только последняя строка. Если после основного сбоя появилось ещё несколько сообщений, они могут быть уже следствием первой ошибки.
Начинаем с первой записи, которая совпадает по времени и запросу.
↑ К оглавлению4. Как включить журнал ошибок 1С-Битрикс
В современном ядре Bitrix Framework обработка ошибок настраивается через секцию exception_handling.
Обычно настройки находятся в:
/bitrix/.settings.php
В актуальных версиях главного модуля файлы .settings.php и .settings_extra.php также могут размещаться в /local.
Если журналирование уже настроено, сначала используем существующую конфигурацию.
Пример штатной секции логирования выглядит так:
'exception_handling' => array(
'value' => array(
'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' => array(
'settings' => array(
'file' => 'bitrix/modules/error.log',
'log_size' => 1000000,
),
),
),
'readonly' => false,
), Это пример структуры, а не файл, которым нужно заменить существующий .settings.php.
Перед редактированием сохраняем копию текущего файла и меняем только нужные параметры.
Нужно ли включать debug => true
Режим debug выводит подробности ошибки прямо в браузер.
На рабочем публичном сайте оставлять его включённым не стоит: сообщение может показать посетителю пути к файлам, детали кода и другую техническую информацию.
Для production безопаснее сначала получить ошибку через журнал.
Если подробный вывод всё-таки нужен для короткой диагностики, после проверки его нужно снова выключить.
↑ К оглавлению5. Фатальная ошибка PHP или ошибка в коде
Одна из самых частых причин 500 — выполнение PHP прекращается из-за фатальной ошибки.
В журнале при этом можно увидеть:
- файл;
- строку;
- текст ошибки;
- стек вызовов.
Например, ошибка указывает на:
/local/...
/bitrix/php_interface/init.php
шаблон сайта;
кастомный компонент;
обработчик события;
сторонний модуль.
В таком случае начинать с изменения настроек сервера обычно не нужно. Уже известен участок кода, который завершил запрос с ошибкой.
Что проверяем
- Какой файл указан первым в стеке.
- Кто его изменял.
- Когда внесено изменение.
- Есть предыдущая рабочая версия файла или нет.
- Ошибка появилась после обновления PHP, модуля или ядра.
- Код использует удалённую или изменившуюся возможность PHP.
Если проблема началась после правки собственного кода, сравниваем текущую версию с рабочей.
Если журнал уже указывает на конкретный компонент или модуль, нет смысла сразу отключать весь /local/ — сначала локализуем найденный участок.
6. Ошибка после смены версии PHP
После изменения PHP старый пользовательский код или сторонний модуль может начать завершаться фатальной ошибкой.
С 1 февраля 2026 года минимальная версия PHP для актуальных продуктов 1С-Битрикс — 8.2. Поэтому работа современного проекта на старой ветке PHP сама по себе уже требует внимания.
Но переход на новую версию PHP тоже нельзя использовать как случайный способ исправления 500.
Если ошибка появилась именно после смены версии, проверяем:
- версию ядра 1С-Битрикс;
- обновления стандартных модулей;
- сторонние решения Marketplace;
- собственный PHP-код;
- необходимые расширения PHP;
- первую фатальную ошибку в журнале.
Правильный порядок при плановом обновлении PHP:
резервная копия → обновление платформы и модулей → проверка сторонних решений → смена PHP → повторная проверка сайта
Если после перехода журнал указывает на сторонний модуль, исправлять нужно его совместимость, а не маскировать фатальную ошибку.
В BitrixVM версия PHP также обновляется отдельно от самой виртуальной машины. Поэтому после изменений окружения полезно отдельно проверить фактически используемую версию PHP и список расширений.
↑ К оглавлению7. Не хватает памяти PHP
Характерная запись:
Allowed memory size exhausted
В этом случае PHP достиг значения memory_limit.
Для актуального серверного окружения 1С-Битрикс в технических требованиях используется значение:
memory_limit = 256M Но простое увеличение лимита не всегда является окончательным решением.
Сначала смотрим, на какой операции закончилась память.
Например:
- импорт большого файла;
- генерация изображения;
- тяжёлая выборка;
- выгрузка каталога;
- сторонний модуль;
- зацикленный пользовательский код.
Если операция действительно требует больше памяти, лимит можно корректировать на уровне конфигурации PHP или хостинга.
Если обычная страница внезапно начинает съедать сотни мегабайт, увеличение memory_limit только отодвинет момент следующего сбоя.
После изменения повторяем тот же запрос и проверяем потребление ресурсов и журнал ошибок.
↑ К оглавлению8. Ошибка в .htaccess
Неправильная директива Apache может сама вызвать 500 ещё до нормального выполнения PHP-кода сайта.
Особенно внимательно проверяем .htaccess, если проблема появилась сразу после его редактирования.
Например, директивы:
php_value
php_flag работают не во всех конфигурациях сервера.
Если хостинг или текущий режим PHP запрещает такие настройки через .htaccess, Apache может вернуть Internal Server Error.
Что делать
- Сохранить текущий
.htaccess. - Сравнить его с последней рабочей версией.
- Найти недавно добавленные директивы.
- Посмотреть error log Apache.
- Вернуть только проблемное изменение.
- Повторить запрос.
Полностью удалять .htaccess наугад не стоит. В нём могут находиться необходимые правила маршрутизации, безопасности и работы самого сайта.
Если используется конфигурация без обработки .htaccess, причину ищем в настройках соответствующего веб-сервера.
9. Проблемы с правами на файлы и каталоги
500 может возникнуть, когда сервер:
- не может прочитать PHP-файл;
- не может подключить нужный файл;
- не может записать кеш;
- не может создать временный файл;
- получает запрещённые для данного хостинга атрибуты файла.
В журнале обычно появляются сообщения вроде:
Permission denied
или путь к ресурсу, который сервер не смог открыть.
Проверяем:
- владельца файлов;
- группу;
- права;
- пользователя, от которого работает веб-сервер или PHP;
- права конкретного каталога, указанного в ошибке.
Не нужно исправлять проблему командой вида:
chmod 777
для всего сайта.
Она не устраняет причину неправильного владельца или конфигурации и создаёт дополнительный риск безопасности.
Права приводим к значениям, которые соответствуют конкретному серверному окружению и схеме запуска PHP.
↑ К оглавлению10. Ошибка подключения или запроса к базе данных
Если журнал указывает на MySQL, mysqli, SQLSTATE, соединение или SQL-запрос, переходим к диагностике базы.
Проверяем:
- доступность сервера БД;
- параметры подключения;
- пользователя и пароль;
- права пользователя базы;
- состояние самой базы;
- запрос или модуль, указанный в стеке.
В современном ядре параметры соединения находятся в секции connections файла .settings.php.
Использовать старые советы по редактированию dbconn.php как универсальный способ восстановления соединения уже неправильно: актуальное ядро получает параметры подключения к базе из .settings.php.
Переменная $DBDebug относится к старому механизму диагностики и может быть полезна в отдельных legacy-сценариях, но это не первый шаг при любой ошибке 500.
Если административный раздел доступен, после восстановления можно дополнительно использовать штатные инструменты проверки и диагностики базы данных.
↑ К оглавлению11. Закончилось место на сервере
Недостаток свободного места способен вызвать проблемы далеко не только при загрузке файлов.
Сайту постоянно нужно записывать:
- кеш;
- сессии;
- временные файлы;
- журналы;
- резервные копии;
- загруженные данные;
- служебные файлы.
При полном диске в системном журнале может появиться:
No space left on device
На сервере с BitrixVM состояние файловых систем можно проверить, например:
df -Th Если место действительно закончилось, наиболее безопасное решение — сначала обеспечить свободное пространство.
Не стоит в аварийном порядке удалять неизвестные каталоги из /bitrix/, /local/ или системной части сервера.
После освобождения места проверяем тот же запрос и смотрим, вернулась нормальная запись кеша, сессий и логов или нет.
↑ К оглавлению12. Ошибка возникает только при долгой операции
Иногда обычные страницы работают, а 500 появляется только при:
- импорте;
- экспорте;
- обмене;
- формировании большого отчёта;
- обработке большого количества товаров;
- другой продолжительной операции.
Тогда в журнале проверяем ограничения времени выполнения и сообщения веб-сервера или PHP.
Простое увеличение timeout до очень большого значения не всегда правильно.
Сначала нужно определить:
- какая операция выполняется долго;
- на каком этапе она останавливается;
- выполняется один тяжёлый запрос или много повторяющихся действий;
- можно разбить процесс на части;
- присутствует медленная внешняя система или база.
Если операция объективно требует больше времени, серверный лимит настраивается осознанно.
Если код зациклился или выполняет лишнюю работу, увеличение лимита только заставит сервер дольше ждать того же сбоя.
↑ К оглавлению13. Проверка после исправления
Ошибка считается исправленной не тогда, когда исчезла страница 500, а когда найденная причина устранена и тот же сценарий снова работает нормально.
После изменения:
- Повторяем тот же URL и то же действие.
- Проверяем HTTP-ответ.
- Смотрим журнал ещё раз.
- Убеждаемся, что исходная ошибка больше не появляется.
- Проверяем соседний функционал, который использует тот же модуль или код.
- Выключаем временный расширенный вывод ошибок.
- Если административный раздел работает, запускаем штатную «Проверку системы».
Инструмент 1С-Битрикс:
Настройки → Инструменты → Проверка системы
проверяет соответствие окружения требованиям продукта и помогает обнаружить проблемы конфигурации, файлов, базы и других частей системы.
Главный принцип остаётся тем же:
воспроизвели → нашли запись в журнале → локализовали причину → исправили → повторили тот же запрос
Так диагностика не превращается в последовательное изменение случайных настроек.
↑ К оглавлению14. Частые вопросы
Можно просто очистить кеш 1С-Битрикс при ошибке 500?
Иногда проблема действительно связана с повреждённым или устаревшим кешем, но очистка кеша не исправит фатальную ошибку PHP, неправильный .htaccess, отсутствие памяти, проблемы с правами или базой. Сначала лучше получить реальную ошибку из журнала.
Почему ошибка 500 появилась после обновления PHP?
Частая причина — несовместимый пользовательский код или сторонний модуль. Также после изменения окружения проверяем необходимые расширения PHP. Начинать нужно с первой фатальной ошибки и стека вызовов.
Где находится .settings.php в 1С-Битрикс?
Классическое расположение: /bitrix/.settings.php В современных версиях главного модуля настройки также могут размещаться в: /local/.settings.php Дополнительные параметры могут задаваться через .settings_extra.php.
Стоит включать debug в .settings.php?
Для короткой диагностики это возможно, но на публичном рабочем сайте подробный вывод не следует оставлять включённым. Безопаснее записывать ошибку в журнал и анализировать её там.
Что делать, когда 500 появляется только в административной части?
Запишите точный URL и действие, после которого появляется ошибка. Затем найдите соответствующую запись в журнале. Если публичная часть работает, это значительно сужает поиск до административного обработчика, модуля или конкретной операции.
Поможет chmod 777 от ошибки 500?
Не используйте 777 как универсальное исправление. Если журнал показывает Permission denied, нужно определить владельца файлов, пользователя PHP и правильную схему прав для конкретного сервера. Открытие полного доступа маскирует проблему и ухудшает безопасность.
Нужно исправить ошибку 500 в 1С-Битрикс?
Разберу журнал PHP и веб-сервера, найду участок, на котором прекращается запрос, проверю код, окружение и настройки 1С-Битрикс. После исправления повторю проблемный сценарий и проверю, что ошибка не возвращается.