Как посмотреть логи ошибок сайта

Когда сайт показывает белый экран, ошибку 500 или не сохраняет форму, интерфейс браузера часто скрывает настоящую причину. Журналы помогают увидеть, какой запрос завершился неудачно, где остановилось приложение и что происходило непосредственно перед сбоем.

Начните с точного времени и действия, которое вызывает ошибку. Затем найдите соответствующую запись в access log, error log и журнале приложения. Чтение всех файлов подряд без привязки к событию обычно только добавляет шума.

В этой статье разберём поиск журналов на виртуальном хостинге и VPS, безопасное включение диагностики PHP и WordPress, типовые сообщения и подготовку обращения в поддержку. Примеры предназначены для вашего проекта; пути и названия служб нужно подставить реальные.

Какие журналы бывают

Журнал	Что содержит	Когда полезен
Access log веб-сервера	Запросы, URL, коды ответа и другие настроенные поля	Проверить, дошёл ли запрос, найти 404 и массовые обращения
Error log веб-сервера	Ошибки обработки запроса, файлов и upstream	Диагностика 403, 502, 504 и проблем маршрутизации
Журнал PHP	Ошибки интерпретатора и выполнения кода	Белый экран, fatal error, ошибки расширений
Журнал приложения	События CMS, исключения, контекст операций	Формы, заказы, интеграции, фоновые задачи
Системный журнал	Запуск служб, нехватка ресурсов, события ОС	Падение процессов и проблемы окружения на VPS

Эти файлы не заменяют друг друга. Код 500 в access log показывает результат запроса, но не обязательно причину. А warning в журнале PHP не всегда объясняет, почему посетитель увидел ошибку: предупреждение могло относиться к другой странице или давно завершённой задаче.

Формат и состав записей зависят от настроек. Например, Nginx позволяет задавать поля access log через log_format, что описано в официальной документации. Не ожидайте, что любой сервер обязательно пишет время выполнения или адрес внешнего сервиса.

Сначала зафиксируйте событие

Запишите URL без секретных параметров, время с часовым поясом, выполненное действие, код ответа и ожидаемый результат. Если проблема возникает после загрузки обложки, важны формат, размер файла, заполненные поля и момент сохранения. Фраза «админка иногда не работает» слишком расплывчата для поиска.

Повторите сбой один раз на безопасных данных, если это не создаёт дубли платежей, заказов или рассылок. Для таких операций сначала используйте тестовый режим. Не нажимайте кнопку оплаты десять раз ради появления дополнительных строк в журнале.

Сравните время компьютера, панели и приложения. Если журнал ведётся в UTC, а вы записали московское время, искать нужно с правильным смещением. Неверная временная привязка — частая причина уверенного, но ошибочного вывода «в логах ничего нет».

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

Где искать логи на виртуальном хостинге

Откройте раздел сайта в панели и найдите «Логи», «Журналы», «Ошибки» или «Диагностика». У провайдера могут быть отдельные вкладки для access log и PHP. Иногда сбор нужно включить заранее, и записи появляются только после этого.

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

Если предусмотрено скачивание, выгрузите небольшой нужный интервал. Большой архив со всеми запросами за месяц неудобен для первичного анализа и может содержать лишние персональные данные. Не загружайте его в публичный чат без обработки.

Когда в панели нет нужного журнала, посмотрите справку тарифа или спросите поддержку: где хранится PHP error log, включена ли запись, какой срок хранения и доступен ли журнал ограничений ресурсов. На виртуальном хостинге системные журналы соседних клиентов обычно недоступны — это нормальное разделение доступа.

Как читать журнал через SSH

Если путь известен, начните с последних строк. Эти команды читают файл и не меняют его:

tail -n 100 /path/to/site-error.log
less /path/to/site-error.log

tail удобен для свежего сбоя, less — для просмотра большого файла с поиском. Чтобы наблюдать новые записи, используйте:

tail -F /path/to/site-error.log

Остановить наблюдение можно сочетанием Ctrl+C. Вариант -F полезен при ротации, когда журнал переименовывают и создают заново. При этом доступность команды зависит от окружения и прав аккаунта.

Для поиска известного фрагмента:

grep -nF 'Allowed memory size' /path/to/site-error.log
grep -nF '/catalog/item/' /path/to/site-access.log

Ищите достаточно конкретный путь или идентификатор. Не вставляйте в команду полный URL со сброшенным паролем, токеном или платёжной подписью: значение может сохраниться в истории команд.

Где лежат логи на VPS

