Как правильно читать access.log и error.log, если сайт регулярно падает

Когда сайт внезапно перестает открываться, а браузер встречает белым экраном или ошибками 502 Bad Gateway и 504 Gateway Time-out, интуитивные попытки перезагрузить сервер редко решают проблему надолго. Сайт поднимается, работает 10–15 минут и падает снова.

Служба поддержки хостинга в таких случаях часто ограничивается отпиской: «Проблема на стороне вашего программного обеспечения, разбирайтесь со скриптами». В этот момент единственный объективный источник правды – журналы веб-сервера.

Главное – понимать разделение зон ответственности:

• access.log (журнал доступа) отвечает на вопрос: кто, когда и с какой интенсивностью запрашивал страницы сайта?
• error.log (журнал ошибок) отвечает на вопрос: почему сервер или программная среда не смогли обработать поступивший запрос?

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

Где лежат журналы и как к ним безопасно подступиться

В подавляющем большинстве веб-проектов на базе Linux инфраструктура строится вокруг веб-сервера Nginx (в роли внешнего прокси) и связки Apache или PHP-FPM на бэкенде.

Стандартные пути размещения журналов:

• Nginx: /var/log/nginx/access.log и /var/log/nginx/error.log
• Apache: /var/log/apache2/ (в Debian/Ubuntu) или /var/log/httpd/ (в CentOS/AlmaLinux)
• Панели управления (Fastpanel, ISPmanager, cPanel): журналы выносятся в домашнюю директорию конкретного пользователя, например: /var/www/username/data/logs/ или /home/username/logs/.

Главная ошибка при падении сервера – пытаться открыть файл журнала текстовыми редакторами nano, vi или скачивать его целиком через FTP/SFTP. Если ресурс находится под атакой или сайт сбоит давно, размер файла может составлять 5–10 ГБ. Попытка открыть его «в лоб» приведет к мгновенному исчерпанию оперативной памяти и зависанию операционной системы.

Для безопасной работы в консоли используют потоковые утилиты:

• Просмотр последних 50 записей:

tail -n 50 /var/log/nginx/error.log

• Отслеживание новых ошибок в режиме реального времени:

tail -f /var/log/nginx/error.log

• Выборка записей за конкретный час без загрузки файла в память:

grep "09/Sep/2026:12:" /var/log/nginx/access.log | head -n 30

Анатомия строки access.log: читаем по полочкам

По умолчанию веб-сервер Nginx использует комбинированный формат записи (combined). Каждая строчка в файле – это один завершенный HTTP-запрос к вашему серверу.

Типичная запись в журнале выглядит так:

192.0.2.45 - - [09/Sep/2026:12:15:32 +0300] "GET /catalog/filter/?price_min=1000 HTTP/1.1" 200 45120 "https://example.com/catalog/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

Разберем параметры по порядку:

• 192.0.2.45 – IP-адрес источника запроса. По нему вычисляют ботов, парсеры и распределенные атаки. Если сайт работает за прокси (например, Cloudflare), без настройки модуля real_ip здесь будет отображаться IP самого сервиса проксирования.
• [09/Sep/2026:12:15:32 +0300] – точное время фиксации события с часовым поясом.
• "GET /catalog/filter/?price_min=1000 HTTP/1.1" – метод (GET/POST), запрашиваемый адрес и версия протокола. Здесь сразу видны подозрительные вызовы вроде обращений к системным файлам (wp-login.php, xmlrpc.php, .env) или «тяжелые» динамические фильтры.
• 200 – код ответа сервера. Критически важный параметр при диагностике:
• 200, 301, 304 – нормальная штатная работа.
• 499 (специфичный код Nginx) – клиент разорвал соединение, не дождавшись ответа. Верный признак того, что скрипты бэкенда выполняются слишком долго.
• 500, 502, 504 – внутренние ошибки бэкенда и тайм-ауты шлюза.
• 45120 – размер переданного ответа в байтах (без учета заголовков). Позволяет отследить аномальную отдачу огромных файлов скриптами вместо статической раздачи.
• "[https://example.com/catalog/](https://example.com/catalog/)" – страница-источник перехода (Referer).
• "Mozilla/5.0..." – строка идентификации клиента (User-Agent). Позволяет быстро отсеять добросовестных поисковых роботов (Яндекс, Google) от самописных сканеров на Python (python-requests), утилит curl или парсеров без указания браузера.

Экспресс-диагностика access.log консольными командами

Когда сайт лежит, читать журнал построчно вручную бесполезно: в секунду могут фиксироваться сотни обращений. Для быстрой локализации проблемы применяют комбинации стандартных утилит Linux: awk, sort, uniq и head.

