Когда сайт перестает работать, самая заметная часть проблемы обычно находится в браузере. Посетитель видит 500, 502, 403, пустую страницу или сообщение о невозможности выполнить запрос. Но браузер показывает только результат. Настоящая причина ошибки часто остается на сервере и попадает в журналы, которые обычно называют логами.
В логах можно обнаружить запрос к проблемной странице, ошибку PHP, неудачную попытку открыть файл, обращение к несуществующему адресу, сбой приложения или подозрительную активность. Иногда одной записи достаточно, чтобы вместо долгих экспериментов сразу понять, где искать неисправность.
При этом лог не похож на понятный отчет с готовым объяснением. Перед владельцем сайта оказывается файл с датами, IP-адресами, кодами ответа, путями и техническими сообщениями. Разберемся, как читать такие записи без попытки превратиться в системного администратора.
Что такое логи сайта
Лог представляет собой журнал событий. Сервер, веб-сервер, PHP, CMS и другие компоненты могут записывать туда информацию о своей работе.
Когда посетитель открывает страницу, веб-сервер получает запрос. Информация об этом запросе может попасть в журнал доступа. Если во время обработки возникает проблема, дополнительная запись появляется в журнале ошибок.
У одного сайта поэтому может быть сразу несколько логов. Они не дублируют друг друга, а показывают происходящее с разных сторон.
На обычном виртуальном хостинге владелец чаще всего сталкивается с журналом обращений и журналом ошибок. На VPS источников значительно больше: появляются системные журналы, отдельные логи Nginx или Apache, PHP-FPM, базы данных, приложения, контейнеров и других служб.
Читать все подряд обычно не нужно. Сначала важно понять, какую проблему вы расследуете.
Чем access log отличается от error log
Два названия встречаются особенно часто: access log и error log.
Access log можно представить как журнал входящих обращений. В нем веб-сервер фиксирует запросы посетителей, поисковых роботов и других клиентов. Там можно увидеть, какой адрес запрашивали, когда это произошло, какой код ответа вернул сервер и с какого IP пришло обращение.
Error log предназначен прежде всего для сообщений о проблемах. Именно здесь часто появляются сведения, которых нет на странице в браузере: невозможность открыть файл, ошибка соединения с внутренним сервисом, проблема конфигурации, отказ в доступе и другие технические события.
Эти журналы хорошо работают вместе.
Представим, что посетитель сообщает: в 15:42 страница товара не открылась. В access log можно найти запрос к этой странице и увидеть, что сервер действительно вернул 500. После этого в error log проверяются записи примерно за то же время. Если там есть сообщение об ошибке PHP или приложения, расследование быстро переходит от общего сайт сломался к конкретной причине.
Где искать логи на обычном хостинге
На виртуальном хостинге проще всего начинать с панели управления. Названия разделов отличаются у разных провайдеров, поэтому искать нужно не конкретную кнопку, а смысл.
Раздел может называться Логи, Журналы, Статистика, Ошибки, Журнал ошибок, Access log или Error log. Иногда журнал доступен непосредственно в настройках конкретного сайта.
В одной панели записи отображаются прямо в браузере. В другой предлагается скачать файл. Некоторые хостинги хранят журналы в отдельном каталоге аккаунта, доступном через файловый менеджер или FTP.
Если найти логи не получается, не стоит перебирать все папки сайта. Проще посмотреть справку конкретного хостинга или спросить поддержку, где доступны журналы веб-сервера и PHP для нужного домена.
Возможности виртуального хостинга ограничены. Провайдер может показывать пользователю только ту часть журналов, которая относится к его аккаунту. Системные события физического сервера обычно недоступны, и это нормально.
Где находятся журналы на VPS
На собственном VPS возможностей значительно больше, но и источников информации становится больше. В типичной Linux-системе многие журналы находятся внутри каталога /var/log/.
Например, Nginx часто использует файлы access.log и error.log в каталоге /var/log/nginx/. У Apache расположение зависит от системы и конфигурации, но журналы также обычно находятся внутри /var/log/.
Это не жесткое правило. Администратор может изменить путь, а отдельный виртуальный хост может иметь собственные файлы журналов. Поэтому при нестандартной конфигурации правильнее посмотреть настройки веб-сервера, чем искать файл по названию из случайной инструкции.
Современные Linux-системы также активно используют системный журнал. Через него можно исследовать запуск и остановку служб, ошибки сервисов и события операционной системы.
Если сайт работает в Docker, часть нужной информации может находиться уже в логах контейнера. У самого приложения тоже может существовать отдельный журнал.
Поэтому на VPS вопрос где лог сайта иногда не имеет единственного ответа.
Как выглядит запись в журнале доступа
На первый взгляд строка access log выглядит как набор несвязанных символов. На самом деле у нее есть структура.
Упрощенная запись может выглядеть примерно так:
192.0.2.15 - - [01/Sep/2026:14:32:18 +0300] "GET /catalog/product/ HTTP/1.1" 200 18452Формат конкретного сервера может отличаться, но здесь уже видны основные элементы.
192.0.2.15— IP клиента;- дата и время показывают момент запроса;
GET— метод запроса;/catalog/product/— запрошенный адрес;200— код ответа;- последнее число может показывать объем переданных данных.
В расширенном формате дополнительно встречаются адрес страницы, с которой пришел посетитель, браузер или другой User-Agent и прочие сведения.
Для обычной диагностики необязательно расшифровывать каждое поле. Чаще всего нужны четыре вещи: время, IP, URL и код ответа.
Коды ответа позволяют быстро отфильтровать события
Если журнал содержит тысячи запросов, просматривать их глазами подряд бессмысленно. Начинать можно с HTTP-кодов.
Ответы 2xx обычно означают успешную обработку. Самый знакомый код 200 говорит, что запрос выполнен нормально.
Коды 3xx связаны с перенаправлениями. Само их присутствие не означает проблему. Например, постоянный редирект со старого адреса на новый может быть совершенно нормальным поведением.
Коды 4xx относятся к ситуациям, когда сервер не может выполнить запрос в его текущем виде. Знакомые примеры — 403 и 404.
Коды 5xx особенно интересны при расследовании серверных сбоев. Они показывают, что проблема возникла на стороне сервера или инфраструктуры, обслуживающей запрос.
Но одного кода недостаточно. Запись 500 подтверждает факт внутренней ошибки, однако не обязательно объясняет ее. За объяснением часто приходится переходить в error log или журнал приложения.
Главный ориентир при поиске ошибки — время
Один из самых эффективных способов работы с логами удивительно прост: сначала выясните точное время проблемы.
Если посетитель говорит сайт вчера не работал, искать придется среди огромного количества событий. Если известно, что ошибка появилась 1 сентября примерно в 16:23, область поиска сокращается до нескольких минут.
Поэтому при воспроизводимой проблеме удобно открыть нужную страницу, дождаться ошибки и сразу посмотреть последние записи журнала.
Еще лучше записать время запроса с точностью до минуты. Не забывайте, что время на сервере может отображаться в другом часовом поясе. Если события в журнале постоянно отличаются от ваших часов на несколько часов, сначала выясните эту разницу.
После этого можно сопоставлять журналы разных компонентов. Например, в 16:23:04 Nginx получил запрос, через секунду приложение записало ошибку, а еще через несколько секунд веб-сервер вернул 500. Такая цепочка намного информативнее каждой записи по отдельности.
Как читать error log
Журнал ошибок обычно выглядит менее аккуратно, чем access log, зато содержит гораздо более ценные подсказки.
Не нужно пытаться понимать всю строку целиком. Сначала ищите знакомые элементы: дату, имя файла, путь, номер строки, название процесса, домен, IP или текст ошибки.
Допустим, после установки плагина перестала открываться одна страница WordPress. В журнале в момент обращения появляется сообщение, содержащее путь к файлу этого плагина. Это еще не всегда окончательный диагноз, но уже очень сильная связь.
Или сервер сообщает, что не может открыть определенный файл из-за отсутствия прав. В таком случае увеличение памяти или смена DNS явно не относятся к причине.
Ценность error log как раз в том, что он помогает выбрать направление проверки и перестать менять настройки наугад.
PHP может вести собственный журнал ошибок
Многие сайты работают на PHP, поэтому неисправность может возникнуть уже после того, как веб-сервер успешно принял запрос.
В журнал PHP способны попадать синтаксические ошибки, необработанные исключения, проблемы подключения файлов, превышение некоторых ограничений и сообщения самого приложения.
Расположение такого журнала зависит от конфигурации хостинга и PHP. На виртуальном хостинге он может быть доступен через панель или находиться рядом с файлами сайта. На VPS путь определяется настройками PHP и PHP-FPM.
Если браузер показывает 500, а журнал веб-сервера не дает понятного ответа, лог PHP становится одним из следующих мест для проверки.
При этом включать публичный вывод подробных PHP-ошибок на рабочем сайте только ради диагностики не лучшая идея. Техническое сообщение может раскрыть посетителю внутренние пути, структуру приложения и другую лишнюю информацию. Безопаснее записывать подробности в журнал, а пользователю показывать нейтральную страницу ошибки.
Что смотреть в логах WordPress
У WordPress есть собственный механизм отладки, который особенно полезен при проблемах с темами, плагинами и PHP-кодом.
При корректной настройке диагностические сообщения можно записывать в отдельный файл, не показывая их посетителям сайта. Это удобнее и безопаснее, чем выводить подробные ошибки прямо на страницу.
Такой журнал особенно полезен, если проблема появилась после обновления плагина, установки новой темы, изменения собственного кода или перехода на другую версию PHP.
Однако WordPress-журнал не заменяет серверные логи. Если запрос вообще не дошел до WordPress, внутри CMS никакой записи может не появиться. Например, доступ способен заблокировать веб-сервер еще до запуска PHP.
Поэтому диагностировать сайт только через CMS иногда недостаточно.
Что значит отсутствие запроса в access log
Иногда самая полезная находка состоит не в наличии записи, а в ее отсутствии.
Представим, что пользователь сообщает об ошибке в 12:10 и предоставляет свой IP. Вы проверяете журнал веб-сервера, но запросов от него в это время вообще нет.
Это повод искать проблему раньше в цепочке. Запрос мог не добраться до исходного сервера из-за DNS, CDN, firewall, сетевой маршрутизации или другого промежуточного компонента.
Если же нужный запрос присутствует и рядом указан код 403, известно уже гораздо больше: веб-сервер обращение получил и отказал в доступе.
При 500 запрос тоже дошел до серверной части, но завершился внутренней ошибкой.
Таким образом, access log помогает ответить на первый важный вопрос: видел ли сервер проблемный запрос вообще.
Почему при CDN картина становится сложнее
Если перед сайтом работает CDN, reverse proxy или система защиты, посетитель может сначала обращаться не непосредственно к вашему серверу.
В результате в журнале исходного сервера вместо IP посетителя иногда отображается адрес промежуточной инфраструктуры. При правильной конфигурации реальный IP может передаваться в специальных заголовках и корректно записываться веб-сервером, но это зависит от настройки.
Кроме того, часть запросов CDN способен обслужить самостоятельно из кэша. Тогда обращение вообще не попадет в access log исходного сервера.
Поэтому при использовании такой инфраструктуры нужно учитывать журналы и диагностические возможности самого CDN или защитного сервиса.
Отсутствие запроса на исходном сервере в этой архитектуре еще не означает, что пользователь его не отправлял.
Логи помогают находить не только ошибки
Журналы доступа полезны и тогда, когда сайт формально работает.
Например, можно заметить огромное количество запросов к одному адресу, множество обращений к несуществующим страницам, постоянные попытки открыть административные пути или необычную активность отдельных клиентов.
Если сервер неожиданно начал испытывать нагрузку, access log помогает понять, какие запросы в этот момент поступают чаще всего.
Представим, что одна страница каталога вызывается сотни раз за короткий период и каждый запрос запускает тяжелую обработку. График CPU показывает только высокую нагрузку. Журнал доступа способен показать, откуда она появилась.
Но не стоит превращать любой необычный IP в доказательство атаки. Поисковые роботы, мониторинг, интеграции, API и обычные посетители тоже создают запросы. Сначала нужно оценивать поведение, а не делать вывод только по адресу.
Большой лог не нужно читать целиком
На посещаемом сайте журнал быстро становится огромным. Правильный подход заключается не в чтении, а в фильтрации.
Искать можно по времени, конкретному URL, IP, HTTP-коду или фрагменту сообщения об ошибке.
Если проблема возникает только на странице /checkout/, запросы к изображениям, главной странице и тысячам других адресов сейчас неинтересны.
Если поддержка сообщает о серии 500, можно сначала отфильтровать соответствующие ответы и посмотреть, какие URL чаще всего с ними связаны.
Если известен IP пользователя, поиск по нему поможет восстановить последовательность его запросов.
Чем точнее сформулирован вопрос к журналу, тем быстрее находится полезная запись.
Не каждая красная строка объясняет проблему
Это важная ловушка. В журналах работающего сайта почти всегда можно найти предупреждения и ошибки, которые никак не связаны с текущим инцидентом.
Старый бот запрашивает несуществующий файл и получает 404. Плагин периодически создает предупреждение, которое годами не мешает работе. Кто-то пытается открыть случайный адрес панели управления.
Если в момент сбоя открыть журнал и выбрать первое страшно выглядящее сообщение, легко начать исправлять совершенно другую проблему.
Связь нужно подтверждать. Совпадает ли время? Относится ли запись к нужному домену? Возникает ли она при повторении ошибки? Исчезает ли после исправления предполагаемой причины?
Хорошая диагностика строится не на поиске любой ошибки, а на поиске события, которое соответствует наблюдаемому поведению сайта.
Почему нельзя бездумно удалять журналы
Логи занимают место, поэтому возникает естественное желание периодически удалять их вручную. На VPS это может привести к неприятным последствиям, если не понимать, как конкретная служба работает с открытым файлом журнала.
Обычно для журналов используют ротацию. Старый файл архивируется или переименовывается, создается новый, а устаревшие архивы постепенно удаляются согласно правилам хранения.
На виртуальном хостинге этим часто занимается сам провайдер.
Если журналы внезапно разрослись и заняли значительную часть диска, полезнее сначала выяснить причину. Возможно, приложение записывает одну и ту же ошибку тысячи раз. Простое удаление файла освободит место, но он быстро вырастет снова.
Особенно опасно отключать логирование полностью только ради экономии диска. При следующем сбое можно остаться без главного источника диагностической информации.
Что не должно попадать в логи
Журнал способен содержать чувствительную информацию, поэтому относиться к нему как к обычному текстовому файлу не стоит.
Приложение не должно без необходимости записывать пароли, секретные ключи, токены доступа, платежные данные и другую конфиденциальную информацию.
Опасность существует и при отправке журнала постороннему специалисту. Перед публикацией файла на форуме или передачей неизвестному человеку нужно проверить его содержимое и удалить чувствительные данные.
Для обращения в поддержку собственного хостинг-провайдера обычно достаточно нужного фрагмента, времени события, адреса страницы и описания проблемы. Отправлять гигантский архив всех журналов без запроса поддержки чаще всего нет необходимости.
Как правильно искать причину ошибки по логам
Рабочая схема выглядит проще, чем может показаться.
- Воспроизведите проблему и запишите точное время.
- Определите страницу или действие, которое вызывает ошибку.
- Найдите соответствующий запрос в access log.
- Посмотрите HTTP-код ответа.
- Проверьте error log за тот же промежуток времени.
- Если используется PHP или отдельное приложение, проверьте его журнал.
- Сопоставьте сообщения по времени и URL.
- Проверьте, повторяется ли найденная ошибка при повторном запросе.
- Исправляйте только компонент, на который указывают собранные данные.
- После изменения снова воспроизведите ситуацию и проверьте журнал.
Последний пункт особенно важен. Если после изменения ошибка исчезла, а запрос теперь возвращает нормальный ответ, появляется причинно-следственная связь. Если ничего не изменилось, значит гипотеза была неверной и нужно продолжать поиск.
Что отправить технической поддержке
Логи позволяют сформулировать обращение намного точнее, чем сообщение сайт не работает.
Укажите домен, проблемный URL, приблизительное время сбоя и действия, после которых возникает ошибка. Если известен код ответа, добавьте его. Приложите небольшой фрагмент журнала, относящийся к событию, если он доступен.
Например, поддержке значительно проще работать с описанием: при открытии страницы оформления заказа около 14:35 сервер возвращает 500, ошибка повторяется из разных сетей, в журнале PHP в это же время появляется сообщение из конкретного файла.
Специалист уже знает, что запрос до сервера доходит, видит время события и получает направление для проверки.
На виртуальном хостинге это особенно полезно, поскольку часть системных журналов пользователю недоступна. Поддержка сможет сопоставить предоставленное время с данными, которые видны только на стороне провайдера.
Когда логов недостаточно
Журналы не являются универсальным ответом на любую проблему. Они показывают только то, что конкретный компонент решил записать.
Если сервер внезапно потерял питание или виртуальная машина полностью зависла, приложение может просто не успеть оставить полезное сообщение. Если запрос заблокирован до веб-сервера, его не будет в access log сайта. Если настроено слишком скудное логирование, важной информации тоже может не оказаться.
Поэтому логи нужно сочетать с мониторингом ресурсов, проверкой доступности, состоянием служб и данными панели хостинга.
Но при обычных ошибках сайта именно журнал часто оказывается самым коротким путем к причине. Он позволяет заменить догадки последовательностью событий: запрос пришел, сервер его принял, приложение попыталось выполнить действие и на конкретном этапе возникла ошибка.
Когда владелец сайта начинает смотреть на логи именно так, непонятное сайт сломался превращается в гораздо более полезное описание: какой запрос не сработал, когда это произошло, какой компонент его обрабатывал и что тот сообщил в момент сбоя. А конкретную проблему исправить намного проще, чем неизвестную.
