Настройка error log и отладки ошибок на сайте в 2026 году

Настройка error log и отладки ошибок на сайте в 2026 году — это уже не «включил display_errors и посмотрел, что сломалось». На деле всё стало сложнее: PHP 8.2 и 8.3 строже реагируют на старый код, MySQL 8.0 быстрее показывает проблемы с запросами, а браузеры и CDN иногда маскируют настоящую причину сбоя. Я обычно настраиваю логирование сразу на нескольких уровнях: сервер, PHP, CMS и мониторинг. И только так можно быстро понять, где именно сайт начал сыпаться.

Зачем нужен error log в 2026 году

Если говорить грубо, error log — это не просто файл с ошибками. Это ваша история болезни проекта. Без него вы почти всегда будете лечить симптомы, а не причину. У меня был клиент на WordPress с PHP 8.2, который жаловался на «рандомную» белую страницу на карточках товара. Визуально всё выглядело как проблема темы. Но в error log быстро всплыла несовместимость старого плагина фильтров с новым типом данных из WooCommerce. За полчаса нашли источник, хотя вручную это могло бы занять день.

В 2026 году сайт редко ломается «в лоб». Чаще это цепочка мелких проблем: deprecated-уведомления, переполненный memory_limit, медленный SQL-запрос, ошибка в API, конфликт кеша, неотловленное исключение. Если логирование отключено, вы видите только итог: 500, 502, пустая форма, неработающая интеграция. А вот причина остаётся в тени.

И ещё момент. Для SEO и продаж ошибка на сайте — это не абстракция. Если из-за бага не отправляются формы, не загружается корзина или падает личный кабинет, вы теряете деньги здесь и сейчас. Поэтому я однозначно считаю, что настройка логов — это не «опция для разработчика», а обязательная часть доработки сайта и нормальной технической поддержки. Если сайт уже ведёт себя нестабильно, сначала стоит сделать проверку сайта, а потом уже чинить точечно.

Где искать ошибки на сайте: сервер, PHP, CMS и браузер

Я обычно начинаю с самого простого: где именно видна поломка. На хостинге это может быть Apache, Nginx, PHP-FPM или контейнер Docker. На стороне CMS — WordPress, Битрикс или Laravel. В браузере — JS-ошибки, CORS, mixed content, проблемы с загрузкой скриптов. И если сразу не определить уровень, диагностика превращается в хаотичное «пощёлкать всё подряд».

На практике чаще всего ошибки делятся на несколько слоёв:

• PHP-ошибки — warnings, notices, deprecated, fatal errors, exceptions.
• Веб-сервер — 500, 502 Bad Gateway, 503 Service Unavailable, ошибки прокси.
• CMS — конфликт плагинов, модулей, шаблонов, компонентных ошибок.
• База данных — медленные запросы, deadlock, некорректные индексы, проблемы с кодировкой.
• Фронтенд — JavaScript-ошибки, упавшие формы, не грузится карта или аналитика.

Если у вас WordPress на PHP 8.1 или 8.2, то часть старых плагинов начнёт «шуметь» deprecated-уведомлениями. Внешне всё работает, но логи уже засыпаны мусором. На Bitrix ситуация похожая: старые шаблоны и самописные компоненты часто дают notice или warning, особенно после обновления ядра. У Laravel-кастомных проектов чаще всплывают исключения, связанные с очередями, конфигурацией env или API-интеграциями.

Я бы ещё отдельно отметил проблему, которую многие недооценивают: ошибки не всегда видны на проде, но отлично проявляются на staging-среде. Поэтому статья про staging-сайт здесь очень кстати. Я почти всегда рекомендую отлавливать ошибки сначала на копии проекта, а уже потом переносить исправления на боевой домен.

Настройка error log на уровне PHP

Самый частый сценарий — включить логирование в php.ini, .user.ini или через панель хостинга. Я обычно на проектах с PHP 8.2 и 8.3 настраиваю логирование так, чтобы не показывать ошибки пользователям, но при этом сохранять полный журнал в файл. Это плохая идея — выводить ошибки прямо в браузер на боевом сайте. Так можно случайно показать пути к файлам, структуру классов, SQL-запросы и даже куски конфигурации.

