Як керувати Nginx: запуск, зупинка, перезапуск і перезавантаження на Linux

Nginx — це високопродуктивний, подієво-орієнтований веб-сервер і зворотний проксі, який обслуговує мільйони виробничих середовищ по всьому світу. Управління його життєвим циклом — запуск, зупинка, перезапуск і перезавантаження — здійснюється через систему ініціалізації Linux: або systemd (Ubuntu 16.04+, CentOS 7+, Debian 8+), або застарілий фреймворк SysVinit. Критична відмінність між restart і reload не є косметичною: перезапуск завершує всі активні з’єднання, тоді як перезавантаження виконує заміну конфігурації без простою, створюючи нові робочі процеси перед поступовим завершенням старих.

Цей посібник охоплює всі операційні команди, які вам потрібні, базову механіку кожної з них, перевірку конфігурації перед застосуванням, діагностику на основі журналів і граничні випадки, що спричиняють приховані збої у виробництві.

Передумови

Перш ніж виконувати будь-які команди керування Nginx, переконайтеся в наступному:

• Ви маєте root-доступ або обліковий запис користувача з привілеями sudo.
• Nginx встановлено (nginx -v має повернути рядок з версією).
• Ви знаєте, яку систему ініціалізації використовує ваш дистрибутив (systemctl --version підтверджує systemd; його відсутність вказує на SysVinit або інший менеджер).

Якщо ви налаштовуєте новий сервер, середовище VPS Хостинг під управлінням Ubuntu 22.04 LTS або Debian 12 використовуватиме systemd за замовчуванням, що є рекомендованим шляхом для всіх нових розгортань.

Розуміння моделі процесів Nginx

Nginx працює як головний процес і один або кілька робочих процесів. Головний процес читає конфігурацію, прив’язується до привілейованих портів (80, 443) і керує життєвим циклом робочих процесів. Робочі процеси обробляють фактичні клієнтські з’єднання. Саме ця архітектура робить reload безпечним для виробництва: головний процес породжує нові робочі процеси з оновленою конфігурацією, поки існуючі робочі процеси завершують обслуговування поточних запитів, а потім коректно завершують роботу.

Коли ви виконуєте жорсткий restart, сам головний процес завершується і перезапускається, скидаючи всі відкриті з’єднання. Використовуйте це лише в ситуаціях, коли сам головний процес перебуває в поганому стані або після оновлення бінарного файлу.

Керування Nginx за допомогою systemd (сучасні дистрибутиви Linux)

systemd є стандартним менеджером служб у всіх сучасних дистрибутивах Linux. Nginx інтегрується з ним через файл юніту, який зазвичай розташований за адресою /lib/systemd/system/nginx.service.

Запуск Nginx

sudo systemctl start nginx

Це активує юніт служби Nginx. Якщо головному процесу не вдається прив’язатися до порту або виникає помилка конфігурації, systemd негайно повідомить про збій. Перевірте код виходу за допомогою echo $? — ненульове значення означає, що запуск не вдався.

Зупинка Nginx

sudo systemctl stop nginx

Це надсилає SIGTERM головному процесу Nginx, який потім сигналізує робочим процесам завершити активні запити перед вимкненням. Якщо робочі процеси не завершуються протягом налаштованого тайм-ауту, systemd надсилає SIGKILL. На завантаженому сервері це може призвести до скидання з’єднань — використовуйте reload замість цього, коли це можливо.

Перезапуск Nginx

sudo systemctl restart nginx

Перезапуск — це послідовна зупинка з подальшим запуском. Усі активні з’єднання завершуються. Використовуйте це лише коли:

• Сам бінарний файл Nginx було оновлено.
• Головний процес не відповідає.
• Вам потрібно звільнити та повторно прив’язати прослуховуючі сокети (наприклад, після зміни порту).

Завжди запускайте тест конфігурації перед перезапуском (розглянуто в розділі «Перевірка» нижче).

Перезавантаження Nginx (застосування конфігурації без простою)

sudo systemctl reload nginx

Це правильна команда для застосування змін конфігурації у виробництві. Внутрішньо systemd надсилає SIGHUP головному процесу Nginx. Головний процес повторно читає nginx.conf, перевіряє його та породжує нові робочі процеси. Старі робочі процеси продовжують обслуговувати існуючі з’єднання, поки вони не стануть неактивними, а потім завершують роботу. Весь перехід є непомітним для кінцевих користувачів.

Критичний граничний випадок: Якщо нова конфігурація містить помилку, reload може мовчки завершитися невдачею на деяких дистрибутивах — стара конфігурація залишається активною, але жодна помилка не відображається в терміналі. Саме тому попередня перевірка за допомогою nginx -t є обов’язковою перед кожним перезавантаженням.

Перевірка статусу Nginx

sudo systemctl status nginx

