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
Подієва модель замість процесу на кожне з'єднання
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.