Базовая конфигурация для PHP-FPM выглядит примерно так:

display_errors = Off
log_errors = On
error_reporting = E_ALL
error_log = /var/log/php8.3/site-error.log
html_errors = Off

Если у вас shared-hosting, путь к error_log часто задаётся в панели управления. На VPS или выделенном сервере я стараюсь делать отдельный лог под каждый сайт. Это удобно, потому что не приходится разбирать общий поток ошибок от десятка виртуальных хостов. Особенно это критично, если на сервере и WordPress, и Bitrix, и пара Laravel-приложений.

Ещё один нюанс: в 2026 году многие хостинги по умолчанию включают агрессивную фильтрацию логов. То есть часть deprecated и warning может не попадать в стандартный файл. Я с таким сталкивался на Nginx + PHP 8.3. Решение банальное: проверить настройки pool'а PHP-FPM, права на файл и, если нужно, поднять уровень журналирования в конфиге.

Если сайт на WordPress, полезно дополнительно включить собственный debug-режим. В wp-config.php я обычно добавляю такие строки на время работ:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Тогда WordPress складывает ошибки в wp-content/debug.log. Но честно говоря, этого мало для сложных проектов. Если есть плагины, REST API, cron, интеграция с CRM или обмен с 1С, я всё равно смотрю серверный лог. Иначе можно пропустить фатальную ошибку на уровне PHP-FPM или web server.

Для Bitrix логирование часто завязано и на ядро, и на отдельные обработчики. Если проект живой и постоянно дорабатывается, однозначно стоит держать под рукой и серверный лог, и лог приложения. В таких случаях поддержка Bitrix с нормальной отладкой экономит массу времени. По опыту, на больших каталогах Bitrix особенно полезно отслеживать медленные запросы к базе и исключения в кастомных компонентах.

Логи Nginx, Apache и reverse proxy: что смотреть в первую очередь

Если сайт возвращает 502, 503 или просто тормозит, я почти всегда первым делом открываю error log веб-сервера. Для Nginx это обычно /var/log/nginx/error.log, для Apache — /var/log/apache2/error.log или аналогичный путь в зависимости от дистрибутива. На проектах с reverse proxy ещё нужно смотреть логи балансировщика, потому что именно там часто теряется исходная причина.

У меня был случай на Laravel-проекте с Nginx и PHP-FPM 8.2: сайт стабильно отдавал 502 только на некоторых страницах. В браузере всё выглядело как проблема «где-то на сервере». В error log Nginx быстро нашёлся таймаут соединения с PHP-FPM, а уже в логах приложения — тяжёлый запрос к MySQL 8.0 с отсутствующим индексом. То есть проблема была не одна, а две: и серверный таймаут, и медленная база.

Вот пример типичного фрагмента конфигурации Nginx для более удобной диагностики:

server {
    server_name example.com;
    root /var/www/example.com/public;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log warn;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_read_timeout 120;
    }
}

Я специально использую отдельные файлы логов под каждый домен. Это очень помогает, когда на сервере несколько сайтов. И ещё одна вещь: уровень warn не всегда достаточен. Если отлавливаете сложную проблему, на короткое время можно поднять детализацию до info или даже debug, но потом обязательно вернуть обратно. Иначе лог разрастается до неприличия, а полезные события тонут в шуме.

Если вы уже замечаете, что ошибки появляются вместе с перенаправлениями, SSL или прокси-цепочкой, загляните в материалы про 502 Bad Gateway и ошибки прокси и обратный прокси Nginx. Там хорошо видно, как ошибки могут прятаться не в коде, а в связке Nginx + PHP-FPM + CDN.

Отладка ошибок в WordPress, Bitrix и Laravel

Разные CMS и фреймворки требуют немного разного подхода, и это нормально. На WordPress я чаще всего смотрю debug.log, логи плагинов, JS-консоль и состояние cron. На Bitrix — журнал ошибок ядра, события модулей, интеграции с каталогом и обмены. На Laravel — storage/logs/laravel.log, очереди, кэш конфигурации и окружение .env.

