Когда сайт лёг, форма перестала отправляться или хостинг пишет о перегрузке, первым делом смотрят логи. Это простые текстовые файлы, и прочитать их может не только администратор, но и владелец сайта - если знать, куда смотреть.
Логи никто не читает, пока всё работает. А когда сайт падает вечером в пятницу, разработчик не отвечает, а клиенты уже звонят, за дело берётся сам владелец - и упирается в файл на несколько тысяч строк без единой подсказки, что в нём важно. Дальше - какие логи бывают, как устроена одна строка и что в ней означает тревогу, а что обычную работу сайта.
Какие логи бывают и где их искать
У сайта одновременно пишется несколько логов, и каждый отвечает на свой вопрос.
Лог обращений (access log) - запись о каждом запросе к серверу: кто зашёл, на какую страницу и с каким результатом.
Лог ошибок сервера (error log) - сбои на уровне сервера: нехватка памяти, обрыв соединения, таймаут при обращении к базе.
Лог ошибок PHP - ошибки в коде сайта или движка: неопределённая функция, конфликт двух плагинов после обновления.
Почтовый лог - фиксирует, ушло ли письмо с формы или его отклонил сервер получателя.
Лог CMS - WordPress и Bitrix ведут свой журнал: неудачные входы в админку, ошибки обновлений.
Лог панели хостинга - часть этих данных дублируется в разделе статистики, для тех, у кого нет SSH.
На хостингах с панелью логи обычно лежат в папке logs рядом с сайтом или открываются кнопкой "Статистика" либо "Логи". По SSH типичные пути похожи на /var/log/nginx/access.log - точное расположение проще спросить у поддержки, чем угадывать.
Как устроена строка лога обращений
Одна строка access log содержит: IP-адрес, дату и время с точностью до секунды, метод запроса (GET - открыл страницу, POST - отправил форму), адрес страницы, код ответа, размер ответа в байтах, откуда пришёл переход и user-agent - строку, которой браузер или робот представляется серверу.
Выглядит это так:
93.171.х.х - - [08/Nov/2026:11:42:07 +0300] "GET /prices/ HTTP/1.1" 200 18420 "https://yandex.ru/" "Mozilla/5.0 ..."
Уже из одной строки видно: кто-то пришёл из Яндекса, открыл страницу с ценами, сервер ответил кодом 200 - отдал страницу без ошибок. Вместо 200 бывает 500, 403 или 404, и это та самая тревога, которую ищут в первую очередь.
Коды ответа, которые сигналят о беде
Код 500 на своих страницах. Сервер пытался отдать страницу и не смог. Если 500-е повторяются на одном адресе, причину ищут в error log и PHP-логе за то же время - там обычно есть подробность, которой нет в access log. Если сайт лёг целиком, порядок действий шире, он разобран в статье Сайт не работает: 9 причин и пошаговая диагностика.
Всплеск 404 после переезда. Старые адреса остались в поиске и закладках, и лог покажет всплеск "страница не найдена" именно на них. Решение - настроить редиректы со старых адресов на новые.
Код 403 у поисковых роботов. Если YandexBot или Googlebot регулярно получают 403, это причина падения позиций в поиске, которую редко связывают с логами. Обычно дело в блокировке на уровне сервера или в защите от ботов, которая принимает их за подозрительный трафик.
Как найти причину: время инцидента и характер трафика
Первый шаг - сузить лог до нужного окна времени, а не листать всё подряд: это как сначала убрать из стога лишнее сено, а потом уже искать иголку. Если клиент написал "лёг в районе двух часов дня", смотрят строки с 13:45 до 14:15. Тем же принципом пользуется мониторинг: он фиксирует время падения по алерту, и это готовая точка отсчёта для поиска в логе - если он настроен заранее (подробнее - в статье про мониторинг доступности сайта).
Второй шаг - оценить характер трафика в этом окне. Резкий рост запросов бывает по двум причинам.
Наплыв реальных посетителей. Разные IP и user-agent, посетители заходят на разные страницы, доходят до корзины и оформления заказа. Хорошая проблема: сервер не справляется с популярностью, решение - на стороне хостинга или кэша.
Парсер или атака под видом посетителей. Узкий диапазон IP или один и тот же user-agent, запросы идут на несколько адресов с машинной скоростью, робот игнорирует robots.txt. Если похоже на целенаправленную перегрузку, дальше по теме статья Защита сайта от DDoS: что реально помогает.
Лог ошибок PHP: типовая запись после неудачного обновления
Типичная находка после обновления плагина выглядит так:
PHP Fatal error: Uncaught Error: Call to undefined function old_function() in /wp-content/plugins/имя-плагина/файл.php on line 42
Расшифровка простая: код вызывает функцию, которой больше нет - новая версия плагина её убрала, а старый код на сайте всё ещё на неё ссылается. Сайт в этот момент показывает белый экран или 500 вместо страницы.
Лечится это откатом: через FTP переименовывают папку плагина, например добавляют "_old" к названию, - сайт оживает сразу, а разбираться с обновлением можно без спешки. Резервная копия перед обновлением - привычка, которая экономит такие вечера.
Команды для SSH и то же самое кнопками в панели
Для тех, у кого есть доступ по SSH, разбор ускоряют простые команды.
| Задача | Команда в SSH | Аналог в панели хостинга |
|---|---|---|
| Смотреть лог в реальном времени | tail -f access.log | обновлять вкладку "Логи" вручную |
| Найти все ошибки 500 | grep " 500 " access.log | фильтр по коду ответа в разделе логов |
| Сузить лог до окна времени | grep "08/Nov/2026:14:0" access.log | фильтр по дате и времени, если он есть |
| Скачать файл лога целиком | команда scp с сервера | кнопка "Скачать" рядом с файлом лога |
Частых посетителей за инцидент считают с помощью связки awk, sort и uniq - три стандартные утилиты передают вывод друг другу по конвейеру, и готовую команду проще скопировать из справки хостинга, чем набирать по памяти.
Без SSH все эти задачи закрывает панель хостинга: раздел "Логи" обычно даёт фильтр по дате и коду ответа, а архив скачивается одной кнопкой. Устроено это по-разному от хостинга к хостингу - при выборе площадки стоит проверить заранее, насколько удобны логи и статистика, разбор в статье Как выбрать хостинг для сайта в 2026: 12 критериев.
Про ротацию забывают чаще всего. Логи обычно хранятся от 7 до 30 дней, потом архивируются или удаляются. Если инцидент важен, лог лучше скачать сразу после сбоя, а не через неделю, когда нужный кусок уже вычищен.
Что логировать самому и почему нельзя писать личные данные
Кроме серверных логов полезно вести свой минимальный журнал: отправок форм и ответов платёжного шлюза. Он закрывает споры "форма не работает" или "деньги списались, а заказа нет" за минуту вместо звонков в техподдержку.
Правильный объём записи - факт и статус, а не содержимое. Для формы это время отправки, страница и код ответа; для оплаты - время, статус и номер транзакции. Имя, телефон, почта и текст сообщения в такой журнал не попадают.
Файл лога обычно лежит без шифрования и без ограничений по правам доступа, и персональные данные в нём - лишняя точка утечки, за сохранность которой отвечает оператор данных по 152-ФЗ. Проще не собирать лишнее, чем потом объяснять, откуда в незащищённом файле взялись телефоны клиентов.
Пять шагов по логам, когда сайт лёг
- Зафиксировать точное время сбоя - по жалобе клиента или по алерту системы мониторинга, если она настроена заранее.
- Открыть error log сервера и PHP-лог за это окно времени и найти первую ошибку в цепочке, а не последнюю: именно первая обычно и есть причина.
- Проверить access log на код 500 на тех же адресах и на резкий рост числа запросов перед падением.
- Сверить время сбоя с недавними изменениями: обновление плагина, деплой новой версии, смена настроек DNS.
- Если причина не находится за 15-20 минут, писать в поддержку хостинга с точным временем и цитатой строки из лога - это сокращает разбор с часов до минут.
Логи как привычка, а не как чтение в момент паники
Логи не чинят сайт сами по себе - они экономят самое дорогое во время аварии: время на понимание, что произошло. Разница между "сайт не работает, помогите" и "с 14:05 до 14:12 сервер отдавал 500 на странице оформления заказа после обновления плагина оплаты" - это разница между часом разбора и пятью минутами.
Иногда заглядывать в error log полезно и без жалоб: часть проблем видна за несколько дней до того, как её замечают посетители. Тот же принцип лежит в основе базовой защиты сайта, разобранной в статье Как защитить сайт от взлома: 14 правил.
Если интересно, как похожие ситуации разбирали на реальных проектах, в кейсах есть истории с конкретными цифрами и тем, что чинили после сбоя.
