Игорь Сысоев писал Nginx именно под эту боль - под Rambler, где надо было отдавать статику массе пользователей дёшево по железу. Ответ на вопрос "что такое nginx" в одну строку: это веб сервер и обратный прокси с событийной (event-driven) архитектурой, который держит тысячи соединений горсткой процессов. Если ты прямо сейчас спрашиваешь себя, для чего нужен nginx и зачем он вообще - вот ради этого: масштаб по соединениям при копеечном расходе памяти. Дальше разберём механику, экосистему форков на 2026 год, ключевые термины и сквозную схему "как запрос проходит через nginx", которую мы будем тащить через весь курс.
Event-driven против prefork: почему nginx это не "ещё один веб сервер"
Модель "процесс на соединение" интуитивна: пришёл клиент - дали ему рабочего, рабочий с ним возится от и до. Беда в том, что HTTP-соединение большую часть жизни просто ждёт. Ждёт, пока клиент дошлёт байты по медленному мобильному каналу. Ждёт ответа от базы. Ждёт, пока браузер заберёт ответ. Всё это время процесс-рабочий занят, но ничего не делает - он висит на блокирующем чтении из сокета. Тысяча медленных клиентов - тысяча простаивающих процессов, сжирающих память.
Nginx переворачивает картину. У него небольшое число процессов-воркеров (обычно по одному на ядро CPU). Каждый воркер крутит бесконечный цикл событий (event loop) поверх системного механизма мультиплексирования - epoll на Linux, kqueue на BSD. Идея в одном предложении: вместо "сиди и жди на этом сокете" воркер говорит ядру "разбуди меня, когда на любом из моих тысяч сокетов появится готовность читать или писать". Ядро возвращает пачку готовых событий - воркер быстро их обрабатывает (распарсил кусок запроса, отдал кусок ответа, проксировал байты) и снова уходит в ожидание. Соединение, которое ждёт сети, не стоит почти ничего: это запись в структуре данных, а не целый процесс.
Код: Выделить всё
worker_processes auto; # обычно = числу ядер CPU
events {
worker_connections 10240; # сколько соединений тянет ОДИН воркер
multi_accept on; # за один цикл принимать пачку новых соединений
use epoll; # механизм мультиплексирования на Linux
}
Код: Выделить всё
# prefork (классическая модель): N соединений => N процессов/потоков
# память: O(N), переключения контекста: много, потолок: тысячи
#
# event-driven (nginx): N соединений => горстка воркеров + epoll
# память: O(N) дешёвых структур, переключений мало, потолок: десятки/сотни тысяч
Для чего нужен nginx: пять ролей одного бинарника
Тот же event-driven движок закрывает целый веер задач. Понять, зачем нужен nginx на практике, проще всего через его роли - один и тот же процесс в зависимости от конфига становится:
- Раздатчик статики. Отдаёт css, js, картинки, видео прямо с диска через sendfile (данные летят из файла в сокет в ядре, минуя копирование в userspace). Самая первая и самая дешёвая его работа.
- Reverse proxy (обратный прокси). Принимает запрос снаружи и проксирует на приложение - PHP-FPM, Node, Python, Java. Клиент видит только nginx, бэкенд спрятан. Это его роль в 90% реальных инсталляций.
- Балансировщик нагрузки. Раскидывает запросы на несколько одинаковых бэкендов (upstream-группа) по алгоритму round-robin, least_conn, hash и так далее. Один упал - трафик идёт на живых.
- Терминатор TLS. Снимает с себя дорогую криптографию HTTPS, расшифровывает трафик на границе и дальше внутрь сети ходит по простому HTTP. Сертификаты, протоколы, шифры - всё на нём.
- Кэш. Запоминает ответы бэкенда и отдаёт их сам, не дёргая приложение. Снимает нагрузку и ускоряет отдачу.
А теперь чего nginx не делает, чтобы не было завышенных ожиданий. Он не интерпретатор: сам по себе не выполняет PHP, Python или Java - он проксирует запрос туда, где код реально исполняется. Он не сервер приложений и не фреймворк. Он не база данных и не очередь сообщений. Из коробки он не делает активных health checks бэкендов в open-source-версии (только пассивные - помечает мёртвым после серии ошибок; активные проверки бесплатно есть в Angie). Граница простая: nginx - это умный, очень быстрый диспетчер трафика на входе. Бизнес-логика живёт за ним.
Карта экосистемы 2026: nginx, freenginx, Angie, OpenResty
Слово "nginx" в 2026 году - это уже не один проект, а целое семейство. Путаница тут стоит реальных денег и нервов на проде, поэтому разложим точно по состоянию на текущий момент.
- nginx (под F5). Тот самый, оригинальный. В 2019-м NGINX Inc. купила F5 Networks, и развитие идёт под её крылом. Актуальная stable-ветка - 1.30.x (1.30.0 вышла 14 апреля 2026), mainline - 1.31.x. Версия 1.30 принесла важные вещи: отдельную директиву http2 on, 103 Early Hints вместо удалённого server push, ECH (Encrypted Client Hello), нативные sticky-сессии и переход проксирования к бэкенду на HTTP/1.1 с keepalive по умолчанию. Если кто-то называет текущей версией 1.25 или 1.27 - он отстал на год-два.
- freenginx (форк Максима Дунаева). В феврале 2024 ведущий разработчик nginx Максим Дунаев разошёлся с F5 во взглядах на раскрытие уязвимостей и завёл независимый форк freenginx - "веб-сервер, которым рулят разработчики, а не корпорация". Важно: проект ЖИВОЙ. На 2026 это не брошенный экспонат: stable 1.30.1, mainline 1.31.2, security-фиксы выходят параллельно с nginx (тот же max_headers и поддержка OpenSSL 4.0 ехали в обеих ветках). Если встретишь утверждение "freenginx умер" - оно неверное.
- Angie (форк экс-разработчиков nginx, РФ). Другая команда выходцев из nginx делает Angie. Актуально - 1.11.6 (25 мая 2026, на базе nginx 1.29.3) и ветка 1.12 (база 1.31.1). Фишка Angie в том, что он бесплатно даёт то, за что у F5 берут деньги в nginx Plus: REST API /status с детальным JSON, метрики Prometheus, панель Console Light, динамическое управление upstream без reload, нативный ACME (Let's Encrypt без certbot прямо в конфиге), нативный Zstd, активные health checks и slow_start, автообнаружение бэкендов по меткам Docker-контейнеров. 100% совместим по конфигам с nginx.
- OpenResty (nginx + LuaJIT). Это не форк ради форка, а nginx, в который встроен LuaJIT (свой форк - openresty/luajit2 с GC64) и куча Lua-модулей. Ты пишешь логику прямо в конфиге на Lua, исполняемую внутри воркера на разных фазах обработки запроса. Актуальная версия - 1.31.1.1 (5 июня 2026, ядро nginx 1.31.1). Именно на OpenResty строят программируемые API-шлюзы - этим мы займёмся во второй половине курса.
Мини-глоссарий и сквозная схема: как запрос проходит через nginx
Прежде чем нырять в конфиги в следующих уроках, забей в голову шесть слов - на них держится вообще всё.
- Директива (directive). Одна инструкция конфига. Бывает простой (заканчивается ; - например worker_processes auto;) и блочной (с фигурными скобками - server { ... }).
- Контекст (context). Блок, внутри которого действуют директивы: main (корень файла), events, http, server, location. Контексты вложены, и многие настройки наследуются от внешнего к внутреннему - это базовый принцип чтения любого конфига.
- server (виртуальный хост, vhost). Описание одного сайта/сервиса: на каком порту слушать (listen), на какое имя откликаться (server_name). На одном nginx живут десятки vhost.
- location. Правило для пути в URL внутри server. Именно location решает, что делать с /api/, что с /images/, а что с /. Сердце маршрутизации.
- upstream. Именованная группа бэкенд-серверов для проксирования и балансировки. На неё ссылается proxy_pass.
- worker (воркер). Процесс, который реально обслуживает соединения в event-loop. Главный (master) процесс ими только управляет: читает конфиг, открывает порты, перезапускает упавших и делает плавный reload.
Типичные грабли новичка
- Путать prefork-мышление с event-driven. Не пытайся "дать каждому запросу свой процесс" в nginx - модель другая. И не блокируй воркер тяжёлой синхронной работой: встанет не один запрос, а целая пачка соединений этого воркера.
- Ждать от nginx исполнения кода. Он не запускает твой PHP/Python сам - он проксирует на FPM/приложение. "Белый экран" часто не в nginx, а в бэкенде за ним.
- Гнаться за устаревшим синтаксисом. Параметр listen ... http2 устарел - в 2026 включают HTTP/2 отдельной директивой http2 on;. Копировать старые гайды из 2018-го - прямой путь к предупреждениям и нерабочим настройкам.
- Считать freenginx мёртвым, а HTTP/3 экспериментальным. Оба утверждения на 2026 ложны: freenginx активно релизится, HTTP/3 в stable и production-ready.
- Смешивать форки в голове. nginx, Angie и OpenResty - разные дистрибутивы с разными возможностями. "В интернете писали, что так можно" нередко относится к другому форку или к платному nginx Plus.
Глубоких конфигов тут ещё нет - задача просто увидеть зверя живьём и узнать его версию.
- Подними nginx в Docker одной командой:
Код: Выделить всё
docker run --rm -p 8080:80 --name ngx nginx:1.30 - Открой в браузере http://localhost:8080 - увидишь страницу "Welcome to nginx!". Это дефолтный server-блок отдаёт статику.
- Узнай точную версию и параметры сборки: Найди в выводе модули (--with-http_v2_module, --with-http_ssl_module и т.п.) - это и есть то, что умеет твой бинарник.
Код: Выделить всё
docker exec ngx nginx -V - Проверь синтаксис конфига (главная команда на каждый день): Ответ "syntax is ok / test is successful" - святое правило перед любым reload на проде.
Код: Выделить всё
docker exec ngx nginx -t - Глянь на процессы внутри контейнера и найди master и worker: Увидишь "nginx: master process" и под ним "nginx: worker process" - ровно та модель из урока.
Код: Выделить всё
docker exec ngx ps aux - Для сравнения вытащи версию Angie: Обрати внимание - команда та же nginx, конфиги совместимы, а вот возможности шире.
Код: Выделить всё
docker run --rm angie/angie nginx -v
- В чём суть проблемы C10K и почему prefork-модель упирается в потолок там, где event-driven держится?
- Назови пять ролей nginx и приведи пример задачи под каждую. Что из этого nginx делать не будет?
- Чем на 2026 год отличаются nginx (F5), freenginx, Angie и OpenResty? Под какую задачу что выберешь?
- Перечисли шесть базовых терминов (контекст, директива, server, location, upstream, worker) и опиши путь запроса от прихода на воркер до ответа клиенту.
Nginx захватил веб не магией, а сменой модели: вместо "процесс на соединение" - событийный цикл, где горстка воркеров поверх epoll тянет десятки тысяч соединений. Этот же движок работает раздатчиком статики, обратным прокси, балансировщиком, терминатором TLS и кэшем - кирпичами будущего API-шлюза. В 2026 "nginx" - это семейство: живой nginx под F5 (1.30/1.31), активный форк freenginx, богатый бесплатными фичами Angie и программируемый OpenResty. Ты уже держишь в голове глоссарий и сквозную схему прохождения запроса - дальше мы только наполняем её конкретикой, конфиг за конфигом.
