Устранение неполадок Nginx: распространенные решения из командной строки для проблем с веб-сервером

Когда Nginx выходит из строя, первые несколько минут обычно уходят на сужение проблемы. Остановлена ли служба? Не удалось ли изменение конфигурации? Использует ли другой процесс порт 80? Работает ли Nginx нормально, но вышестоящее приложение не отвечает? Командная строка дает быстрые ответы, если выполнять проверки в правильном порядке.

Я предпочитаю начинать с наименее разрушительных команд: проверить статус, протестировать конфигурацию, прочитать журналы и только потом перезагрузить или перезапустить. Перезапуск может скрыть полезные улики, поэтому относитесь к нему как к исправлению только после того, как узнаете, что именно исправляете.

Основные команды управления Nginx

Первым шагом в устранении неполадок часто является проверка состояния самой службы Nginx. В зависимости от вашей операционной системы вы обычно будете взаимодействовать либо с systemd, либо с service (SysVinit).

1. Проверка статуса службы Nginx

Знание того, работает ли Nginx, остановлен или дает сбой, имеет решающее значение. Команда status предоставляет этот обзор.

Использование systemd (распространено на современных дистрибутивах Linux, таких как Ubuntu 16.04+, CentOS 7+):

sudo systemctl status nginx

Ожидаемый вывод (Активен/Работает):

● nginx.service - Высокопроизводительный веб-сервер и обратный прокси-сервер
   Loaded: загружен (/lib/systemd/system/nginx.service; включен; предустановка поставщика: включена)
   Active: active (running) с Вт 2023-10-24 10:00:00 UTC; 1ч назад
     Docs: man:nginx(8)
 Main PID: 1234 (nginx)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/nginx.service
           ├─1234 nginx: master process /usr/sbin/nginx -g daemon on;
           └─1235 nginx: worker process

Если в выводе отображается Active: inactive (dead) или Active: failed, вы знаете, что Nginx в настоящее время не обслуживает трафик. Это не говорит вам, почему. Следующая подсказка обычно находится в тесте конфигурации или системном журнале.

sudo journalctl -u nginx -n 80 --no-pager

Это показывает последние журналы службы, включая ошибки запуска от systemd. Ищите сообщения о неизвестных директивах, отсутствующих файлах сертификатов, ошибках привязки или ошибках разрешений.

2. Запуск, остановка и перезагрузка Nginx

Как только вы определите состояние, вам нужно управлять им. Используйте следующие команды по мере необходимости:

Действие	Команда (с использованием `systemctl`)
Остановить службу	`sudo systemctl stop nginx`
Запустить службу	`sudo systemctl start nginx`
Перезапустить службу	`sudo systemctl restart nginx` (Останавливает, а затем снова запускает)
Перезагрузить конфигурацию	`sudo systemctl reload nginx` (Применяет новые конфигурации без разрыва соединений)

Лучшая практика: используйте reload вместо restart При внесении изменений в конфигурацию (например, обновлении виртуальных хостов или SSL-сертификатов) всегда используйте reload. Это применяет изменения корректно, в то время как существующие соединения продолжают работать без перебоев. Используйте restart только в том случае, если reload не удается или если вам нужно полностью сбросить рабочие процессы.

Перед любой перезагрузкой выполните:

sudo nginx -t && sudo systemctl reload nginx

Этот однострочный шаблон предотвращает самую распространенную ошибку: перезагрузку сломанной конфигурации и остановку работающего сервера. Если nginx -t завершается неудачей, команда перезагрузки не выполнится.

Проверка файлов конфигурации

Наиболее распространенной причиной сбоя запуска или неожиданного поведения Nginx является синтаксическая ошибка в файлах конфигурации (nginx.conf или файлах, включенных в /etc/nginx/sites-available/). Nginx предоставляет отличную встроенную утилиту тестирования.

3. Тестирование синтаксиса конфигурации

Флаг -t проверяет файлы конфигурации на наличие синтаксических ошибок и проверяет, действительны ли пути к файлам конфигурации.

sudo nginx -t

Пример успешного вывода:

nginx: синтаксис файла конфигурации /etc/nginx/nginx.conf в порядке
nginx: тест файла конфигурации /etc/nginx/nginx.conf прошел успешно

Пример вывода с ошибкой:

Если существует ошибка, Nginx укажет вам на точный файл и номер строки. Например, отсутствующая точка с запятой:

nginx: [emerg] неизвестная директива "server_name example.com" в /etc/nginx/sites-enabled/default:15
nginx: тест файла конфигурации /etc/nginx/nginx.conf не пройден

