Мой дэйли дайджест

одно техническое понятие в день

nginx

8 июня 2026 · ~11 мин чтения

инструмент devops веб инфраструктура

nginx

nginx (произносится «энджинкс») — веб-сервер и обратный прокси (reverse proxy), который принимает HTTP-запросы от клиентов, перенаправляет их нужным приложениям и возвращает ответы. Главная особенность — асинхронная событийная архитектура, позволяющая обслуживать десятки тысяч соединений одновременно при минимальном потреблении памяти.

История

Игорь Сысоев (Russian, работал в компании Rambler) начал разрабатывать nginx примерно в 2002 году, а первый публичный релиз вышел в 2004 году. Причина появления — знаменитая «проблема C10k»: в начале 2000-х веб-серверы на основе Apache плохо справлялись с десятью тысячами одновременных соединений. Apache использовал модель «один процесс или поток на соединение», что при 10 000 соединений означало 10 000 процессов — это убивало сервер.

Сысоев сделал ставку на другую архитектуру: один процесс с event loop (петля событий), который обрабатывает все соединения асинхронно. Для русского интернета 2000-х, где Rambler обслуживал огромные нагрузки, это была насущная необходимость.

Ключевые вехи:
- 2004 — первый открытый релиз, 0.1.x
- 2011 — компания Nginx Inc. основана для коммерческой поддержки
- 2013 — nginx занял второе место по распространённости, обогнав Microsoft IIS
- 2019 — F5 Networks купила Nginx Inc. примерно за $670 млн
- 2024 — nginx остаётся одним из двух самых популярных веб-серверов в мире (вместе с Apache), по данным Netcraft используется на ~34% активных сайтов

Параллельно существует форк OpenResty (2011, создан Yichun Zhang) — nginx с встроенным Lua-интерпретатором для программирования прямо в конфиге. Alibaba, Cloudflare и многие CDN используют именно его.

Что это такое

nginx — это программа, которая сидит «перед» твоим приложением и управляет входящими HTTP/HTTPS-запросами. Она умеет несколько принципиально разных вещей:

Веб-сервер: отдаёт статические файлы (HTML, CSS, картинки, видео) напрямую, без участия приложения. Делает это очень быстро — просто читает файл с диска и отправляет клиенту.

Обратный прокси (reverse proxy): получает запрос, передаёт его «за кулисы» приложению (например, FastAPI на порту 8030), получает ответ и отдаёт клиенту. Клиент не знает, что общается с прокси — для него всё выглядит как общение с одним сервером.

Балансировщик нагрузки (load balancer): если у тебя несколько экземпляров приложения, nginx распределяет запросы между ними по разным алгоритмам.

SSL/TLS-терминатор: принимает зашифрованные HTTPS-запросы, расшифровывает их и передаёт приложению уже в открытом виде. Приложение работает с обычным HTTP, и возиться с сертификатами ему не нужно.

Чем отличается от Apache: Apache по умолчанию создаёт поток или процесс на каждое соединение. nginx — нет. Один рабочий процесс nginx обрабатывает тысячи соединений через event loop. Результат: nginx использует меньше памяти и лучше держит нагрузку при большом количестве одновременных соединений. Apache зато лучше совместим со старыми .htaccess-файлами и модульной системой PHP.

Чем отличается от HAProxy: HAProxy — специализированный балансировщик нагрузки для TCP/HTTP, не умеет отдавать статику и хуже как веб-сервер, зато как балансировщик гибче и производительнее. nginx универсальнее, HAProxy — точнее.

Аналогии из жизни

Аналогия 1: Ресепшен в офисном здании

Ты приходишь в бизнес-центр, где сидят десятки компаний. Ресепшионист (nginx) встречает всех посетителей, смотрит к кому ты идёшь и направляет тебя в нужный кабинет. Сам он не знает, как делать ту работу, которой занимаются в кабинетах, — его задача только маршрутизация.

Где ломается: если ресепшионист сломается (nginx упал), никто не попадёт ни в один кабинет, даже если все сотрудники на месте и работают. Кроме того, ресепшен не ускорит работу внутри кабинета — если приложение медленное, прокси не поможет.

Аналогия 2: Почтовый сортировочный центр

Всё, что приходит на один адрес (порт 80/443), nginx сортирует по «получателям» (доменам, путям URL) и отправляет нужному сервису. site.ru/api уходит в FastAPI, site.ru/static обслуживается прямо из папки на диске, blog.site.ru идёт в другое приложение.

