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

Сначала проверьте конфигурацию

Лупа над файлом конфигурации и отметка успешной проверки

bash
sudo nginx -t

Команда разбирает все файлы конфигурации и сообщает результат:

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

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

Проверку и перезагрузку удобно объединить:

bash
sudo nginx -t && sudo systemctl reload nginx

Ключ -T (заглавная) дополнительно выводит всю итоговую конфигурацию со всеми подключёнными файлами. Это полезно, когда непонятно, какой из include-файлов на самом деле применяется.

Команды systemctl

Служба называется nginx во всех популярных дистрибутивах: Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, Fedora.

bash
sudo systemctl reload nginx    # перечитать конфигурацию без остановки
sudo systemctl restart nginx   # полный перезапуск
sudo systemctl start nginx     # запустить
sudo systemctl stop nginx      # остановить
sudo systemctl status nginx    # состояние и последние строки лога
sudo systemctl enable nginx    # запускать при загрузке системы

reload или restart

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

restart останавливает все процессы и запускает их заново. Открытые соединения обрываются. Он нужен редко: если Nginx завис, после обновления пакета (хотя пакетные менеджеры обычно делают это сами) или если reload по какой-то причине не применил изменения.

Изменения в сайтах, location, проксировании, сертификатах, заголовках и редиректах применяются через reload.

Сигналы nginx -s

У Nginx есть собственный способ управления - сигналы главному процессу:

bash
sudo nginx -s reload   # перечитать конфигурацию
sudo nginx -s quit     # остановиться, дообслужив текущие запросы
sudo nginx -s stop     # остановиться сразу
sudo nginx -s reopen   # переоткрыть файлы журналов

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

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

Другие системы и контейнеры

Старые системы без systemd:

bash
sudo service nginx reload
sudo /etc/init.d/nginx reload

Alpine Linux (OpenRC):

bash
sudo rc-service nginx reload

FreeBSD:

bash
sudo service nginx reload

Nginx в Docker-контейнере перезагружается командой внутри контейнера:

bash
docker exec имя_контейнера nginx -s reload

Перезапуск всего контейнера (docker restart) тоже работает, но обрывает соединения.

Если Nginx не запустился

Смотрите, что пишет systemd и журнал ошибок:

bash
sudo systemctl status nginx
sudo journalctl -u nginx -n 50
sudo tail -n 50 /var/log/nginx/error.log

Частые причины:

  • bind() to 0.0.0.0:80 failed (98: Address already in use) - порт занят другим процессом, часто Apache или вторым экземпляром Nginx. Найдите его: sudo ss -tlnp | grep -E ':80|:443'.
  • unknown directive - опечатка в имени директивы или директива из модуля, который не подключён.
  • could not build server_names_hash, you should increase server_names_hash_bucket_size - слишком длинные имена в server_name. Добавьте в блок http строку server_names_hash_bucket_size 64; (или 128).
  • cannot load certificate или BIO_new_file() failed - неверный путь к сертификату или ключу либо нет прав на чтение.
  • duplicate listen options или a duplicate default server - два блока server объявлены сервером по умолчанию на одном порту.
  • open() ... failed (13: Permission denied) - у рабочего процесса нет доступа к файлам сайта или сокету. Проверьте права и, в системах с SELinux, контексты безопасности.

О том же для Apache - в статье про перезапуск Apache в Linux.