Если говорить про WordPress, типовые проблемы в 2026 году всё ещё крутятся вокруг старых плагинов, несовместимости с PHP 8.2/8.3 и кривых обновлений. У меня был клиент, у которого после автоматического обновления плагина оплаты сломалась checkout-страница. В логах сразу увидели TypeError из-за изменения сигнатуры метода. Без логов пришлось бы долго гадать, почему корзина «иногда» падает. Кстати, если вы хотите обновлять сайт без сюрпризов, посмотрите статью про safe update.

В Bitrix проблема часто заключается в том, что ошибка не проявляется сразу. Страница вроде открылась, но где-то в компоненте уже случилось исключение, которое потом влияет на кеш, ajax или оформление заказа. Я обычно советую не ограничиваться только административной панелью. Иногда полезно включить логирование на уровне PHP и дополнительно проверить, не забит ли диск, не упёрлись ли вы в memory_limit и не валится ли cron.

Laravel в этом смысле очень удобен. Он честно пишет exception stack trace, и это сильно ускоряет диагностику. Но есть ловушка: если приложение активно работает с очередями и внешними API, ошибки могут уходить в worker-логи, а не в основной файл. Поэтому я всегда смотрю ещё и Supervisor, и системный журнал.

Как отлавливать PHP warning, notice, deprecated и fatal error

На деле именно здесь чаще всего теряется время. Fatal error заметить легко: сайт упал, и всё очевидно. А вот warning и notice многие игнорируют месяцами, хотя именно из них потом вырастает большой баг. В 2026 году на PHP 8.1–8.3 deprecated-сообщения особенно важны. Сегодня это просто предупреждение, а в следующем обновлении — уже неработающий функционал.

Я обычно настраиваю такой уровень error_reporting, чтобы видеть вообще всё на этапе отладки:

<?php
error_reporting(E_ALL);
ini_set('display_errors', '0');
ini_set('log_errors', '1');
ini_set('error_log', __DIR__ . '/logs/php-error.log');

// Для временной отладки
set_error_handler(function ($severity, $message, $file, $line) {
    throw new ErrorException($message, 0, $severity, $file, $line);
});

Этот подход помогает быстро превращать warning в исключение и ловить место, где именно код ведёт себя не так, как ожидалось. Особенно это удобно на Laravel и в самописных модулях, где иначе ошибка может «проглатываться» обработчиком.

Но тут есть нюанс. Если бездумно поднять уровень ошибок на боевом сайте, можно завалить лог огромным количеством мусора. У меня был проект на MySQL 5.7 и старом Битриксе, где одна неверная настройка порождала тысячи одинаковых notice в минуту. В итоге лог разросся, диск начал забиваться, а вместе с этим посыпались уже настоящие аварии. Поэтому отладка должна быть временной и контролируемой. Для длительного наблюдения лучше настроить мониторинг логов сайта и ротацию.

Проверка логов и автоматизация мониторинга

Если сайт живой, вручную читать лог каждый день — плохая идея. Лучше автоматизировать хотя бы базовый контроль. Я обычно настраиваю rotation, архивирование, уведомления в Telegram или почту и простую фильтрацию критических ошибок. Это особенно полезно, когда сайт работает 24/7, а команда маленькая.

Минимальный набор, который я считаю нормой:

• ежедневная ротация error log;
• архивация старых файлов;
• уведомление при появлении fatal error или 5xx;
• контроль роста размера логов;
• проверка доступности сайта и API-ручек;
• отдельный мониторинг после обновлений CMS.

Если хотите выстроить это системно, рекомендую связку из uptime-мониторинга, логов и бэкапов. Вот тут очень пригодится материал про uptime-мониторинг сайта и бэкапы сайта. Я часто говорю клиентам прямо: лог без бэкапа — это половина решения. Сначала вы находите проблему, потом должны иметь возможность быстро откатиться, если исправление оказалось не тем.

Для автоматического поиска ошибок можно использовать простой bash-скрипт. Да, это не enterprise-SIEM, но для малого и среднего проекта часто хватает с головой:

#!/usr/bin/env bash
LOG="/var/log/nginx/example.com.error.log"

if grep -Ei "fatal|uncaught|segmentation fault|upstream timed out|PHP message: PHP Fatal error" "$LOG" | tail -n 20; then
  echo "Errors found in $LOG" | mail -s "Site errors detected" admin@example.com