Ця команда відображає стан служби (active (running), inactive (dead), failed), PID головного процесу, використання пам’яті та CPU, а також останні кілька рядків журналу. Це найшвидший перший крок діагностики для будь-якої проблеми з Nginx.

Приклад виводу для справного екземпляра:

● nginx.service - A high performance web server and a reverse/proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-01-13 10:22:04 UTC; 2h 15min ago
       Docs: man:nginx(8)
    Process: 1234 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on;
   Main PID: 1235 (nginx)
      Tasks: 3 (limit: 4915)
     Memory: 6.4M
        CPU: 312ms
     CGroup: /system.slice/nginx.service
             ├─1235 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─1236 "nginx: worker process"
             └─1237 "nginx: worker process"

Увімкнення автозапуску Nginx при завантаженні

sudo systemctl enable nginx

Без цього Nginx не запуститься автоматично після перезавантаження сервера. Поєднайте це з командою start в одному виклику:

sudo systemctl enable --now nginx

Вимкнення автозапуску Nginx

sudo systemctl disable nginx

Керування Nginx за допомогою SysVinit (застарілі системи)

SysVinit зустрічається на дистрибутивах, що досягли кінця терміну підтримки, таких як CentOS 6 та Ubuntu 14.04. Обгортка service надає єдиний інтерфейс до init-скриптів, розташованих у /etc/init.d/.

Якщо ви досі використовуєте системи на базі SysVinit у виробництві, настійно рекомендується перейти на підтримуваний дистрибутив. Ці системи більше не отримують патчі безпеки, що створює значну вразливість для будь-якого сервера, доступного з Інтернету.

systemd проти SysVinit: порівняння команд

Перевірка конфігурації перед будь-якими змінами служби

Це найважливіша операційна звичка при керуванні Nginx. Пошкоджений файл конфігурації призведе до того, що restart завершиться невдачею і залишить ваш сервер офлайн.

sudo nginx -t

Успішний тест повертає:

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

Для детального виводу, який також друкує розв’язану конфігурацію (корисно при налагодженні директив include):

sudo nginx -T

nginx -T виводить всю об’єднану конфігурацію в stdout, що робить її безцінною для аудиту складних налаштувань з кількома серверними блоками, розподіленими по /etc/nginx/conf.d/ або /etc/nginx/sites-enabled/.

Робочий процес для безпечних змін конфігурації:

# 1. Edit your configuration
sudo nano /etc/nginx/nginx.conf

# 2. Validate — stop here if errors are reported
sudo nginx -t

# 3. Apply with zero downtime
sudo systemctl reload nginx

# 4. Confirm the service is still healthy
sudo systemctl status nginx

Надсилання сигналів безпосередньо головному процесу Nginx

У сценаріях, де systemd недоступний або вам потрібен точний контроль, Nginx приймає POSIX-сигнали безпосередньо через nginx -s:

sudo nginx -s reload    # Equivalent to SIGHUP — graceful config reload
sudo nginx -s reopen    # Reopen log files (used after log rotation)
sudo nginx -s stop      # Fast shutdown (SIGTERM)
sudo nginx -s quit      # Graceful shutdown — waits for workers to finish

PID головного процесу зберігається в /var/run/nginx.pid за замовчуванням. Ви також можете надсилати сигнали вручну:

sudo kill -HUP $(cat /var/run/nginx.pid)

Сигнал reopen є особливо важливим у конвеєрах ротації журналів. Коли logrotate переміщує /var/log/nginx/access.log, Nginx продовжує записувати в старий файловий дескриптор, поки ви не надішлете reopen, після чого він створює і записує в новий шлях до файлу.

Діагностика збоїв: журнали та journal

Коли Nginx не вдається запустити або перезавантажити, два джерела надають діагностичні дані.

Журнал systemd

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

Для відстеження виводу в реальному часі під час спроби перезапуску:

sudo journalctl -u nginx -f

Журнал помилок Nginx

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

Для моніторингу в реальному часі:

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

Поширені шаблони збоїв та їх причини:

• bind() to 0.0.0.0:80 failed (98: Address already in use) — Інший процес (Apache, попередній екземпляр Nginx) утримує порт 80. Визначте його за допомогою sudo ss -tlnp | grep :80.
• open() "/var/log/nginx/error.log" failed (13: Permission denied) — Робочий користувач Nginx не має права запису до каталогу журналів.
• nginx: [emerg] unknown directive — Друкарська помилка або непідтримувана директива модуля в nginx.conf. Вивід nginx -t міститиме точний файл і номер рядка.
• connect() failed (111: Connection refused) while connecting to upstream — Nginx працює, але upstream-застосунок (PHP-FPM, Node.js) не працює. Це з’являється в журналі помилок, а не під час запуску.

Керування Nginx на серверах з панеллю керування

