Где живут файлы Nginx и команды управления
Половина проблем с Nginx — это «отредактировал не тот файл» или «забыл перезагрузить». Разберёмся, где что лежит и какими командами рулить.
«Правило номер один: после любой правки — `nginx -t`, и только потом `nginx -s reload`. Без проверки в прод не заходим.»
Nginx хранит конфигурацию в /etc/nginx/. Внутри — главный файл и подключаемые куски. Понимание этой раскладки экономит часы отладки.
Типичная структура каталога
/etc/nginx/
├── nginx.conf # главный файл: глобальные настройки + include
├── conf.d/ # доп. конфиги, подключаются через include
│ └── default.conf
├── sites-available/ # все сайты (Debian/Ubuntu-стиль)
│ └── example.com
├── sites-enabled/ # симлинки на ВКЛЮЧЁННЫЕ сайты
│ └── example.com -> ../sites-available/example.com
├── mime.types # соответствие расширений и Content-Type
└── snippets/ # переиспользуемые куски (ssl-параметры и т.п.)
В nginx.conf обычно есть строки вроде include /etc/nginx/conf.d/*.conf; и include /etc/nginx/sites-enabled/*; — именно через них подтягиваются твои сайты. Схема sites-available + sites-enabled (с симлинками) удобна: чтобы выключить сайт, удаляешь симлинк, а сам конфиг остаётся.
Команды управления
# Проверить синтаксис конфига (НЕ применяет!)
nginx -t
# Перезагрузить конфиг без обрыва соединений (graceful)
nginx -s reload
# либо через systemd:
systemctl reload nginx
# Полный перезапуск (рвёт соединения — на проде осторожно)
systemctl restart nginx
# Остановить / запустить
systemctl stop nginx
systemctl start nginx
# Посмотреть статус и логи ошибок старта
systemctl status nginx
journalctl -u nginx --no-pager | tail -n 30
Как работает под капотом
nginx -s reload — это, по сути, отправка master-процессу сигнала HUP. Master перечитывает конфиг, проверяет его, и при успехе поднимает новые воркеры (см. урок про архитектуру). Сигнал QUIT — мягкая остановка (доработать соединения), TERM — жёсткая, USR1 — переоткрыть лог-файлы (нужно после ротации логов). Логи по умолчанию: /var/log/nginx/access.log и /var/log/nginx/error.log.
Частые ошибки
- Reload без
nginx -t. Сломанный конфиг при перезагрузке не применится, но ты этого не заметишь и будешь думать, что правка сработала. Всегда проверяй. - Правка в
sites-available, но сайт не включён. Если нет симлинка вsites-enabled, твой конфиг не подключён вообще. - Несколько
serverс одинаковымlistenиserver_name. Nginx предупредит о конфликте; выиграет первый. - Забыть про
error.log. 90% ответов «почему не работает» лежат именно там.
Best practices
- Один сайт — один файл в
sites-available. Чисто и понятно. - Перед reload всегда
nginx -t; заведи привычку как рефлекс. - После ротации логов шли
nginx -s reopen(USR1), иначе Nginx будет писать в удалённый файл. - Держи рабочую копию конфига в системе контроля версий (git).
Типичный рабочий цикл правки конфига
На практике работа с Nginx сводится к повторяющемуся ритуалу, который стоит довести до автоматизма. Шаг первый: правишь нужный файл в sites-available или conf.d. Шаг второй: nginx -t — проверяешь синтаксис. Если команда ругается, она прямо называет файл и номер строки с проблемой, так что чинить легко. Шаг третий: nginx -s reload — применяешь без обрыва соединений. Шаг четвёртый: проверяешь результат (открываешь сайт, смотришь curl -I на заголовки) и заглядываешь в error.log, не появилось ли предупреждений.
Полезно знать разницу между способами управления. Команды nginx -s reload/stop/quit работают напрямую через сигналы процессу. В системах с systemd обычно используют systemctl reload nginx — то же самое, но интегрировано с менеджером служб, который умеет автозапуск и показывает статус через systemctl status nginx. Если Nginx вообще не стартует (а не просто не применяет конфиг), nginx -t уже не поможет — смотри journalctl -u nginx: там будет настоящая причина, будь то занятый порт, отсутствующий файл сертификата или опечатка в пути. Заведя привычку всегда заканчивать правку проверкой логов, ты ловишь проблемы до того, как их заметят пользователи.
Итоги
Файлы Nginx живут в /etc/nginx/: главный nginx.conf подключает conf.d и сайты из sites-enabled (симлинки на sites-available). Управление — через nginx -t (проверка), nginx -s reload (мягкая перезагрузка) и systemd. Логи — в /var/log/nginx/. Дальше начинаем самое вкусное — раздачу статики и блоки location.