Nginx — это веб-сервер, обратный прокси и балансировщик нагрузки в одной программе. Его создал Игорь Сысоев в 2004 году для решения проблемы C10k: как удержать десять тысяч одновременных соединений на одном сервере без падения производительности. Сегодня Nginx обслуживает большую часть трафика в интернете и стоит на хостингах, VDS и выделенных серверах — в том числе на инфраструктуре ZevsHost.net.
Что такое Nginx и зачем он нужен
Nginx принимает HTTP-запросы от браузеров и отдаёт им файлы, страницы или передаёт запрос дальше — на PHP-FPM, Node.js или другой backend. Помимо статики и динамики он умеет работать как reverse proxy, кэшировать ответы, шифровать трафик по SSL/TLS и ограничивать нагрузку от отдельных клиентов.
Главное отличие от классического веб-сервера — Nginx не создаёт отдельный процесс или поток на каждое подключение. Это решает основную проблему производительности старых серверов при большом числе одновременных клиентов.
Как устроена архитектура Nginx: master и worker процессы
Внутри Nginx работает один master-процесс и несколько worker-процессов. Master-процесс запускается от root, читает конфигурацию, открывает сокеты и управляет worker-процессами: перезапускает их при сбое, применяет новую конфигурацию без разрыва соединений.
Worker-процессы делают всю реальную работу: принимают соединения, читают запросы, отдают ответы. Каждый worker — однопоточный процесс, но благодаря событийной модели один worker обрабатывает тысячи соединений параллельно. Число worker-процессов задаётся директивой worker_processes и обычно равно числу ядер CPU.
nginx -V
nginx -t
systemctl reload nginx
Event-driven модель вместо процесса на каждое соединение
Apache в классическом режиме prefork создаёт отдельный процесс на каждое соединение, а в режиме worker — отдельный поток. При росте числа клиентов растёт и число процессов, каждый из которых занимает память и требует переключения контекста CPU.
Nginx использует неблокирующий ввод-вывод и системные вызовы epoll на Linux (kqueue на BSD). Worker-процесс не ждёт завершения одной операции, а обрабатывает события от сотен соединений в цикле. Именно это позволяет держать 10 000 и больше одновременных подключений на скромном VPS с 1-2 ГБ памяти.
Чем Nginx отличается от Apache
Apache исторически сильнее в динамической обработке через модули вроде mod_php, которые встраивают интерпретатор прямо в веб-сервер. Nginx принципиально не встраивает интерпретаторы: динамику он передаёт по FastCGI на PHP-FPM или по HTTP на upstream-сервер. Подробно эта связка разобрана в статье про Nginx и PHP-FPM.
Ещё одно отличие — файл конфигурации. У Apache это .htaccess в каждой папке сайта, который сервер перечитывает при каждом запросе. У Nginx конфигурация статична: .htaccess не поддерживается вовсе, а правила описываются в server block, который разбирается подробно в статье о виртуальных хостах Nginx.
Таблица сравнения Nginx и Apache
| Параметр | Nginx | Apache |
|---|---|---|
| Модель обработки | Event-driven, один worker на тысячи соединений | Process/thread на соединение |
| Поддержка .htaccess | Нет | Да |
| Обработка PHP | Через FastCGI и PHP-FPM | Встроенный модуль mod_php |
| Расход памяти при росте нагрузки | Растёт медленно | Растёт пропорционально числу соединений |
Где Nginx используется на практике
Типичные сценарии применения Nginx на серверах и хостингах:
- Веб-сервер для статики: HTML, CSS, JS, изображения без участия backend.
- Reverse proxy перед PHP-FPM, Node.js или Java-приложением.
- Балансировщик нагрузки между несколькими backend-серверами.
- TLS-терминатор: обработка HTTPS перед внутренними сервисами по HTTP.
- Кэширующий слой перед медленным origin-сервером.
С чего начать настройку Nginx
Прежде чем писать правила location и настраивать проксирование, нужно поставить сам сервер и понять структуру его файлов конфигурации. Порядок такой:
- Установить пакет Nginx из официального репозитория, как описано в статье про установку Nginx на Ubuntu и Debian.
- Изучить структуру конфигурации и создать первый server block для своего домена.
- Настроить обработку динамики через PHP-FPM или reverse proxy на нужный backend.
- Если сайт переезжает со старого сервера, свериться со статьёй о миграции с Apache на Nginx, чтобы не потерять правила из .htaccess.
Nginx выигрывает у Apache по потреблению памяти и по числу одновременных соединений на равном железе, но требует другого подхода к конфигурации: без .htaccess и без встроенного интерпретатора PHP. Это компромисс, который окупается на нагруженных сайтах и при малом объёме ресурсов VPS.