Коротко. Большинство ошибок 1С-Битрикс сводятся к пяти сценариям: нехватка ресурсов сервера при пиковой нагрузке (502/504), блокировка сессии при параллельных AJAX-запросах, обрыв соединения с базой данных, ложное срабатывание встроенного проактивного фильтра защиты и падение сайта после обновления модулей из-за нехватки памяти PHP. Диагностика по логам (bitrix/admin/event_log.php и лог PHP-ошибок) в 80% случаев занимает 15-30 минут и указывает точную причину без необходимости перебирать варианты вслепую.
Ошибка 502 Bad Gateway и 504 Gateway Timeout
Эти ошибки означают не проблему в коде сайта, а то, что веб-сервер (обычно nginx) не дождался ответа от PHP-обработчика в отведённое время. Причины почти всегда одна из трёх: недостаточно воркеров PHP-FPM для количества одновременных запросов (актуально при рекламных всплесках трафика или во время полной выгрузки каталога через обмен с 1С), слишком долгий SQL-запрос без индекса, из-за которого одна страница «съедает» ресурс надолго, или банальная нехватка оперативной памяти на сервере при одновременной работе нескольких тяжёлых процессов — например, обмена с 1С и резервного копирования, запущенных в одно и то же время. Проверяется это в первую очередь логом nginx (error.log, строки с upstream timed out) и логом PHP-FPM slow log, который показывает, какой именно скрипт выполнялся дольше лимита.
«Слишком долго идёт закрытие сессии» и зависшие AJAX-запросы
PHP по умолчанию блокирует файл сессии на время выполнения скрипта — если пользователь на одной вкладке запускает долгую операцию (например, загрузку большого файла или сложный отчёт в личном кабинете), все остальные запросы от этого же пользователя, включая AJAX-обновление корзины, ждут, пока первый скрипт освободит сессию. Ощущается это как зависший интерфейс: корзина не обновляется, фильтр каталога «крутится» без ответа. Решение — закрывать сессию сразу после того, как скрипту больше не нужна запись в неё, вызовом session_write_close(), и для действительно долгих операций (импорт, экспорт, отчёты) явно выносить их в отдельный поток без блокировки основной сессии пользователя.
Обрыв связи с базой данных
Сообщение вида «Не удаётся установить соединение с базой данных» или «Слишком много соединений» имеет две типичные причины. Первая — банально неверные данные подключения в bitrix/php_interface/dbconn.php после переноса сайта на новый сервер или смены пароля к базе без обновления файла конфигурации. Вторая, более коварная — превышен лимит одновременных подключений MySQL (max_connections), что случается на виртуальном хостинге с общими ресурсами при скачке посещаемости или при обмене с 1С, который держит соединение открытым дольше обычного. Для сайтов с растущим трафиком лимит подключений на дешёвом shared-хостинге часто оказывается первым узким местом ещё до того, как исчерпается процессор или память — здесь помогает переход на VPS с настраиваемыми лимитами MySQL или пул соединений через отдельный сервис (ProxySQL, PgBouncer для аналогов).
Ложные блокировки проактивного фильтра защиты
Встроенный в 1С-Битрикс модуль «Проактивная защита» (доступен на тарифах «Бизнес» и выше) анализирует входящие запросы на признаки SQL-инъекций и XSS-атак и блокирует подозрительные с кодом 403. Проблема в том, что фильтр иногда принимает за атаку легитимные действия — например, ввод в текстовое поле формы обратной связи символов вроде ' OR или HTML-тегов в теле сообщения, или запросы от систем оплаты с нестандартными параметрами в URL. Если после подключения интеграции (платёжный шлюз, CRM, форма с богатым текстовым полем) начали приходить жалобы на ошибку 403 у части пользователей — первым делом стоит проверить журнал проактивного фильтра (Настройки → Проактивная защита → Журнал событий) и добавить исключение для конкретного правила, а не отключать защиту целиком.
Сайт падает или показывает белый экран после обновления
Белая страница без текста ошибки (или с «Fatal error» в логе PHP, но без отображения на сайте — что нормально для боевого режима без вывода ошибок пользователю) после обновления модулей почти всегда одна из трёх причин:
| Причина | Как проявляется | Что делать |
|---|---|---|
| Нехватка памяти PHP | Ошибка вида «Allowed memory size exhausted» в логе | Увеличить memory_limit в php.ini минимум до 512M на время обновления, для боевой работы часто достаточно 256M |
| Конфликт стороннего модуля | Ошибка указывает на файл вне bitrix/modules/main или bitrix/modules/iblock |
Временно отключить нестандартный модуль через bitrix/admin/module_admin.php и обновить его отдельно |
| Незавершённое обновление БД | Часть таблиц обновилась, часть — нет, ошибки о несуществующих полях | Повторно запустить обновление через bitrix/admin/update_system.php, не выполнять его вручную частями |
Обновления ядра и модулей стоит запускать не в пиковые часы посещаемости и обязательно после свежего бэкапа базы — откат при обновлении без бэкапа занимает часы вместо минут.
Где смотреть логи и как быстро найти причину
Три источника, которые закрывают почти все диагностические задачи: bitrix/admin/event_log.php — журнал событий самого 1С-Битрикс (ошибки авторизации, изменения настроек, сбои обмена); лог PHP-ошибок, путь к которому задаётся в php.ini директивой error_log (обычно в корне сайта или в отдельной папке логов у хостинга); лог веб-сервера nginx или Apache с кодами ответа — по нему видно, на каких именно URL и с какой частотой возникают 500-е ошибки. Если ошибка воспроизводится не постоянно, а эпизодически — стоит смотреть на совпадение по времени с другими процессами: обменом с 1С, резервным копированием, автоматической переиндексацией поиска. Часто «случайные» сбои на деле привязаны к конкретному часу суток, когда несколько тяжёлых задач выполняются одновременно.
FAQ
Сайт периодически выдаёт 502 ошибку только в определённое время суток — почему?
Это почти всегда совпадение по времени с фоновой задачей — обменом с 1С, резервным копированием или переиндексацией поиска, которые в этот момент нагружают сервер сильнее обычного. Проверьте расписание cron-задач и лог сервера на этот временной интервал.
После обновления модулей сайт перестал открываться — что делать в первую очередь?
Посмотреть лог PHP-ошибок — он почти всегда прямо указывает файл и причину. Если под рукой нет свежего бэкапа, для временного восстановления работы можно откатить последнее обновлённое обновление модуля через административную панель, но правильный путь — восстановление из бэкапа, сделанного перед обновлением.
Как отличить настоящую атаку от ложного срабатывания проактивной защиты?
По журналу проактивного фильтра: если заблокированные запросы идут с одного IP пачками и с явно вредоносными параметрами — это атака. Если блокируются легитимные пользователи с обычных IP на конкретной форме сайта — это ложное срабатывание, требующее настройки исключения.
Можно ли устранить эти ошибки без программиста?
Часть — да: увеличение memory_limit, проверка логов, добавление исключения в проактивный фильтр — это административные действия. Ошибки, связанные с производительностью базы данных или конфликтом кастомного кода, требуют разработчика, который умеет читать код модулей.
Сколько стоит диагностика и устранение регулярных ошибок на сайте?
Диагностика по логам обычно занимает 1-2 часа работы и стоит в пределах 3 000-8 000 ₽. Устранение зависит от причины: настройка сервера и лимитов — часы, доработка конфликтующего кастомного модуля — от одного дня.
Разобраться, почему сайт на 1С-Битрикс даёт сбои
Бесплатный аудит найдёт причину ошибок по логам сервера и покажет, что нужно исправить в первую очередь.