Где живут файлы 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.

Проверьте себя
1. Что делает команда `nginx -t`?
AПерезапускает Nginx
BПроверяет синтаксис конфигурации, не применяя её
CПоказывает активные соединения
DВключает тестовый режим раздачи
2. Зачем нужна пара каталогов sites-available и sites-enabled?
AДля бэкапов
BКонфиги сайтов хранятся в available, а симлинки в enabled позволяют включать/выключать сайт, не удаляя файл
CОдин для HTTP, другой для HTTPS
DЭто устаревший механизм без смысла