Архитектура Nginx: master и worker-процессы

Внутри Nginx живёт один «начальник» (master) и несколько «работяг» (worker): начальник читает конфиг и следит за порядком, а работяги обслуживают запросы.

«Master ничего не отдаёт клиентам — он только управляет. Всю реальную работу делают worker-процессы.»

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

Master-процесс: начальник

Master-процесс стартует первым и обычно работает от root (чтобы иметь право занять привилегированный порт 80/443). Его задачи: прочитать и проверить конфигурацию, открыть слушающие сокеты, породить рабочие процессы и реагировать на сигналы (перезагрузка, остановка). Сам master не обрабатывает клиентские запросы — он дирижёр, а не музыкант.

Worker-процессы: работяги

Worker-процессы — это те, кто реально читает запросы, отдаёт файлы, ходит на бэкенд. Обычно их число равно числу ядер процессора (worker_processes auto;), и каждый воркер сбрасывает root-привилегии, работая от непривилегированного пользователя. Вот схема:

            +----------------------+
            |   master (root)      |
            |  читает конфиг,      |
            |  держит сокеты :80   |
            +----------------------+
              |        |        |
              v        v        v
        +--------+ +--------+ +--------+
        |worker 1| |worker 2| |worker 3|  <- по одному на ядро CPU
        +--------+ +--------+ +--------+
            |          |          |
         клиенты    клиенты    клиенты

Все воркеры разделяют одни и те же слушающие сокеты: новое соединение «подхватывает» один из свободных воркеров.

Как работает под капотом

Когда ты делаешь nginx -s reload, master читает новый конфиг, проверяет его и, если всё в порядке, запускает новые воркеры с новой конфигурацией. Старым воркерам он говорит «доработайте текущие соединения и завершитесь». Поэтому перезагрузка конфигурации происходит без обрыва — ни один пользователь не получит ошибку. Если новый конфиг сломан, master просто не применит его, и старые воркеры продолжат работать.

Кроме воркеров есть вспомогательные процессы: cache manager и cache loader управляют дисковым кешем. Но сердце системы — именно master + воркеры.

Частые ошибки

Ставить worker_processes в большое фиксированное число вроде 32 «для скорости». Больше воркеров, чем ядер, — это лишние переключения контекста. Используй auto.
Запускать всё от root. Master — да (для портов), но воркеры должны работать от ограниченного пользователя (директива user).
Делать restart вместо reload. Restart рвёт соединения; reload — нет.

Best practices

worker_processes auto; — пусть Nginx сам посчитает ядра.
Проверяй конфиг перед перезагрузкой: nginx -t, и только потом nginx -s reload.
Задай user www-data; (или nginx) — воркеры не должны иметь лишних прав.

Зачем разработчику понимать эту модель

Знание про master и воркеров — не абстрактная теория, а ключ к нескольким практическим решениям. Во-первых, ты понимаешь, почему обновление сертификата или конфигурации не требует «технических работ» с заглушкой: nginx -s reload бесшовно поднимает новые воркеры. Во-вторых, ты осознанно настраиваешь число воркеров и лимиты дескрипторов: каждый воркер — отдельный процесс со своим набором открытых файлов, и системный лимит ulimit -n должен быть достаточным, иначе под нагрузкой посыплются ошибки «too many open files».

Ещё один практический момент — привилегии. Master стартует от root исключительно для того, чтобы занять порты 80 и 443 (порты ниже 1024 требуют привилегий). Сразу после этого воркеры сбрасывают права и работают от ограниченного пользователя вроде www-data. Это важная мера безопасности: даже если в воркере найдут уязвимость, атакующий не получит root. Когда ты видишь в логах ошибку доступа к файлу, первым делом проверяй, что именно этот непривилегированный пользователь имеет право читать каталог со статикой — частая причина 403 на ровном месте. Понимание архитектуры превращает загадочные симптомы в очевидные причины.

Итоги

Nginx состоит из master-процесса (управление, конфиг, сокеты, привилегии) и нескольких worker-процессов (вся реальная обработка). Такая модель даёт graceful reload без обрыва соединений и хорошую отказоустойчивость. В следующем уроке заглянем внутрь воркера — в тот самый цикл событий, который позволяет обслуживать тысячи соединений.