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

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

Это руководство посвящено практическому использованию команд в системах Linux, где Nginx управляется через systemd, что распространено на Ubuntu, Debian, CentOS, Rocky Linux и многих облачных образах.

Примеры предполагают, что служба называется nginx. Некоторые пользовательские сборки или панели управления используют другое имя модуля, но установленные из пакетов версии Nginx обычно следуют этому соглашению. Если сомневаетесь, выведите список соответствующих модулей:

systemctl list-units '*nginx*'
systemctl list-unit-files '*nginx*'

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

Проверка, запущен ли Nginx

Начните с проверки статуса службы:

sudo systemctl status nginx

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

Внимательно прочитайте первые несколько строк статуса. active (running) означает, что systemd считает, что главный процесс жив. failed означает, что последняя попытка запуска или перезагрузки не удалась. enabled или disabled сообщает о поведении при загрузке, а не о том, работает ли служба прямо сейчас.

Для более короткого вывода, полезного в скриптах:

systemctl is-active nginx

Возможные результаты: active, inactive, failed или activating. Если вам нужно только узнать, включен ли Nginx при загрузке, используйте:

systemctl is-enabled nginx

Вы также можете подтвердить, что Nginx прослушивает веб-порты:

sudo ss -ltnp | grep nginx

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

Если ss ничего не показывает, подтвердите, не занят ли порт другим процессом:

sudo ss -ltnp 'sport = :80'
sudo ss -ltnp 'sport = :443'

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

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

Используйте start, когда Nginx не запущен:

sudo systemctl start nginx

Используйте stop, когда вы намеренно хотите отключить его:

sudo systemctl stop nginx

Будьте осторожны с stop на производственных серверах. Это немедленно делает службу недоступной, если только другой сервер или балансировщик нагрузки не обрабатывает трафик.

Используйте restart, когда вам нужна полная остановка и запуск:

sudo systemctl restart nginx

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

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

Для большинства изменений конфигурации предпочтительнее перезагрузка:

sudo systemctl reload nginx

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

Практический пример: вы добавляете новый блок сервера для api.example.com. Сначала выполните sudo nginx -t. Если тест пройден, выполните sudo systemctl reload nginx. Пользователи с существующими соединениями не должны заметить изменений.

Вы также можете попросить Nginx напрямую перезагрузиться:

sudo nginx -s reload

В системах с systemd предпочтительнее использовать systemctl reload nginx для рутинных операций, поскольку systemd остается источником истины для состояния службы и журналов. Прямая форма nginx -s все еще полезна в минимальных системах или в контейнерах, где systemd отсутствует.

Знайте разницу между перезагрузкой и перезапуском

Это различие предотвращает много предотвратимых простоев.

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

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

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

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

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

Тестирование конфигурации перед применением изменений

Самая важная команда:

sudo nginx -t

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

Вы можете увидеть вывод, подобный этому:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

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

sudo nginx -T

Это полезно, когда вы не уверены, какой файл содержит директиву. Это может выявить неожиданности из /etc/nginx/conf.d/, sites-enabled или предоставленных пакетом фрагментов.

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

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

sudo nginx -t -c /etc/nginx/nginx.conf

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

Для более глубокого контрольного списка команд см. тестирование конфигураций Nginx и мониторинг статуса.

Просмотр журналов при управлении службой

Когда команда не удается, журналы обычно объясняют причину. Начните с журнала:

sudo journalctl -u nginx --since "10 minutes ago"

При неудачной загрузке или перезапуске удалите временное окно и покажите последние записи:

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

Для просмотра журналов в реальном времени:

sudo journalctl -u nginx -f

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

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

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

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

После перезагрузки наблюдайте как за журналом, так и за журналом ошибок в течение минуты:

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

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

Включение или отключение Nginx при загрузке

Чтобы Nginx запускался автоматически после перезагрузки:

sudo systemctl enable nginx

Чтобы включить и запустить его одним шагом:

sudo systemctl enable --now nginx

Чтобы предотвратить его автоматический запуск:

sudo systemctl disable nginx

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

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

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

systemctl cat nginx
systemctl show nginx -p WantedBy -p After -p Requires

Избегайте прямого редактирования файлов модулей из пакетов. Вместо этого используйте переопределение:

sudo systemctl edit nginx

Это создает drop-in в каталоге переопределений systemd и упрощает обновление пакетов. После изменения переопределений модуля выполните:

sudo systemctl daemon-reload
sudo systemctl restart nginx

Изменяйте зависимости модуля только тогда, когда понимаете отношения при запуске. Многие проблемы Nginx относятся к конфигурации Nginx, а не к конфигурации systemd.

Отправляйте сигналы только когда это необходимо

Nginx имеет главный процесс и рабочие процессы. Главный процесс читает конфигурацию, управляет рабочими процессами и реагирует на сигналы. Systemd скрывает большую часть этого от вас, что хорошо для нормальной работы.

Если вам нужно проверить дерево процессов:

ps -o pid,ppid,user,cmd -C nginx

Вы обычно увидите один главный процесс, работающий от root, и рабочие процессы, работающие от настроенного пользователя Nginx, часто www-data, nginx или nobody в зависимости от дистрибутива.

Существуют прямые сигналы:

sudo nginx -s reload
sudo nginx -s quit
sudo nginx -s stop

quit запрашивает корректное завершение. stop выходит быстро. В повседневном администрировании системы используйте systemctl, если у вас нет особой причины не делать этого. Это сохраняет состояние службы, журналы и поведение при перезапуске в одном месте.

Распространенные ошибки команд, которых следует избегать

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

Не используйте kill -9 для обычного управления Nginx. Позвольте systemd и главному процессу Nginx управлять рабочими процессами. Принудительное завершение процессов может оставить запутанные состояния и разорванные соединения.

Не редактируйте файлы в sites-available и не предполагайте, что они активны. В макетах Debian-стиля включенный файл обычно является символической ссылкой в sites-enabled. Подтвердите с помощью:

ls -l /etc/nginx/sites-enabled/

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

Не предполагайте, что sudo systemctl status nginx доказывает, что каждый сайт работает. Nginx может работать, в то время как один блок сервера указывает на мертвый апстрим или неправильный корневой каталог документов.

Не тестируйте только HTTP, когда изменение связано с HTTPS. Цепочка сертификатов, разрешения ключей, сопоставление SNI и поведение редиректа — все это требует проверки HTTPS:

curl -I https://example.com/
openssl s_client -connect example.com:443 -servername example.com </dev/null

curl -I достаточно для многих проверок. openssl s_client более подробен и полезен, когда вам нужно проверить сертификат, предоставленный для конкретного имени.

Контрольный список безопасных производственных изменений

Для небольшого изменения конфигурации Nginx используйте повторяемый контрольный список:

Отредактируйте целевой файл.
Выполните sudo nginx -t.
Если тест не пройден, исправьте конфигурацию, прежде чем трогать работающую службу.
Выполните sudo systemctl reload nginx.
Проверьте sudo systemctl status nginx --no-pager.
Протестируйте затронутый URL с помощью curl.
Просмотрите журнал ошибок на предмет новых сообщений.

Например, после добавления редиректа:

sudo nginx -t
sudo systemctl reload nginx
curl -I http://example.com/old-path
sudo tail -n 50 /var/log/nginx/error.log

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

curl -I https://api.example.com/health
sudo journalctl -u nginx --since "5 minutes ago" --no-pager

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

Устранение неполадок при неудачных запусках и перезагрузках

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

sudo nginx -t

Если синтаксис действителен, но запуск все равно не удается, проверьте журнал:

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

Распространенные причины включают:

Другой процесс уже использует порт 80 или 443.
Путь к файлу сертификата или ключа неправильный.
Nginx не может прочитать файл из-за разрешений или политики SELinux/AppArmor.
Указанный каталог не существует.
Динамический модуль, настроенный в nginx.conf, отсутствует после изменения пакета.

Для конфликтов портов:

sudo ss -ltnp 'sport = :80'
sudo ss -ltnp 'sport = :443'

Для отсутствующих файлов доверяйте сообщению об ошибке Nginx. Обычно оно указывает путь. Проверьте путь точно так, как написано, а не ожидаемый путь:

sudo ls -l /path/from/error/message

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

Когда обращаться за помощью по вопросам управления службой

Обратитесь к DevOps-инженеру или системному администратору Linux, когда Nginx не запускается после обновления пакета, когда перезагрузки не удаются на производственном сервере, или когда systemd показывает ошибки разрешений и изоляции, которые вы не понимаете. Также обращайтесь за помощью перед изменением файлов модулей на общей инфраструктуре.

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

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