У Nginx часто встречаются /var/log/nginx/access.log и /var/log/nginx/error.log, у Apache — каталоги /var/log/apache2/ или /var/log/httpd/. Это распространённые варианты, а не обязательный стандарт для любого сервера.

У конкретного сайта могут быть собственные пути в конфигурации виртуального хоста. Просмотрите активную настройку или найдите директивы access_log и error_log. Не заменяйте конфигурацию только ради того, чтобы путь стал похож на пример из статьи.

Службы под systemd могут писать в journal. Пример просмотра для реального имени службы:

sudo journalctl -u your-app.service --since '30 minutes ago' --no-pager

Нужны права на чтение соответствующих журналов. Если приложение работает в контейнере, смотрите журнал конкретного контейнера и способ его хранения. Ошибка может находиться не в системном файле, а в стандартном потоке процесса.

Не публикуйте полный вывод конфигурации сервера. В нём могут оказаться адреса внутренних сервисов, пути к ключам и параметры подключений. Для обращения в поддержку выбирайте только относящийся к сбою фрагмент.

Как безопасно включить журнал PHP

На рабочем сайте ошибки лучше записывать в закрытый журнал, а не показывать посетителю. В панели PHP ищите настройки log_errors, display_errors, error_reporting и путь к файлу ошибок.

Пример желаемой конфигурации:

log_errors = On
display_errors = Off
error_reporting = E_ALL

Способ изменения зависит от обработчика PHP и ограничений хостинга. Панель, php.ini, .user.ini и настройки пула PHP-FPM не взаимозаменяемы во всех окружениях. Значения и ограничения описаны в руководстве PHP.

Если указываете собственный error_log, выберите каталог вне публичной папки и убедитесь, что процесс PHP может туда писать. Не используйте общий открытый файл с правами на запись для всех пользователей сервера.

После изменения воспроизведите безопасный тестовый запрос и убедитесь, что запись появилась. Затем проверьте, что посетитель по-прежнему не видит трассировку. Учтите, что настройки веб-PHP и CLI могут различаться: журнал cron-задачи иногда находится в другом месте.

Как включить диагностику WordPress

Для тестовой копии можно настроить режим отладки в wp-config.php. Не добавляйте повторные определения, если константы уже есть. Перед редактированием сохраните копию файла и проверьте место вставки.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/private/path/wordpress-debug.log');
define('WP_DEBUG_DISPLAY', false);

Путь должен существовать и быть доступен для записи процессу PHP, но не для скачивания через сайт. Поведение этих параметров описано в документации WordPress по отладке.

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

Не исправляйте проблему отключением всех сообщений об ошибках. Это убирает видимый симптом, но не причину. Если после обновления появился несовместимый плагин, его нужно обновить, заменить или исправить на тестовой копии.

Как читать одну запись

В записи могут присутствовать время, уровень, сообщение, путь файла, номер строки и контекст запроса. Сначала найдите время и точное сообщение, затем посмотрите несколько строк до и после.

Учебный пример:

2026-10-26T10:15:00+03:00 ERROR
Upload failed: destination is not writable
request_id=example-request-id

Здесь видно, что проблема связана с записью файла, но ещё неизвестно почему. Причиной могут быть права, владелец каталога, квота, режим только для чтения или неверный путь. Нужна последовательная проверка, а не автоматическая установка самых широких прав.

Номер строки помогает найти место проявления, но не всегда первопричину. Например, ошибка в библиотеке обработки изображений может быть вызвана неполным входным файлом или нехваткой памяти. Не редактируйте стороннюю библиотеку, пока не проверили входные данные и окружение.

Если есть stack trace, читайте цепочку вызовов вместе с последними изменениями проекта. Обычно полезнее первый относящийся к вашему приложению вызов, чем десятки повторяющихся строк фреймворка.

Типовые сообщения и первые действия

Сообщение или симптом	Что проверить сначала
Allowed memory size exhausted	Тяжёлую операцию, размер входных данных, лимит памяти, утечки
Permission denied	Реальный путь, владельца, права, ограничения окружения
No space left on device	Диск, квоту, inode, временные каталоги
Connection refused	Работу нужной службы, адрес и порт
Ошибка аутентификации базы	Имя пользователя, пароль, права, новый адрес СУБД
upstream timed out	Длительную работу приложения, БД, внешние запросы
Primary script unknown	Корень сайта, путь PHP-скрипта, настройки FastCGI
Too many connections	Утечки соединений, параллельность, ограничения БД