Эта немедленная обратная связь позволяет вам перейти непосредственно к строке 15 указанного файла, чтобы исправить опечатку.

Иногда сообщаемая строка является только той, где Nginx наконец заметил проблему. Отсутствующий } или ; может быть на несколько строк раньше. Если ошибка указывает на нормально выглядящую директиву, проверьте блок выше нее.

4. Отображение активной конфигурации

Чтобы увидеть, что именно Nginx в настоящее время выполняет (особенно полезно после множественных слияний конфигурации или сложных включений), используйте флаг -T (заглавная T):

sudo nginx -T

Это выводит всю активную конфигурацию, которую можно перенаправить в файл для сравнения или подробного просмотра:

sudo nginx -T > current_nginx_config.txt

Будьте осторожны при публикации вывода nginx -T. Он может содержать внутренние имена хостов, пути к сертификатам, заголовки прокси, а иногда и секреты, передаваемые в заголовках. Для работы с инцидентами это отлично. Для тикетов или чата сначала отредактируйте.

Проверка портов и слушателей

Если Nginx не запускается и в журналах упоминается bind() to 0.0.0.0:80 failed, другой процесс может уже прослушивать порт.

sudo ss -ltnp | grep -E ':80|:443'

Типичный вывод показывает локальный адрес, порт и имя процесса. Если Apache, Caddy, прокси контейнера или старый процесс Nginx удерживает порт, Nginx не сможет к нему привязаться.

Вы также можете подтвердить публичное поведение с самого сервера:

curl -I http://127.0.0.1
curl -Ik https://127.0.0.1

-I извлекает только заголовки. -k игнорирует проверку сертификата, что полезно при тестировании localhost с сертификатом, выданным для доменного имени. С другой машины также протестируйте реальное имя хоста:

curl -I https://example.com

Если localhost работает, но публичное имя хоста не работает, проверьте правила брандмауэра, группы безопасности облака, DNS, балансировщики нагрузки или конфигурацию CDN.

DNS стоит проверить отдельно, потому что он может сделать здоровый сервер Nginx сломанным извне:

dig +short example.com
dig +short www.example.com

Убедитесь, что возвращаемый адрес является ожидаемым сервером или балансировщиком нагрузки. Если вы недавно переместили сайт, устаревший DNS может отправлять некоторых пользователей на старый хост, в то время как ваши собственные тесты попадают на новый.

Мониторинг и анализ журналов

Если Nginx запускается успешно, но обслуживает неправильные страницы или возвращает ошибки 5xx, журналы становятся основным источником правды.

5. Поиск ключевых файлов журналов

По умолчанию журналы Nginx обычно находятся в /var/log/nginx/. Два основных файла:

access.log: Записывает каждый запрос, обработанный сервером, включая IP, время запроса, код состояния и запрошенный ресурс.
error.log: Записывает предупреждения, уведомления и критические ошибки, возникшие во время работы или обработки запросов.

6. Мониторинг журналов в реальном времени с помощью `tail`

Чтобы отслеживать ошибки по мере их возникновения, используйте команду tail с опцией слежения (-f) для журнала ошибок.

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

Это бесценно при тестировании только что развернутой конечной точки приложения, так как вы можете сразу увидеть, выдает ли Nginx или вышестоящее приложение ошибки.

Для более загруженного сервера отслеживайте только новые строки ошибок и сохраняйте видимость временных меток:

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

Затем воспроизведите неудачный запрос в другом терминале:

curl -I https://example.com/failing/path

Этот простой двухтерминальный рабочий процесс часто быстрее, чем щелкать в браузере, потому что каждый запрос и запись журнала можно сопоставить напрямую.

7. Анализ кодов состояния журнала доступа

Для проблем с высоким трафиком быстрый просмотр журнала доступа на предмет кодов состояния может выявить проблемы:

Коды 4xx (Ошибки клиента): Часто указывают на битые ссылки, отсутствующие файлы (404) или проблемы с разрешениями.
Коды 5xx (Ошибки сервера): Указывают на то, что сам Nginx не смог выполнить запрос, часто из-за тайм-аутов соединения с вышестоящим сервером (502/504) или внутренних ошибок обработки сервера (500).

Используйте grep для фильтрации по конкретным кодам. Например, поиск всех ошибок 502 Bad Gateway:

sudo grep ' 502 ' /var/log/nginx/access.log | tail -n 20

Быстрый подсчет кодов состояния может показать, имеете ли вы дело с одним плохим URL или с более широким инцидентом:

sudo awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Распространенные паттерны:

Всплески 404 часто означают неудачный путь развертывания, отсутствующие статические файлы или измененные маршруты.
403 часто указывает на права доступа к файлам, права доступа к каталогам или намеренное правило доступа.
502 обычно означает, что Nginx не смог получить действительный ответ от вышестоящей службы.
504 обычно означает, что вышестоящая служба приняла соединение, но не ответила вовремя.

При сбоях вышестоящего сервера также проверьте службу приложения:

sudo systemctl status myapp
sudo journalctl -u myapp -n 100 --no-pager

Замените myapp на фактическое имя службы. Nginx может проксировать только то, что живо и доступно.

Расширенная диагностика: подробность и идентификатор процесса

8. Принудительное ведение журнала отладки (с осторожностью)

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

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

После изменения директивы необходимо использовать reload или restart Nginx, чтобы изменение вступило в силу.

9. Поиск идентификатора главного процесса Nginx (PID)

Идентификатор процесса (PID) полезен для отправки определенных сигналов работающему главному процессу (например, для корректного завершения работы или корректной перезагрузки вне systemctl). PID обычно хранится в файле, обычно /var/run/nginx.pid.

cat /var/run/nginx.pid
# Пример вывода: 1234

Затем вы можете использовать команду kill при необходимости (например, sudo kill -HUP 1234 для принудительной перезагрузки с использованием PID):

Большинство операторов должны предпочесть systemctl reload nginx, потому что это проходит через менеджер служб и его легче аудировать. Сигналы все еще полезны на минимальных системах, контейнерах или старых хостах, где systemd не управляет процессом.

Распространенные исправления из командной строки по симптомам

Если Nginx выходит из строя после редактирования конфигурации:

sudo nginx -t
sudo journalctl -u nginx -n 80 --no-pager

Исправьте указанный файл и строку, затем протестируйте снова перед перезагрузкой.

Если HTTPS не работает после обновления сертификата:

sudo nginx -t
sudo ls -l /etc/letsencrypt/live/example.com/
sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -dates -subject

Это подтверждает, что файл сертификата существует, и показывает субъект и даты действия.

Если статические файлы возвращают 403:

namei -l /var/www/example.com/index.html

namei -l выводит права доступа для каждого каталога в пути. Nginx требует права на выполнение для родительских каталогов и права на чтение для файлов.

Если обратный прокси возвращает 502:

sudo grep 'connect() failed' /var/log/nginx/error.log | tail
sudo ss -ltnp | grep 3000
curl -I http://127.0.0.1:3000

Это проверяет, прослушивает ли вышестоящий сервер и отвечает ли он локально.

Если вышестоящий сервер является Unix-сокетом вместо TCP-порта, проверьте путь к сокету и права доступа:

sudo ls -l /run/myapp/myapp.sock
sudo grep -R "proxy_pass" /etc/nginx/sites-enabled /etc/nginx/conf.d

Пользователь рабочего процесса Nginx должен иметь разрешение на доступ к сокету. На многих системах этим пользователем является www-data или nginx, но подтвердите это в nginx.conf перед изменением владельца или групп.

Для периодических сбоев сравните успешные и неудачные запросы в журнале доступа. Небольшой выборки часто достаточно:

sudo grep ' 504 ' /var/log/nginx/access.log | tail -n 20
sudo grep ' 200 ' /var/log/nginx/access.log | tail -n 20

Ищите закономерности в путях, полях времени ответа вышестоящего сервера, если ваш формат журнала их включает, или конкретный IP-адрес клиента, который вызывает тяжелые запросы.

Рабочий процесс устранения неполадок

Столкнувшись с проблемой Nginx, следуйте этой последовательности:

Проверьте статус: sudo systemctl status nginx.
Протестируйте конфигурацию: Если не удалось запустить, выполните sudo nginx -t. Исправьте сообщенные ошибки.
Перезапустите/Перезагрузите: Если конфигурация была изменена, используйте sudo systemctl reload nginx.
Отслеживайте журналы: Если работает, но сломано, используйте sudo tail -f /var/log/nginx/error.log при воспроизведении проблемы.
Проанализируйте доступ: Просмотрите access.log на предмет кодов состояния, указывающих на характер сбоя (4xx против 5xx).

Этот порядок не дает вам гадать. Статус говорит вам, работает ли Nginx, тесты конфигурации говорят вам, может ли он загрузиться, журналы говорят вам, что произошло во время реальных запросов, а локальные проверки curl отделяют проблемы Nginx от проблем вышестоящего сервера или сети.

Ведите краткую заметку об инциденте по мере работы: выполненная команда, полученный результат и внесенное изменение. Это предотвращает повторные проверки и значительно упрощает передачу дел.