Где ломается: сортировка работает только по адресу и URL, но не по содержимому зашифрованного HTTPS-трафика (до расшифровки). Поэтому SNI (Server Name Indication) — технология, которая передаёт имя хоста до расшифровки — нужна, чтобы nginx мог правильно выбрать сертификат при нескольких доменах на одном IP.

Аналогия 3: Буфер-официант в ресторане

Кухня (приложение) может приготовить только N блюд одновременно. Официант (nginx) принимает заказы всех посетителей, ставит в очередь, раздаёт готовые блюда. Посетители не ждут у кассы кухни — они сидят и официант сам приходит.

Где ломается: если кухня работает медленно, официант не ускорит приготовление. Он умеет только управлять очередью и соединениями. В реальности nginx не поможет, если узкое место — это база данных или медленный Python-код.

Как это работает

Архитектура: master и workers

При запуске nginx создаёт один master-процесс и несколько worker-процессов (по числу CPU-ядер или по конфигу).

Master-процесс читает конфиг, открывает сокеты (порты 80, 443), порождает worker'ов и следит за ними. Он не обрабатывает запросы.

Каждый worker — это однопоточный процесс с event loop. Он принимает новые соединения, читает данные, отправляет запросы upstream-серверам (proxied backends), ждёт ответа, отправляет клиенту — и всё это без блокировки. Пока ждёт ответа от одного клиента, обрабатывает другого.

Клиент 1 ──→ ┐
Клиент 2 ──→ │ Worker (event loop) ──→ Приложение (FastAPI :8030)
Клиент 3 ──→ ┘                    ──→ Статика (файлы /var/www)

Конфигурация: блоки http, server, location

Конфиг nginx (/etc/nginx/nginx.conf) состоит из вложенных блоков:

http {
    # Глобальные настройки HTTP

    server {
        listen 80;
        server_name scherbinka3.example.com;

        location / {
            proxy_pass http://127.0.0.1:8030;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        location /static/ {
            root /var/www/scherbinka3;
            expires 30d;
        }
    }
}

Когда приходит запрос GET /static/css/style.css HTTP/1.1, nginx:
1. Смотрит на заголовок Host, находит подходящий блок server.
2. Ищет location, наиболее точно совпадающий с путём /static/css/style.css.
3. Выполняет директивы блока — здесь это отдача файла с диска.

Для GET /api/flats тот же сервер попадёт в location / и перенаправит запрос на 127.0.0.1:8030.

HTTPS и certbot

TLS-сертификат (чтобы https:// работал) нужно где-то взять. certbot — утилита от Let's Encrypt, которая автоматически получает бесплатный сертификат и прописывает его в конфиг nginx. Команда примерно такая:

certbot --nginx -d scherbinka3.example.com

После этого в конфиге nginx появляются директивы ssl_certificate и ssl_certificate_key, а все HTTP-запросы перенаправляются на HTTPS.

nginx vs приложение: кто слушает порт 443

Когда стоит nginx, порт 443 слушает nginx, а не твоё приложение. Приложение работает на loopback-адресе (127.0.0.1:8030) и недоступно снаружи напрямую. Это хорошо: nginx обрабатывает TLS, фильтрует запросы, буферизует ответы — а приложению достаётся уже чистый HTTP внутри сервера.

Проблема с default_server

В конфиге nginx можно указать server_name _ — это «поймай всё», сервер для запросов без конкретного доменного имени. Но без директивы default_server на порту listen nginx может проигнорировать такой блок.

Правильно:

server {
    listen 80 default_server;
    server_name _;
    ...
}

Без default_server nginx выбирает первый подходящий блок server, а поведение становится непредсказуемым при нескольких виртуальных хостах.

Где встречается в обычной жизни

Когда открываешь любой крупный сайт — с очень высокой вероятностью перед тобой nginx. Он отдаёт картинки, CSS, скрипты — без участия Python/PHP/Node.js.

Когда сайт работает через HTTPS — nginx (или его аналог) принимает шифрованное соединение, расшифровывает его и передаёт приложению.

Когда у Instagram не падает сайт под нагрузкой — за этим стоят балансировщики уровня nginx (или их форки вроде OpenResty). Сам Instagram использовал nginx годами, сейчас часть нагрузки перешла на Envoy Proxy.

Когда Cloudflare даёт тебе DDoS-защиту — Cloudflare стоит перед твоим nginx как ещё один прокси, но nginx всё равно нужен внутри инфраструктуры.

Когда твой VPS обслуживает несколько сайтов на одном IP — это virtual hosting в nginx. Каждый сайт — отдельный блок server с разным server_name, nginx разбирает запросы по заголовку Host.

Где встречается в IT и бизнесе

Деплой FastAPI / Django / Rails: приложение запускается на 127.0.0.1:8000, nginx принимает внешние запросы на 0.0.0.0:80/443 и проксирует. Это стандартная схема для любого Python/Ruby/Node.js-приложения.

Отдача статики: у Django есть команда collectstatic, которая собирает все файлы в папку. nginx отдаёт их напрямую — быстрее и без нагрузки на Python.

Терминация SSL: сертификаты хранятся в одном месте (nginx), а все backend-сервисы общаются между собой по обычному HTTP внутри сети.

Кэширование: nginx умеет кэшировать ответы от upstream. Для сайтов с большим объёмом однотипных запросов это может снизить нагрузку на приложение в 10–100 раз.

Rate limiting (ограничение частоты запросов): защита от перегрузки и брутфорса. Один IP не сможет сделать больше N запросов в секунду — nginx отклонит лишние с кодом 429.

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    proxy_pass http://127.0.0.1:8030;
}

