Логи Nginx: где искать и как читать ошибки сервера

Если сайт отдал 502, медленно открывается или внезапно начал возвращать 404, ответ обычно уже записан в логах Nginx. В типичной Linux-установке искать нужно в /var/log/nginx/access.log и /var/log/nginx/error.log, но реальные пути задаёт конфигурация. Ниже — практический порядок для Nginx 1.24–1.27: от поиска файлов до чтения конкретной строки и проверки причины сбоя.

Какие логи есть у Nginx

Nginx обычно пишет два основных журнала. В access.log попадает каждый обработанный запрос: адрес клиента, метод, URI, код ответа и объём переданных данных. В error.log записываются ошибки самого веб-сервера, проблемы с файлами, соединением с приложением и исчерпанием ресурсов.

Последняя строка важна: Nginx может лишь зафиксировать, что приложение закрыло соединение. Подробная причина тогда находится не в error.log, а в журнале PHP-FPM, Gunicorn, uWSGI, Node.js или другого backend-сервиса.

Access.log отвечает на вопрос «что увидел клиент», а error.log — «на каком участке оборвался запрос». Для 5xx почти всегда нужны оба журнала.

Сноска. Upstream — сервер или группа серверов, куда Nginx передаёт запрос: например, процесс PHP-FPM или приложение на 127.0.0.1:3000.

Где находятся файлы

В Debian и Ubuntu часто используются пути /var/log/nginx/access.log и /var/log/nginx/error.log. В CentOS, Rocky Linux и AlmaLinux обычно применяется тот же каталог, но имя файла и место записи могут отличаться. Если Nginx установлен в контейнере, логи нередко направляются в стандартный вывод процесса и доступны через Docker или systemd.

Не угадывайте путь по памяти. Сначала выведите активную конфигурацию:

sudo nginx -T 2>/dev/null | grep -E 'access_log|error_log'

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

sudo nginx -t

Успешная проверка заканчивается сообщением syntax is ok и test is successful. Если у процесса нет прав на чтение конфигурации, запускайте команду через sudo.

Проверка через systemd и Docker

Когда файлов в /var/log/nginx нет, проверьте журнал службы:

sudo journalctl -u nginx --since "1 hour ago"

Для контейнера посмотрите вывод конкретного контейнера:

docker logs --since 1h CONTAINER_NAME

Вместо CONTAINER_NAME подставьте имя или идентификатор контейнера. Если в конфигурации указан путь к файлу, а в Docker используется перенаправление в stdout, искать один и тот же запрос нужно в том месте, куда реально пишет выбранный образ.

Как читать access.log

Формат строки не универсален: его задаёт директива log_format. Часто используется вариант, похожий на Combined Log Format:

203.0.113.17 - - [10/Mar/2025:14:20:11 +0300] "GET /catalog/item-42 HTTP/1.1" 200 18452 "https://example.com/" "Mozilla/5.0"

Эту строку можно разобрать так:

• 203.0.113.17 — адрес клиента, если перед Nginx правильно настроена цепочка прокси;
• GET /catalog/item-42 HTTP/1.1 — метод, путь и версия HTTP;
• 200 — статус ответа;
• 18452 — размер тела ответа в байтах;
• следующее значение — Referer, откуда пришёл запрос;
• последнее значение — User-Agent клиента.

Поля могут быть другими. Например, в собственный формат часто добавляют время обработки запроса, адрес upstream и его статус. Посмотрите определение log_format в выводе nginx -T, прежде чем разбирать столбцы с помощью awk.

Быстрый поиск ошибок по статусу

Для просмотра последних записей используйте режим, который не ломается при ротации файла:

sudo tail -F /var/log/nginx/access.log

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

Найти последние ответы 5xx можно так:

sudo grep -E '" [5][0-9]{2} ' /var/log/nginx/access.log | tail -n 50

Для 4xx используйте похожую проверку:

sudo grep -E '" [4][0-9]{2} ' /var/log/nginx/access.log | tail -n 50

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

Как читать error.log

Строка error.log обычно содержит время, уровень сообщения, идентификатор процесса, адрес клиента, виртуальный сервер и описание проблемы. Например:

2025/03/10 14:22:07 [error] 1234#1234: *81 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.17, server: example.com, request: "GET /api/orders HTTP/1.1", upstream: "http://127.0.0.1:3000/api/orders", host: "example.com"

Ключевой фрагмент здесь — Connection refused: на момент подключения приложение на порту 3000 не принимало соединения. Возможны остановленный процесс, неправильный порт, ошибка bind или фильтрация соединения. Сам Nginx не доказывает, какая именно причина остановила приложение.

Частые сообщения и их смысл

• connect() failed (111: Connection refused) while connecting to upstream. Nginx дошёл до адреса backend, но тот отклонил соединение или не слушал порт.
• upstream timed out. Приложение не ответило в отведённое время. Причина может быть в медленном SQL-запросе, внешнем API, блокировке или слишком маленьком таймауте.
• no live upstreams. В настроенной группе upstream Nginx не видит доступных серверов.
• open() ... failed (2: No such file or directory). Запрошенный файл или каталог отсутствует. Это частая причина 404 при раздаче статики.
• permission denied. Процесс Nginx не может прочитать файл или войти в один из каталогов пути. Проверять нужно права на каждый каталог, а не только на сам файл.
• client intended to send too large body. Размер тела запроса превышает ограничение client_max_body_size, например при загрузке файла.

Как связать строку access.log с ошибкой

Время и URI — первый способ сопоставления записей. Сначала найдите в access.log запрос со статусом 502, 504 или 500, затем откройте error.log за ту же секунду и проверьте адрес upstream.

sudo grep '10/Mar/2025:14:22' /var/log/nginx/access.log
sudo grep '2025/03/10 14:22' /var/log/nginx/error.log

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

Что означают коды 4xx и 5xx

Код 499 — нестандартный код Nginx, который обычно означает закрытие соединения клиентом. Он не доказывает, что сервер исправен: пользователь мог уйти из-за долгого ответа, а причина задержки всё ещё находится в backend.

Где чтение логов ломается

Пустой файл не означает отсутствие запросов. Логи могут быть отключены директивой access_log off;, перенаправлены в другой путь или уже отправлены в систему централизованного сбора. После ротации старые данные находятся в файлах вроде access.log.1 или сжатых архивах.

Есть и другие ловушки:

• за reverse proxy в access.log может отображаться адрес прокси, а не пользователя;
• один запрос к странице порождает дополнительные запросы к CSS, JavaScript, изображениям и API;
• статус 200 не гарантирует, что бизнес-операция прошла успешно: приложение могло вернуть ошибку внутри JSON;
• увеличение уровня error-логирования создаёт больше данных и может повысить нагрузку на диск;
• логи с персональными данными нельзя бесконтрольно передавать подрядчикам и хранить дольше необходимого.

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

Что делать дальше

Сначала найдите активные директивы access_log и error_log, затем воспроизведите один конкретный запрос и проследите его по обоим журналам. После этого добавьте в безопасный формат логирования время обработки и идентификатор запроса, если их ещё нет. На сервере стоит наблюдать не только число 5xx, но и долю 499, время ответа upstream, заполнение диска и рост error.log — именно эти показатели часто предупреждают о сбое раньше жалоб пользователей.