fi

На больших проектах я чаще иду в сторону централизованного сбора: ELK, Loki, Graylog, Sentry. И это уже не роскошь. Когда у вас несколько доменов, контейнеры Docker, очереди, cron и внешние интеграции, без централизованных логов искать проблему очень долго. Грубо говоря, вы не отлаживаете сайт, а живёте в поиске иголки в стоге сена.

Что делать при 500, 502, 503 и других сбоях

Когда сайт уже упал, паниковать не надо. Я обычно иду по короткому чек-листу. Сначала смотрю серверный лог, потом PHP-лог, потом приложение, потом базу данных. Если проблема массовая, проверяю ещё DNS, CDN, SSL и заголовки безопасности. Ошибка 500 чаще всего означает, что код упал. 502 — что сломалась связка прокси и backend. 503 — что сервис временно недоступен или перегружен.

На WordPress 500 нередко связан с плагином или темой. На Bitrix это бывает после обновления модуля или из-за старого пользовательского кода. На Laravel — из-за исключения, неверной конфигурации, очереди или кеша. Но я бы не сводил всё к «сломался код». Очень часто виноваты лимиты памяти, права на файлы, переполненный диск, битый OPcache или зависший PHP-FPM worker.

Если сайт стал сыпаться после изменений, полезно держать под рукой статью про ошибку 500 на сайте и материал про 502 Bad Gateway. Я на практике не раз видел, как 500 маскировалась под проблему кеша, а 502 — под обычную «просадку» хостинга. И без логов это выглядит одинаково: сайт просто не открывается.

Практическая схема настройки для проекта в 2026 году

Если бы ко мне пришёл новый клиент и попросил «сделать нормальную отладку», я бы не распылялся. Я обычно выстраиваю такую схему: отдельные логи для Nginx/Apache, отдельный PHP log, лог CMS, мониторинг uptime, алерт при 5xx и ротация файлов. Для WordPress и Bitrix этого уже достаточно, чтобы быстро понять, где именно появилась неисправность. Для Laravel добавляю ещё Sentry или хотя бы централизованный сбор exception.

Самое разумное — сразу продумать и организацию доступа. Логи не должны быть открыты всем подряд. На сервере я ограничиваю доступ по SSH-ключам, иногда добавляю 2FA для панели управления, а сами файлы логов храню с правами, недоступными для веб-процесса. Если проект чувствительный, это уже вопрос не только отладки, но и безопасности. Здесь очень пригодятся статьи про SSH-ключи и заголовки безопасности HTTP.

Ещё один момент: отладка не должна жить отдельно от поддержки сайта. На моём опыте самые стабильные проекты — те, где логирование, мониторинг, бэкапы и обновления связаны в один процесс. Если вы только планируете работы, полезно заранее посчитать бюджет через калькулятор стоимости сайта или сразу закладывать регулярную поддержку WordPress и поддержку Битрикс. Иначе потом всё равно придётся срочно тушить пожары.

На практике я советую простой порядок действий:

1. Сделать резервную копию перед любыми изменениями.
2. Включить логирование на сервере и в CMS.
3. Воспроизвести ошибку на staging-среде.
4. Посмотреть stack trace, SQL-ошибки и логи прокси.
5. Исправить причину, а не симптом.
6. Проверить, что логи снова пишутся корректно.
7. Вернуть production в безопасный режим без display_errors.

Если проект уже нестабилен, я бы не откладывал доработки. Доработать под задачу логирование и отладку обычно дешевле, чем потом разбираться с падениями, потерянными заявками и испорченным UX. Честно говоря, на нормальном бизнес-проекте это одна из самых окупаемых технических работ.

И последнее. Error log — это не просто «файл для разработчика». Это инструмент, который помогает быстрее чинить сайт, меньше терять клиентов и не наступать на одни и те же грабли после каждого обновления. Если вы ведёте сайт на PHP 8.2 или 8.3, используете MySQL 8.0, обновляете CMS и подключаете внешние сервисы, без грамотной отладки уже не обойтись. Это та база, без которой любая дальнейшая оптимизация превращается в угадайку.