Сайт начал выдавать ошибку, страницы стали открываться медленнее или посетители жалуются на проблему, которую вам никак не удается повторить. Можно обновлять плагины, очищать кеш, перезапускать сервер и надеяться, что все пройдет. Но гораздо полезнее сначала посмотреть, что происходило с сайтом в момент сбоя.
Для этого существуют логи. В них веб-сервер, приложение и другие компоненты записывают информацию о своей работе. По журналам можно увидеть, какой адрес запрашивал посетитель, какой ответ отправил сервер, когда возникла ошибка и иногда даже какой файл или скрипт стал ее причиной.
Новичка лог легко пугает. Открываешь файл и видишь сотни строк с IP-адресами, датами, кодами, путями и непонятными сообщениями. Кажется, что разобраться в этом способен только системный администратор. На практике для диагностики обычного сайта достаточно понимать несколько основных вещей и не пытаться читать журнал целиком от первой строки до последней.
Лог полезнее воспринимать не как книгу, а как запись событий. Вы знаете приблизительное время проблемы, находите этот момент и смотрите, что сервер записал рядом.
Какие логи бывают у сайта и где их искать
Для начала важно понять, что единого файла со всей историей сайта обычно не существует. Записи создают разные компоненты, поэтому место поиска зависит от характера проблемы.
Два наиболее полезных журнала веб-сервера называются access log и error log.
Access log хранит информацию о запросах. Когда браузер открывает страницу, загружает изображение или обращается к другому ресурсу, веб-сервер может записать это событие. В журнале обычно можно увидеть IP-адрес клиента, время запроса, запрошенный URL, HTTP-метод, код ответа и объем переданных данных. В зависимости от конфигурации туда добавляются адрес страницы, с которой пришел пользователь, браузер и другая информация.
Error log предназначен прежде всего для сообщений о проблемах самого веб-сервера и связанных с ним процессов. Именно сюда часто стоит смотреть, когда вместо страницы появляется ошибка 500, сервер не может прочитать файл, неправильно работает конфигурация или запрос не удается обработать ожидаемым способом.
Названия и расположение журналов зависят от сервера и хостинга.
На VPS с Nginx стандартные журналы часто находятся в каталоге /var/log/nginx/. У Apache на распространенных Linux-системах их можно встретить в /var/log/apache2/ или другом каталоге, заданном конфигурацией.
Это не универсальные пути. Администратор может настроить отдельный файл для каждого сайта или вообще изменить расположение журналов.
На обычном виртуальном хостинге искать файлы через системные каталоги чаще всего не требуется. Провайдер может показывать журнал запросов и ошибок непосредственно в панели управления. Иногда доступны готовые отчеты, иногда сами файлы для просмотра или скачивания.
Кроме журналов веб-сервера могут существовать логи PHP, CMS, отдельных плагинов, базы данных и других компонентов.
Например, веб-сервер способен сообщить лишь о том, что приложение вернуло ошибку. Настоящая причина при этом находится в журнале PHP или самой CMS. Поэтому error log веб-сервера не всегда дает окончательный ответ, но часто подсказывает, куда двигаться дальше.
WordPress тоже умеет записывать отладочную информацию, если соответствующий режим включен. Использовать его постоянно на рабочем сайте без необходимости не стоит. Подробное логирование способно создавать большие файлы, а неправильная настройка вывода ошибок может показать посетителям техническую информацию, которую им видеть не нужно.
Поэтому сначала ищите уже доступные журналы хостинга. Если их недостаточно, включайте дополнительную диагностику осознанно и после решения проблемы возвращайте настройки в нормальное состояние.
Как понять строку access log
Формат журнала может отличаться, но обычная запись выглядит примерно так:
192.0.2.25 — — [28/Aug/2026:14:35:18 +0300] «GET /catalog/ HTTP/1.1» 200 18452
На первый взгляд это набор символов. Если разделить строку на части, она становится намного понятнее.
В начале находится IP-адрес клиента. Это не обязательно конкретный человек. Запрос мог сделать поисковый робот, сервис мониторинга, программа, прокси или другой автоматизированный клиент.
Далее указано время события. Для диагностики это одна из самых ценных частей строки.
Если пользователь говорит, что около 14:35 не мог открыть каталог, можно искать события именно в этот период вместо просмотра тысяч запросов за весь день.
Затем идет сам запрос. GET означает получение ресурса, а /catalog/ показывает, какой адрес запрашивался.
После него находится HTTP-код ответа. В нашем примере это 200, то есть запрос был успешно обработан.
Именно коды часто позволяют быстро увидеть общую картину.
- 200 обычно означает успешный ответ;
- 301 и 302 показывают перенаправление;
- 403 означает, что доступ к ресурсу запрещен;
- 404 сообщает, что запрошенный ресурс не найден;
- 500 указывает на внутреннюю ошибку сервера или приложения;
- 502 часто возникает, когда веб-сервер не получил нормальный ответ от следующего компонента;
- 503 говорит о временной недоступности сервиса;
- 504 связано с превышением времени ожидания ответа от другого сервиса.
Сам код еще не объясняет причину. Он только показывает результат обработки запроса.
Например, 404 может означать действительно удаленную страницу, неправильную ссылку или проблему с маршрутизацией. Поэтому после обнаружения кода нужно смотреть на URL и сопоставлять его с тем, что должно происходить на сайте.
В конце строки обычно указывается объем ответа. В расширенном формате могут присутствовать дополнительные поля.
Особенно полезен User-Agent. Он помогает понять, кто сделал запрос. Там может быть указан обычный браузер, поисковый робот или название автоматизированного клиента. Однако полностью доверять этой строке нельзя, поскольку клиент способен передать произвольное значение.
Поле Referer, если оно записывается, показывает адрес, с которого был совершен переход. Оно может помочь найти внутреннюю страницу с битой ссылкой.
Представим, что в журнале регулярно появляется запрос к /images/banner-old.jpg с ответом 404. Самой страницы с таким адресом на сайте нет, потому что это изображение. Если рядом доступна информация об источнике запроса, можно обнаружить страницу, которая продолжает ссылаться на давно удаленный файл.
Access log полезен не только при ошибках.
Он способен показать необычно частые обращения к одному URL, множество запросов с одного адреса, активность роботов и другие события, которые создают нагрузку. Но здесь важно не делать поспешных выводов.
Большое количество строк от одного IP еще не доказывает атаку. Это может быть корпоративная сеть, мониторинг или нормальный робот. Лог дает факты о запросах, а их смысл приходится определять в контексте.
Что искать в error log когда сайт перестал работать
Если access log отвечает в основном на вопрос, что запрашивали и какой результат получили, error log гораздо чаще помогает понять, что пошло не так.
Допустим, после обновления сайт начал возвращать 500. В журнале запросов вы увидите сам код 500, но причина может находиться в error log.
Там встречаются сообщения о проблемах с файлами, правах доступа, конфигурацией, соединением с приложением и множестве других событий.
Главное правило остается прежним: ищите время возникновения проблемы.
Если сайт сломался в 16:10 после обновления плагина, записи трехдневной давности сейчас почти наверняка менее интересны, чем события между 16:09 и 16:11.
Полезно самостоятельно воспроизвести проблему. Откройте неработающую страницу, запомните точное время и сразу после этого посмотрите последние записи журнала.
Так становится намного проще отделить нужное событие от фонового шума.
Не каждое слово error означает катастрофу. Журналы могут содержать предупреждения, сообщения об отсутствующих необязательных файлах и старые события, которые вообще не связаны с текущей неисправностью.
Поэтому важна последовательность событий.
Например, посетитель открывает страницу. В access log появляется запрос и ответ 500. В error log в ту же секунду возникает сообщение о сбое PHP. Теперь уже стоит переходить к журналу PHP или приложения и искать подробности там.
Другой пример связан с правами доступа. Сервер знает, где находится файл, но процесс веб-сервера не имеет права его прочитать. В журнале может появиться соответствующее сообщение, после чего становится понятно, что смена DNS или очистка кеша здесь вообще ни при чем.
При проблемах с PHP можно встретить сообщения разных уровней. Fatal error обычно означает ошибку, из-за которой выполнение скрипта продолжить невозможно. Warning предупреждает о проблеме, но не обязательно останавливает работу. Deprecated сообщает об использовании возможности, которая считается устаревшей и может стать проблемой при дальнейших обновлениях.
После обновления версии PHP такие записи особенно полезны. Старый плагин или тема могут использовать несовместимый код, и журнал способен указать конкретный файл, в котором произошел сбой.
При этом не стоит автоматически редактировать файл, который назван последним.
Он может быть лишь местом, где проявилась проблема, а настоящая причина находится раньше. Если сообщение содержит стек вызовов, его следует рассматривать как цепочку выполнения, а не просто выбирать последнюю строчку.
Для владельца сайта важнее всего получить из журнала несколько фактов: когда произошла ошибка, какой запрос ее вызвал, какой компонент сообщил о проблеме и какой файл или процесс упоминается.
Этого часто достаточно, чтобы сформулировать нормальный запрос в техническую поддержку или передать разработчику конкретную информацию вместо фразы сайт иногда не работает.
Как использовать логи для реальной диагностики сайта
Самый эффективный способ работы с журналами начинается не с их чтения, а с правильно поставленного вопроса.
Допустим, посетитель сообщает, что форма заказа не работает.
Сначала уточните время проблемы и страницу. Затем попробуйте повторить действие самостоятельно. Если ошибка повторилась, запомните время до секунды или хотя бы до минуты.
Теперь откройте access log и найдите запросы к нужному адресу. Посмотрите код ответа. Если сервер возвращает 200, это еще не гарантирует, что форма действительно сработала. Страница могла успешно открыться, а ошибка возникла уже внутри логики приложения.
Тогда проверяйте журналы PHP, CMS или конкретного модуля.
Если сервер отвечает 500, одновременно смотрите error log.
Если приходит 404, проверяйте правильность адреса и маршрутизацию.
При 403 интересуют правила доступа, защита сайта, права на файлы и конфигурация веб-сервера.
Такой подход намного эффективнее, чем просто искать в огромном файле слово error.
Логи помогают и при медленной работе.
Если сервер внезапно начал испытывать высокую нагрузку, access log позволяет увидеть, не запрашивает ли кто-нибудь одну и ту же тяжелую страницу тысячи раз. Можно обнаружить активного робота, неправильно настроенный внешний сервис или собственный скрипт, который зациклился и постоянно обращается к сайту.
Но для диагностики производительности одного access log недостаточно. Его нужно сопоставлять со статистикой CPU, оперативной памяти, базы данных и временем выполнения запросов. Сам факт большого числа обращений еще не объясняет, почему сервер не справляется.
Есть и еще одна практическая польза. Журналы позволяют проверить, происходило ли событие вообще.
Например, внешний сервис утверждает, что отправил запрос к вашему сайту. Если в access log в указанное время ничего похожего нет, проблема могла возникнуть еще до веб-сервера. Если запрос присутствует и получил 500, искать нужно уже на вашей стороне.
При переносе сайта журналы тоже помогают отделить проблемы DNS от проблем приложения. Если вы открываете новый сервер и видите свой запрос в его access log, значит обращение до сервера дошло. Дальше можно разбираться с веб-сервером и сайтом.
Важно помнить о конфиденциальности.
В журналах могут оказаться IP-адреса, URL, технические параметры и другие данные. Приложение не должно без необходимости записывать пароли, секретные ключи, токены авторизации и содержимое чувствительных запросов.
Логи также нельзя хранить бесконечно просто потому, что когда-нибудь пригодятся. На активном проекте они способны быстро занимать место. Нормальная серверная конфигурация предусматривает ротацию журналов, при которой старые файлы архивируются или удаляются согласно заданной политике.
Если на виртуальном хостинге вы заметили огромный лог, который постоянно растет, не ограничивайтесь его удалением. Сначала выясните, почему он стал таким большим. Возможно, приложение непрерывно записывает одну и ту же ошибку, и после удаления файла он снова заполнит диск.
При обращении в поддержку тоже не нужно отправлять весь журнал за несколько месяцев.
Гораздо полезнее сообщить адрес страницы, время возникновения проблемы, последовательность действий и несколько относящихся к событию строк. Если специалисты попросят полный файл, его можно предоставить отдельно.
И не публикуйте логи целиком на форумах и в открытых чатах, предварительно не посмотрев их содержимое. В технической информации могут оказаться данные, которые не предназначены для посторонних.
Освоить журналы сайта на базовом уровне проще, чем кажется. Начните с времени события, найдите нужный запрос в access log, посмотрите HTTP-код и затем проверьте error log или журнал приложения в ту же минуту. Не пытайтесь расшифровать все строки подряд.
Со временем набор непонятных символов превращается в последовательность вполне логичных событий: посетитель запросил страницу, сервер попытался ее обработать, приложение столкнулось с проблемой и записало причину.
Именно в этом главная ценность логов. Они не исправляют сайт сами, зато позволяют перестать гадать. Вместо десятка случайных действий вы получаете конкретную зацепку и можете исправлять уже настоящую причину сбоя.