1. Выявление топ-10 IP-адресов по числу запросов

Позволяет за пару секунд понять, идет ли на сайт атака или агрессивный парсинг с конкретных хостов:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10

Если в выводе один IP совершил десятки тысяч обращений за короткий промежуток времени – перед вами главный кандидат на блокировку в сетевом экране.

2. Топ запрашиваемых адресов (URL)

Команда показывает, какие именно страницы или скрипты генерируют основную нагрузку:

awk -F'"' '{print $2}' /var/log/nginx/access.log | awk '{print $2}' | sort | uniq -c | sort -nr | head -n 10

Если в топе висят не главная страница или карточки товаров, а внутренний поиск по сайту (/search/) или множественные вызовы скрипта авторизации, сервер падает из-за перегрузки базы данных.

3. Анализ подозрительных строк User-Agent

Помогает отследить автоматические системы сканирования и мусорных ботов:

awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10

Запросы с пустыми строками, а также содержащие AhrefsBot, SemrushBot, MJ12bot, Python-urllib или curl, при дефиците ресурсов сервера безопаснее временно заблокировать.

4. Подсчет запросов с кодами ошибок 5xx

Команда группирует адреса, обращение к которым привело к системным сбоям:

awk '($9 ~ /^5/) {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10

Чтение error.log: расшифровка критических ошибок

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

1. upstream timed out (110: Connection timed out) while reading response header from upstream

• Что означает: веб-сервер Nginx принял входящий запрос пользователя и передал его бэкенду (PHP-FPM, Node.js или Python), но тот не уложился в установленный лимит ожидания (обычно 60 секунд) и не вернул заголовки. В браузере пользователя это отображается как 504 Gateway Time-out.
• Причина: зависший SQL-запрос к базе данных, медленный внешний API стороннего сервиса (служба доставки, платежный шлюз) либо нехватка мощностей процессора для генерации страницы.

2. connect() to unix:/var/run/php/php-fpm.sock failed (11: Resource temporarily unavailable)

• Что означает: очередь запросов переполнена. Nginx пытается передать соединение через сокет обработчику PHP, но тот не принимает новые вызовы. Пользователь видит ошибку 502 Bad Gateway.
• Причина: Исчерпание пула рабочих процессов (pm.max_children). Все доступные воркеры PHP заняты выполнением медленных задач.

3. Out of memory / kernel: [xxx] Killed process

• Что означает: в системном журнале ядра (/var/log/messages или через команду dmesg) появляется отметка о срабатывании механизма OOM Killer. Службы базы данных (MySQL / MariaDB) или веб-сервера внезапно останавливаются.
• Причина: полное исчерпание физической оперативной памяти (RAM). Чтобы предотвратить крах всей операционной системы, ядро Linux принудительно завершает самый ресурсоемкий процесс – чаще всего СУБД.

4. directory index of "/var/www/site/" is forbidden

• Что означает: ошибка 403 Forbidden. Сервер не находит индексный файл (index.php, index.html) или не имеет прав на чтение директории от имени системного пользователя (www-data или nginx).

От диагностики к системному решению

Логи дают точный вектор действий:

• Если в access.log аномальный наплыв ботов: заблокируйте проблемные IP-адреса через системный экран iptables/ufw или пропишите запрет в секции server конфигурации Nginx:

if ($http_user_agent ~* (SemrushBot|AhrefsBot|MJ12bot)) {

return 403;

}

• Если в error.log фиксируются таймауты upstream: включите журнал медленных запросов в MySQL (slow_query_log = 1), чтобы оптимизировать тяжелые выборки, и настройте кэширование динамических страниц в Redis или Memcached.
• Если сбои вызваны дефицитом аппаратных ресурсов: когда код оптимизирован, кэш включен, а в логах регулярно появляются Resource temporarily unavailable и срабатывания OOM Killer при росте живого трафика, сервер уперся в физический потолок.

Краткая памятка: 3 команды при экстренном падении

Если сайт перестал открываться прямо сейчас, выполните в терминале:

1. uptime – покажет среднюю загрузку процессора (Load Average) за 1, 5 и 15 минут.
2. free -m – покажет реальный остаток свободной оперативной памяти и объем раздела подкачки (swap).
3. tail -n 20 /var/log/nginx/error.log – выведет первопричину текущего отказа.

Сталкивались ли вы с неожиданными записями в логах при падении своих сайтов? Какие ошибки в error.log доставляли больше всего проблем при отладке? Поделитесь своим опытом в комментариях.