Nginx принимает запросы снаружи, отдает статику с диска и проксирует их на приложение — один воркер-процесс держит тысячи соединений при RAM-отпечатке 2-4 МБ. Разберем установку, базовую конфигурацию, проксирование и балансировку через upstream, настройку HTTPS и кэширования, а также типовые ошибки. Отдельно — российский форк Angie, выросший из той же кодовой базы.
Что такое Nginx и зачем он нужен
Веб-сервер и reverse proxy
У Nginx две основные роли. Как веб-сервер он отдает файлы напрямую — страницы, картинки, скрипты. Как reverse proxy (обратный прокси) он стоит перед приложением и передает ему запросы, скрывая backend от внешнего мира и беря на себя шифрование, кэш и балансировку. Чаще всего обе роли совмещаются на одном узле.
Чем Nginx отличается от Apache
На отдаче статики и большом числе соединений Nginx в разы экономичнее Apache по памяти: воркер-процесс потребляет 2-4 МБ против 8-30 МБ на поток у Apache при потоковой модели. Архитектурное отличие — Apache создает процесс или поток на каждое соединение, Nginx обрабатывает тысячи в одном процессе через событийную модель. Поэтому Nginx часто ставят фронтом, а Apache оставляют под привычные PHP-приложения за ним.
Angie — российский форк Nginx
Angie — форк Nginx, который развивают бывшие разработчики оригинала, включенный в реестр Минцифры. Он понимает те же конфигурации, что и Nginx, поэтому переезд сводится к замене пакета без переписывания настроек. При этом Angie бесплатно отдает то, за что у Nginx просили платную подписку Plus, недоступную в России с 2022 года: активные проверки здоровья backend, когда балансировщик сам опрашивает серверы, расширенную статистику в формате JSON и боевой режим HTTP/3. Для проектов импортозамещения серверов это способ закрыть уход Nginx Plus, оставшись на привычной технологии с вендорской поддержкой.
Установка Nginx
Ubuntu и Debian
В deb-системах сервер ставится одной командой apt install nginx из штатного репозитория. Сразу после установки он запускается и отдает тестовую страницу — это подтверждает, что все работает.
RHEL и Rocky
В rpm-системах команда аналогична: dnf install nginx. Пакет тоже есть в базовых репозиториях, дополнительные источники не нужны.
Astra Linux
На Astra Linux SE сервер берют из main-репозитория — он входит в поддерживаемый набор пакетов. Это позволяет строить веб-инфраструктуру на сертифицированной ОС без сторонних источников.
Запуск и проверка
Управление идет через systemctl: запуск, остановка, перезапуск и проверка статуса. После установки сервис добавляют в автозагрузку, чтобы он поднимался при перезагрузке узла.
Базовая структура конфигурации
Главный конфиг
Корень настроек — файл /etc/nginx/nginx.conf. В нем глобальные параметры: число рабочих процессов, лимиты соединений, подключение остальных конфигов. Сами сайты обычно выносят в отдельные файлы, а не пишут все в одном месте.
sites-available и sites-enabled
Конфигурации сайтов хранят в каталоге sites-available, а включают созданием ссылки в sites-enabled. Так сайт легко выключить, не удаляя его настройки — просто убрав ссылку. Это удобная и общепринятая схема.
Server blocks
Каждый сайт описывается блоком server (виртуальный хост, virtual host). В нем задают, какой домен обслуживать, на каком порту слушать и где брать файлы. Один Nginx так обслуживает десятки сайтов на одном адресе.
Директивы location
Внутри server блоки location определяют, как обрабатывать разные пути URL: статику отдать с диска, запросы к API проксировать на backend, часть путей закрыть. Location — основной инструмент маршрутизации внутри сайта.
Настройка веб-сервера для сайта
Минимальный server block
Один сайт описывается коротко: домен в server_name, путь к файлам в root, стартовый файл в index. Этой тройки достаточно, чтобы началась раздача статической страницы.
Несколько сайтов
Когда сайтов много, их различают по server_name: Nginx смотрит, какой домен запросил клиент, и отдает соответствующий блок. Для HTTPS тут работает SNI — механизм, позволяющий держать много защищенных сайтов на одном IP.
Корневые директивы
Что и в каком порядке искать на диске, решает связка root, index и try_files. Последняя особенно выручает приложения с человекопонятными адресами: вместо ошибки она отдает несуществующий путь на обработку скрипту.
Статика и сжатие
Отдачу статики ускоряют сжатием — gzip или более эффективным brotli. Сжатый текст и стили доходят до браузера быстрее и экономят трафик. Для картинок и архивов сжатие отключают — они и так сжаты.
Reverse proxy и проксирование
proxy_pass и заголовки
Сердце проксирования — строка proxy_pass: она отправляет пришедший в location запрос на нужный backend. Без проброса заголовков приложение будет считать, что все посетители пришли с одного адреса — самого прокси. Поэтому реальный IP и исходный протокол передают через X-Forwarded-For и X-Forwarded-Proto.
WebSocket
Чаты, живые уведомления и подобное держат канал открытым постоянно. Для них в прокси добавляют заголовки апгрейда протокола, иначе долгоживущее WebSocket-соединение будет регулярно обрываться.
Тайм-ауты и буферизация
Сколько ждать ответа от приложения и как складывать данные перед отправкой клиенту — задают тайм-ауты и буферизация. Тяжелым отчетам поднимают предел ожидания, а потоковой выдаче буферизацию, наоборот, выключают.
Типовые backend
За Nginx чаще всего стоят PHP-FPM для PHP-сайтов, приложения на Node.js или Python-сервисы через gunicorn. При нагруженных запросах к базе backend отделяют на сервер баз данных — это снижает конкуренцию за ресурсы между приложением и СУБД.
Балансировка нагрузки (upstream)
Когда одного backend мало, нагрузку распределяют между несколькими копиями приложения — растет и производительность, и отказоустойчивость. Фронт и backend при такой схеме разделяют: мы подбираем серверы под каждую роль отдельно — требования к ним разные.
Блок upstream
Группу приложений-приемников перечисляют в блоке upstream — по сути список пар «адрес и порт». Дальше proxy_pass указывает уже на эту группу, а не на единственный сервер. Ввести в пул новую машину или вывести старую — правка одной строки.
Методы распределения
Без настройки трафик раздается по кругу — это round-robin. Метод least_conn отправляет очередной запрос туда, где меньше активных соединений, а ip_hash привязывает посетителя к одной машине по его адресу — пригодится, когда сессия хранится прямо на сервере. Так и реализуется load balancing — раскладка нагрузки по копиям приложения.
Веса и проверки здоровья
Серверам задают веса — более мощный backend получает больше запросов. Пассивные проверки исключают узел из пула после серии ошибок. Активные проверки здоровья, когда балансировщик сам опрашивает backend, доступны в Angie и коммерческом Nginx Plus.
TLS, SSL и HTTPS
Шифрование сегодня обязательно, и его настройка — отдельный пункт аудита безопасности любого сайта.
Бесплатные сертификаты
Бесплатный путь к HTTPS — сертификаты Let's Encrypt, которые выписывает и сам же продлевает certbot. Срок жизни короткий, 90 дней, зато обновление идет автоматически по таймеру, и руками к нему возвращаться не нужно.
Корпоративные сертификаты
Коммерческие и корпоративные сертификаты подключают вместе с цепочкой промежуточных центров — иначе часть клиентов получит ошибку доверия. Полную цепочку собирают в один файл.
HTTP/2 и HTTP/3
Скорость поднимают свежие версии протокола: HTTP/2 гонит много запросов по одному соединению, а HTTP/3 поверх QUIC срезает задержки. У Nginx поддержка HTTP/3 пока обкатывается, у Angie она уже боевая.
Версии TLS
Оставляют только TLS 1.2 и 1.3, устаревшие версии отключают. Это закрывает известные уязвимости старых протоколов и требуется большинством стандартов безопасности.
Из чего собирается рабочий reverse proxy с TLS
Соберем типовую боевую конфигурацию по смыслу, по порядку директив. Открывает блок server строка listen с портом 443 и пометкой ssl — это вход для защищенных соединений, а server_name закрепляет за блоком конкретный домен. Дальше идет пара путей к файлам сертификата и закрытого ключа, выданных удостоверяющим центром, плюс ограничение версий шифрования двумя актуальными — двенадцатой и тринадцатой.
Основная логика живет внутри location для корневого пути. Строка proxy_pass отправляет запрос на приложение по локальному адресу и порту, а следом четыре строки проброса заголовков доносят до backend подлинные данные посетителя: имя хоста, реальный IP, цепочку адресов и исходный протокол. Без этих заголовков приложение увидит вместо клиентов сам прокси, что сломает и журналы, и логику авторизации.
Остается мелочь, о которой часто забывают: посетитель, набравший адрес без https, должен попадать на защищенную версию автоматически. Для этого рядом заводят второй компактный блок server на порту 80 с единственной директивой постоянного перенаправления на тот же домен по https. Готовый шаблон такой конфигурации наши инженеры пришлют под вашу связку домена и backend.
Кэширование и производительность
Кэш проксируемых ответов
Директива proxy_cache придерживает ответы приложения и выдает их повторно из памяти, не беспокоя backend на каждый одинаковый запрос.
Кэш для PHP
fastcgi_cache делает то же для PHP-приложений: результат работы скрипта кэшируется, и популярные страницы отдаются без повторного обращения к PHP и базе. На посещаемом сайте это снимает с backend основную массу однотипных запросов и заметно сокращает время ответа.
Кэш файлов и тюнинг
open_file_cache держит в памяти дескрипторы часто запрашиваемых файлов — без него на каждый запрос статики Nginx открывает файловый дескриптор заново. Параметры worker_processes и worker_connections настраивают под число ядер и ожидаемую нагрузку — это базовый тюнинг производительности.
Безопасность
Ограничение частоты запросов
Ограничитель limit_req режет число обращений с одного адреса в секунду — заслон от подбора паролей и примитивных атак на отказ. Обычно выставляют 10-20 запросов в секунду для обычных страниц и 1-2 для форм авторизации — так живой посетитель лимит не замечает.
Скрытие версии и методов
Версию сервера в заголовках скрывают, лишние HTTP-методы запрещают. Меньше информации злоумышленнику — меньше зацепок для атаки.
WAF
Для фильтрации вредоносных запросов перед приложением ставят WAF — ModSecurity или NAXSI. Они отсекают типовые атаки на уровне веб-сервера, до того как запрос дойдет до backend.
Логи и мониторинг
access.log и error.log
Nginx ведет два журнала: access.log с каждым запросом и error.log с проблемами. Первый — для аналитики и разбора нагрузки, второй — первое место при поиске причины сбоя.
Формат логов
Формат access.log настраивают под свои нужды через log_format — добавляют время ответа backend, кэш-статус и прочие поля. Так логи становятся источником данных для оптимизации.
Метрики
Простую сводку показывает модуль stub_status, а для развернутого наблюдения подключают экспортер в Prometheus. Счетчики соединений и запросов оказываются на общих дашбордах — это исходные данные для аудита ИТ-инфраструктуры и оптимизации под рост трафика.
Сравнение: Nginx, Angie и Apache
Типовые ошибки конфигурации
502 Bad Gateway
Самая частая ошибка в работе прокси: backend не ответил — упал, перегружен или не запущен. Первым делом смотрят error.log и проверяют, жив ли прикладной сервер за прокси.
Restart вместо reload
Применять конфигурацию через restart — значит разорвать все текущие соединения. Команда reload подхватывает изменения без разрыва: пользователи ничего не замечают. Restart оставляют на крайний случай.
Слабый TLS-конфиг
Оставленные включенными старые версии TLS и слабые шифры — дыра в безопасности и провал любого аудита. Конфигурацию шифрования держат в актуальном состоянии.
Часто задаваемые вопросы (FAQ)
Что такое Nginx простыми словами?
Это веб-сервер и обратный прокси: он принимает запросы из интернета, отдает файлы напрямую или передает их приложению, попутно занимаясь шифрованием, кэшем и распределением нагрузки.
Чем Nginx отличается от Apache?
Nginx обрабатывает много соединений в одном процессе через события и экономнее по памяти на статике и высокой нагрузке. Apache привычнее для классических PHP-приложений. Часто их используют вместе.
Как настроить Nginx как reverse proxy?
В блоке location прописать proxy_pass на адрес backend и передать заголовки с реальным адресом клиента. Тогда Nginx будет проксировать запросы на приложение.
Что такое upstream и как балансировать нагрузку?
upstream — список backend-серверов. Запросы между ними распределяет балансировщик методами round-robin, least_conn или ip_hash. Это повышает и скорость, и отказоустойчивость.
Как настроить HTTPS на Nginx?
Получить сертификат через certbot от Let's Encrypt, подключить его в конфигурации сайта и оставить только TLS 1.2 и 1.3. Certbot потом сам продлевает сертификат.
Что лучше: Nginx или Angie?
Angie совместим с Nginx и добавляет активные проверки здоровья, расширенную статистику и боевой HTTP/3, плюс реестр Минцифры. Для импортозамещения и сложной балансировки удобнее Angie, для типовых задач достаточно Nginx.
Как ограничить количество запросов в секунду?
Директивой limit_req с заданной зоной: она ограничивает частоту запросов с одного адреса, защищая от перебора и простых атак, не мешая обычным посетителям.
Какие типичные ошибки настройки Nginx?
Чаще всего — 502 из-за упавшего backend, restart вместо reload с разрывом соединений и устаревший TLS-конфиг. Все три легко предотвратить.
Что проверить перед публикацией
Перед выкладкой сайта в продакшен стоит пройтись по короткому списку. Проброшены ли заголовки с реальным адресом клиента — без них сломается авторизация и аналитика. Выставлены ли тайм-ауты на тяжелые запросы — без этого медленные backend накапливают зависшие соединения. Настроено ли автопродление сертификата, чтобы он не истек незаметно. Стоит ли rate limiting на формах входа как заслон от перебора. И включен ли open_file_cache для статики — без него на каждый файл Nginx открывает дескриптор заново.
Поможем с веб-инфраструктурой
Разворачиваете Nginx как веб-сервер, обратный прокси или балансировщик нагрузки? Инженеры Serverzilla подберут серверы под фронт и backend, настроят upstream-балансировку, TLS и кэширование, развернут российский Angie. Соберем конфигурацию под задачу с запасом под рост трафика. Оставьте заявку.