Это направления проверки, а не однозначные диагнозы. Одинаковый текст может возникнуть по разным причинам. Например, увеличение memory_limit поможет только если операция укладывается в общие ресурсы и действительно требует большего лимита, а не бесконечно накапливает данные.

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

Что означают HTTP 500, 502 и 504

500 сообщает о внутренней ошибке сервера, но не раскрывает конкретную причину. Ищите журнал приложения и PHP в тот же момент. Иногда приложение намеренно возвращает 500 при исключении, а веб-сервер отработал штатно.

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

Ошибки нужно связывать с конкретным маршрутом. Если статические картинки работают, а динамические страницы нет, проблема может быть в обработчике приложения. Если не открывается вообще ничего, проверьте также сеть, TLS и конфигурацию сайта.

Сравните код в браузере с access log. Прокси или CDN способен вернуть собственную ошибку до обращения к origin. В таком случае на сервере не будет соответствующей записи, и искать нужно на предыдущем участке цепочки.

Если в логах ничего нет

Проверьте правильность домена, файла и временного интервала. Уточните, включена ли запись и хватает ли места. Сам журнал может перестать обновляться из-за переполнения диска или отсутствия прав.

Убедитесь, что запрос достигает нужной площадки. После переноса часть сетей может обращаться по старому DNS, а вы — смотреть журналы нового сервера. Проверка нового хостинга до переключения описана в отдельной статье.

Ошибка в браузерном JavaScript тоже не обязана попадать в серверный журнал. Откройте Console и Network: запрос мог даже не отправиться из-за ошибки скрипта, CORS или блокировки смешанного контента.

Если приложение пишет только в stdout, ищите вывод службы или контейнера. Если это управляемая услуга, уточните доступные журналы у провайдера. Не включайте глобальный debug на всех сайтах аккаунта ради одного запроса.

Как подготовить обращение в поддержку

Передайте домен, пример маршрута без секретов, точное время с часовым поясом, код ответа и краткий сценарий воспроизведения. Добавьте небольшой очищенный фрагмент журнала и список последних изменений.

Хорошее описание: «После загрузки WebP-обложки и сохранения статьи сервер отвечает 500; повторяется на тестовой записи; время 14:20 МСК; в журнале ошибка записи в каталог загрузок». Оно помогает быстро проверить права и квоту.

Не отправляйте пароль от админки, ключ API, cookies сессии или полный дамп базы в обычном сообщении. Если поддержке нужен доступ, используйте предусмотренный ею безопасный механизм и ограниченный срок действия.

Перед публикацией фрагмента замените секреты и идентификаторы клиентов нейтральными обозначениями. Сохраните структуру и смысл сообщения, чтобы замена не скрыла причину. Оригинал держите в защищённом месте до завершения расследования.

Ротация и срок хранения

Журнал не должен расти бесконечно. На VPS настройте ротацию штатными средствами системы или приложения; на виртуальном хостинге уточните политику провайдера. Хранение выбирайте под задачи диагностики и требования проекта.

Не удаляйте активный файл вслепую. Процесс может продолжить запись в уже удалённый открытый файл, и место не освободится ожидаемым образом. Используйте корректную ротацию с переоткрытием журнала, если это требуется службе.

Сохраняйте нужный фрагмент до исправления, чтобы не потерять доказательства причины. Затем убедитесь, что после изменения новые ошибки не появляются. Для важных проектов полезно отдельное оповещение о росте числа сбоев, а не только ручной просмотр раз в месяц.

Сведения в логах могут включать IP-адреса, пути и параметры запросов. Настройте состав записей так, чтобы в них не попадали пароли и чувствительные данные. Не размещайте архив журналов в публичной папке сайта.

Практический сценарий: ошибка при загрузке картинки

Сначала зафиксируйте формат и размер файла, точное действие и время. Откройте Network, найдите запрос загрузки и код ответа. Если это 413, проверьте ограничения размера запроса на веб-сервере и уровне приложения. Если 500 — журнал обработки файла.

Сверьте, доступен ли временный каталог, хватает ли места и поддерживается ли формат библиотекой обработки изображений. Попробуйте небольшой заведомо корректный файл на тестовой записи. Если он работает, сравните характеристики с проблемным, не заменяя сразу все настройки сервера.

После исправления проверьте загрузку, сохранение alt, отображение обложки и повторное редактирование статьи. Посмотрите, не остались ли временные файлы и новые ошибки. Успешная загрузка без сохранения записи — ещё не завершённый сценарий.

Пример расследования ошибки 500 после смены PHP