Якщо на вашому сервері запущена панель керування, така як cPanel або Plesk, Nginx може керуватися як шар зворотного проксі перед Apache або як основний веб-сервер. У таких середовищах не використовуйте необроблені команди systemctl для перезапуску Nginx без розуміння оркестрації служб панелі — деякі панелі перевизначають файл юніту systemd і керують Nginx через власні супервізори демонів.

Для середовищ під управлінням cPanel правильна команда перезапуску зазвичай така:

/scripts/restartsrv_nginx

Розгортання VPS з cPanel обробляє керування службами через Service Manager WHM, який надає графічний інтерфейс разом із CLI-скриптами вище.

Для середовищ, де ви хочете повного ручного контролю без панелі, ознайомтеся з доступними Панелями керування VPS, щоб знайти рівень управління, що відповідає вашій операційній моделі.

Nginx на виділеному обладнанні

Розгортання з високим трафіком, що використовують Nginx як балансувальник навантаження або точку завершення TLS, значно виграють від виділених ресурсів. На Виділеному сервері ви можете точно налаштувати кількість робочих процесів відповідно до фізичних ядер CPU, налаштувати великі значення worker_connections без конкуренції з іншими орендарями та використовувати оптимізації на рівні ядра (SO_REUSEPORT, sendfile, tcp_nopush) на повну потужність. Команди керування службами ідентичні середовищам VPS — різниця полягає в тому, що ви можете налаштувати, а не в тому, як ви керуєте службою.

Якщо ваш екземпляр Nginx завершує HTTPS-трафік, переконайтеся, що ваші TLS-сертифікати актуальні. Прострочені сертифікати спричиняють негайні збої з’єднань, які systemctl status nginx не виявить — служба виглядає справною, тоді як клієнти отримують помилки SSL-рукостискання. Проактивне керування вашими SSL-сертифікатами запобігає цьому класу прихованих збоїв.

Матриця операційних рішень

Використовуйте цю матрицю для вибору правильної дії керування для конкретної ситуації:

Ключові технічні висновки

• Завжди запускайте sudo nginx -t перед restart або reload. Невдалий тест не дозволить вам вивести працюючий сервер офлайн із пошкодженою конфігурацією.
• Надавайте перевагу reload над restart у виробництві. Це не руйнівно і охоплює 99% сценаріїв зміни конфігурації.
• nginx -s quit безпечніший за nginx -s stop, коли вам потрібно вимкнути вручну — він чекає, поки робочі процеси завершать активні з’єднання.
• systemctl enable nginx відокремлений від systemctl start nginx. Якщо забути про enable, Nginx не переживе перезавантаження.
• nginx -T (у верхньому регістрі) виводить повну розв’язану конфігурацію, включаючи всі підключені файли — використовуйте його перед великими змінами для перевірки ефективної конфігурації.
• Середовища панелей керування мають власні скрипти перезапуску. Використання необроблених команд systemd у cPanel або Plesk може спричинити невідповідності стану.
• Постійно відстежуйте /var/log/nginx/error.log під час будь-якого розгортання конфігурації. Помилки upstream і проблеми з дозволами з’являються тут, а не в systemctl status.

Часті запитання

У чому різниця між nginx restart і nginx reload?

restart завершує головний процес і всі робочі процеси, скидаючи активні з’єднання, а потім запускається заново. reload надсилає SIGHUP головному процесу, який породжує нові робочі процеси з оновленою конфігурацією, поки старі робочі процеси завершують обслуговування існуючих запитів — що призводить до нульового простою.

Чому sudo systemctl restart nginx завершується невдачею, навіть якщо nginx -t проходить успішно?

Успішний тест конфігурації не гарантує успішного запуску. Поширені причини включають конфлікти портів (інший процес вже прив’язаний до порту 80 або 443), відсутні файли SSL-сертифікатів, на які посилається конфігурація, або недостатні ліміти файлових дескрипторів. Перевірте journalctl -u nginx одразу після збою для отримання конкретної помилки.

Як застосувати зміну конфігурації без будь-якого простою?

Запустіть sudo nginx -t для перевірки, потім sudo systemctl reload nginx. Це виконує плавну заміну робочих процесів на місці. Існуючі з’єднання не переривається.

Як зробити так, щоб Nginx запускався автоматично після перезавантаження сервера?

Запустіть sudo systemctl enable nginx. Це створює символічне посилання у відповідному каталозі цілі systemd. Поєднайте це з sudo systemctl start nginx або використовуйте sudo systemctl enable --now nginx для увімкнення та запуску однією командою.

Де розташовані журнали Nginx і як читати їх у реальному часі?

За замовчуванням журнал помилок знаходиться за адресою /var/log/nginx/error.log, а журнал доступу — за адресою /var/log/nginx/access.log. Стежте за будь-яким з них у реальному часі за допомогою sudo tail -f /var/log/nginx/error.log. Для структурованого перегляду журналів з фільтрацією за мітками часу та серйозністю використовуйте sudo journalctl -u nginx -f.