Кто пользуется

По данным W3Techs (2024), nginx используется примерно на 34% всех веб-сайтов, для которых известен веб-сервер. В сегменте высоконагруженных сайтов — заметно больше.

Конкретные имена:
- Netflix — nginx для стриминга видео и статических ресурсов
- Dropbox — перешли с Apache на nginx для производительности
- GitHub — nginx как фронтенд-прокси
- Яндекс — использует собственный форк nginx (частично открытый), а также nginx в публичной инфраструктуре

Масштабы: крупные CDN сообщают, что один сервер с nginx обрабатывает от 50 000 до 200 000 запросов в секунду в зависимости от типа контента и железа. Для сравнения: типовой VPS за 500 рублей в месяц при разумной нагрузке легко держит 1 000–5 000 запросов в секунду через nginx.

Альтернативы и конкуренты

Apache HTTP Server (1995, Apache Software Foundation)
- Плюсы: гибкая модульная система, .htaccess работает «из коробки», огромная документация и экосистема, хорошо поддерживает PHP через mod_php.
- Минусы: «один поток на соединение» по умолчанию плохо масштабируется под большое число долгих соединений (websocket, long polling); потребляет больше памяти при той же нагрузке.

Caddy (2015, Matt Holt)
- Плюсы: автоматическое получение HTTPS-сертификатов без certbot, читаемый конфиг (Caddyfile), хорош для малых и средних проектов.
- Минусы: меньше возможностей тонкой настройки, меньше документации и кейсов для high-load, написан на Go (более высокое потребление памяти).

HAProxy (2001, Willy Tarreau)
- Плюсы: лучший балансировщик нагрузки для TCP/HTTP с богатой статистикой, гибкое управление соединениями.
- Минусы: не отдаёт статику, нет встроенного SSL-терминатора на уровне веб-сервера — обычно ставят в паре с nginx.

Envoy Proxy (2016, Lyft)
- Плюсы: создан для service mesh и микросервисов, gRPC, HTTP/3, встроенная трассировка.
- Минусы: сложнее в настройке, избыточен для простых сценариев, потребляет больше ресурсов.

Не путай nginx и nginx Plus

Существует коммерческая версия — nginx Plus (от F5). Она включает расширенный мониторинг, активную проверку здоровья backend'ов, динамическое обновление конфига без перезагрузки и поддержку. Бесплатный nginx умеет очень много, но некоторые enterprise-фишки доступны только в Plus.

Когда НЕ стоит использовать

Когда проект — чистая статика без домена и HTTPS — GitHub Pages, Netlify или Cloudflare Pages дают хостинг статики бесплатно, с CDN и HTTPS. Ставить свой nginx ради этого — лишняя инфраструктурная нагрузка.

Когда нужна балансировка на уровне TCP с детальной статистикой — HAProxy или Envoy в таком случае мощнее. nginx умеет stream {}-балансировку, но настройка сложнее и статистика беднее.

Когда всё приложение — serverless или PaaS (Vercel, Railway, Render) — платформа сама берёт на себя nginx-функции. Ставить nginx перед managed-платформой — дублирование без выигрыша.

Связанные понятия

Литература и источники

Где встретилось у меня

8 июня при работе над лендингом ЖК «Новая Щербинка» — FastAPI-приложение (Python, uvicorn на порту 8030) задеплоили на нейро-сервер, и потребовалось настроить nginx как reverse proxy. В процессе столкнулись с багом: блок server_name _ без директивы default_server не становился catch-all, и сайт был недоступен по прямому IP. После правки конфига и добавления default_server — заработало. Параллельно nginx фигурировал в топологии daily-digest: там он на Fornex-VPS раздаёт собранный HTML-блог.

Краткое резюме