Предположим, после переключения версии главная открывается, но страница формы возвращает 500. Запишите время, путь и действие. Затем найдите этот запрос в access log и соответствующую ошибку в журнале PHP.

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

Сравните прежний и новый профиль PHP: версия, модули, лимиты, путь временных файлов. Если критичный сценарий не работает, используйте подготовленный возврат к прежнему окружению, сохранив сведения об ошибке для исправления на копии.

После изменения повторите именно форму, которая падала, затем проверьте соседние сценарии. Успешная главная по-прежнему ничего не говорит о коде отправки письма. Проверьте и результат доставки в тестовый ящик, а не только сообщение интерфейса.

Пример расследования ошибки 502 на VPS

Начните с error log веб-сервера. Сообщение о невозможности подключиться к upstream направляет проверку к обработчику приложения. Посмотрите состояние службы и её журнал в тот же период.

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

Если служба работает, сверяйте адрес или сокет подключения, права и фактическую конфигурацию. Не открывайте внутренний порт всему интернету ради проверки связи между локальными процессами. Сначала подтвердите маршрут и область доступа.

После исправления выполните один обычный запрос, проверьте ответ и отсутствие новой ошибки. Затем понаблюдайте за стабильностью в течение подходящего для проекта времени. Один успешный запрос сразу после рестарта не исключает повторное падение под обычной нагрузкой.

Как не перепутать шум ботов с неисправностью

В access log почти любого публичного сайта встречаются запросы к несуществующим путям. Само наличие множества 404 не доказывает взлом или поломку. Важно, относятся ли они к реальным страницам и пользователям вашего проекта.

Сравните маршруты, частоту и время. Если посетители получают 404 на опубликованную статью после изменения постоянных ссылок, это прикладная проблема. Если неизвестный клиент запрашивает файлы чужой CMS, это другой сценарий, требующий оценки защиты и нагрузки.

Не блокируйте широкие диапазоны адресов по одной строке без понимания последствий. За одним внешним IP могут находиться разные пользователи. Для защиты от автоматических запросов используйте подходящие ограничения и проверяйте, что они не мешают нормальным действиям.

Что сохранять после инцидента

Оставьте короткое описание причины, исправления и подтверждающего сценария. Например: «каталог обработки изображений был недоступен для записи; восстановлен владелец; загрузка, alt и повторное сохранение проверены». Такой итог полезнее архива всех журналов без вывода.

Запишите, что поможет обнаружить повторение: контроль квоты, оповещение о падении службы, тест формы или проверка последней фоновой задачи. Не каждая проблема требует сложной системы мониторинга, но у каждой должен быть понятный признак.

Удалите временный публичный debug и убедитесь, что журналы продолжают сохраняться в закрытом месте. Если во время расследования раскрылись ключи или пароли, их нужно заменить; удаление строки из публичного сообщения не отменяет факта раскрытия.

Частые вопросы

Можно ли показывать ошибки PHP посетителям?

На рабочем сайте лучше писать их в закрытый журнал. Публичная трассировка может раскрыть внутренние пути и детали приложения. Подробный вывод используйте в контролируемом тестовом окружении.

Нужно ли исправлять каждое предупреждение немедленно?

Оцените влияние и связь с текущим сбоем. Предупреждения о несовместимости полезно устранить до обновления PHP, но не каждое из них объясняет конкретную ошибку 500.

Достаточно ли access log для поиска причины?

Он помогает связать время, маршрут и статус. Для внутренних исключений обычно нужен журнал приложения или PHP, а для падения процесса — сведения службы и системы.

Можно ли очистить огромный журнал?

Сначала сохраните нужный фрагмент и найдите причину роста. Затем выполните штатную ротацию. Без исправления повторяющейся ошибки файл быстро вырастет снова.

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

• Повторён исходный сценарий на безопасных данных.

• Проверен результат операции, а не только код ответа.

• В журналах нет новой связанной ошибки.

• Публичный debug отключён.

• Временные диагностические файлы удалены.

• Настроена ротация и сохранён полезный контекст инцидента.

Работа с логами становится эффективной, когда каждое изменение связано с проверяемой гипотезой. Это позволяет исправить причину сбоя и не менять случайные параметры сайта в надежде, что ошибка исчезнет.

Если Nginx отвечает 502

Для сообщения об upstream есть отдельная инструкция по 502 Bad Gateway: журнал, служба, локальный порт и проверка исправления.

Две практические проверки для загрузки и записи

Для больших загрузок используйте диагностику 413 в Nginx, а при No space left on device — проверку диска и inode. Сначала сопоставьте код и сообщение журнала.