Nginx: установка и настройка на максимальную производительность

Главный прирост производительности Nginx дают не «магические» параметры, а правильная база: официальный пакет, актуальная версия, достаточные лимиты файлов, корректные worker-процессы, keep-alive, HTTP/2, продуманный TLS и кэширование. Ниже — практический гайд для продакшена на Linux с конфигурациями, сверенными с актуальной документацией NGINX и nginx.org на май 2026 года.

Что вы получите: быстрый, предсказуемый и обновляемый Nginx без устаревших настроек

В 2026 году начинать тюнинг Nginx нужно не с worker_connections 100000, а с установки из официального репозитория и понимания версии. На 11 мая 2026 года актуальная стабильная ветка NGINX Open Source — 1.30.0, выпущенная 14 апреля 2026 года; она включает изменения из ветки 1.29.x, в том числе Early Hints, HTTP/2 к backend-серверам, Encrypted ClientHello, Multipath TCP и изменение поведения проксирования: HTTP/1.1 с keep-alive для upstream теперь включён по умолчанию.

В официальной документации NGINX по-прежнему различаются mainline и stable: mainline получает новые функции и исправления чаще, а stable обновляется реже и подходит для окружений со строгими требованиями к стабильности. При этом сами NGINX-доки рекомендуют официальный репозиторий для продакшена, потому что системные репозитории дистрибутивов часто отстают от актуальных релизов.

Перед установкой: что считать «максимальной производительностью»

Максимальная производительность Nginx — это баланс четырёх вещей:

Пропускная способность — сколько запросов и байт сервер обрабатывает без деградации.
Задержка — как быстро клиент получает первый байт и полный ответ.
Стабильность под пиком — не заканчиваются файловые дескрипторы, память, backend-соединения.
Обновляемость — сервер получает security-fix без ручной пересборки.

Поэтому в этом гайде приоритет такой:

Уровень	Что настраиваем	Почему важно
Пакеты	официальный репозиторий nginx.org	актуальные исправления и модули
Процессы	`worker_processes`, `worker_connections`, лимиты файлов	основа параллелизма
HTTP	keep-alive, HTTP/2, опционально HTTP/3	меньше handshakes, лучше multiplexing
Файлы	`sendfile`, `tcp_nopush`, `open_file_cache`	меньше системных вызовов и блокировок
TLS	session cache, TLS 1.2/1.3, ALPN	меньше CPU на повторные соединения
Кэш	`proxy_cache`, stale, cache lock	меньше нагрузки на backend

Установка Nginx из официального репозитория

Для продакшена лучше ставить Nginx из официального репозитория, а не из репозитория дистрибутива. Официальная документация прямо указывает, что пакет из nginx.org — рекомендуемый способ для production, а пакет из системного репозитория удобен для обучения и тестов, но может быть устаревшим.

Ubuntu / Debian: официальный stable-репозиторий

Ниже — сокращённая практическая схема для Ubuntu. Для Debian отличается только строка репозитория: вместо packages/ubuntu используется packages/debian. Команды соответствуют официальной процедуре установки NGINX Open Source через apt.

sudo apt update
sudo apt install -y curl gnupg2 ca-certificates lsb-release ubuntu-keyring

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
  | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
https://nginx.org/packages/ubuntu $(lsb_release -cs) nginx" \
  | sudo tee /etc/apt/sources.list.d/nginx.list

echo -e "Package: *\nPin: origin nginx.org\nPin: release o=nginx\nPin-Priority: 900\n" \
  | sudo tee /etc/apt/preferences.d/99nginx

sudo apt update
sudo apt install -y nginx

sudo nginx -v
sudo nginx -t

Если вам нужны самые новые функции Nginx, например свежие изменения mainline-ветки, используйте https://nginx.org/packages/mainline/ubuntu. Для инфраструктуры, где важнее предсказуемость, выбирайте stable.

RHEL / Rocky / AlmaLinux / Amazon Linux 2023

Для RHEL-подобных систем официальный гайд допускает установку через dnf; если пакет недоступен в системном репозитории, используется EPEL, но для production всё равно предпочтителен официальный репозиторий nginx.org.

Минимальная проверка после установки:

sudo nginx -v
sudo nginx -V
sudo nginx -t
systemctl status nginx

Особенно важна команда nginx -V: она показывает, с какими модулями собран бинарник, где лежит nginx.conf, какие пути используются для логов и включены ли модули вроде http_ssl_module, http_v2_module, http_v3_module.

Базовая архитектура Nginx: master, workers и лимиты

Nginx запускает master-процесс и один или несколько worker-процессов. Master читает конфигурацию и управляет workers, а workers фактически обрабатывают клиентские запросы. Количество workers задаётся директивой worker_processes; значение auto позволяет Nginx ориентироваться на доступные CPU-ядра.

Ключевая ловушка: worker_connections — это не только клиентские соединения. В это число входят и соединения с upstream-серверами, поэтому reverse proxy обычно расходует больше дескрипторов, чем кажется. Официальная документация подчёркивает, что фактическое число одновременных соединений также ограничено лимитом открытых файлов, который можно менять через worker_rlimit_nofile.

Стартовая конфигурация worker-процессов

user nginx;

worker_processes auto;
worker_rlimit_nofile 200000;

events {
    worker_connections 32768;
}

Как оценить верхнюю границу:

потенциальные соединения ≈ worker_processes × worker_connections

Но для reverse proxy эту цифру нельзя трактовать как «столько клиентов выдержит сервер». Один клиентский запрос может занимать клиентское соединение плюс соединение к backend. Добавьте TLS, HTTP/2 streams, keep-alive, кэш, логирование и реальные лимиты ОС — и расчёт становится инфраструктурным, а не арифметическим.

Практический подход:

Поставьте worker_processes auto.
Поднимите worker_rlimit_nofile.
Согласуйте системный лимит сервиса Nginx через systemd или init-систему.
Проверяйте под нагрузкой error.log: если появляются too many open files, Nginx упёрся не в CPU, а в лимиты дескрипторов.

HTTP-настройки: keep-alive, sendfile и кэш открытых файлов

Для статических файлов и смешанных web-нагрузок базовый блок http может выглядеть так:

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    keepalive_timeout 30s;
    keepalive_requests 1000;

    open_file_cache          max=10000 inactive=60s;
    open_file_cache_valid    120s;
    open_file_cache_min_uses 2;
    open_file_cache_errors   on;

    include /etc/nginx/conf.d/*.conf;
}

sendfile on включает передачу файлов через системный вызов sendfile(), а tcp_nopush on на Linux использует TCP_CORK и работает только вместе с sendfile; это помогает отправлять заголовки и начало файла в одном пакете и отдавать файл полными пакетами.

keepalive_timeout управляет временем, в течение которого keep-alive соединение остаётся открытым, а keepalive_requests ограничивает число запросов через одно keep-alive соединение. Слишком маленькие значения увеличивают число повторных TCP/TLS handshakes, слишком большие — удерживают память и дескрипторы на неактивных клиентах.

open_file_cache полезен для серверов, которые часто отдают статические файлы: Nginx может кэшировать файловые дескрипторы, размеры, времена изменения, сведения о директориях и даже ошибки поиска файлов, если включён open_file_cache_errors.

HTTP/2: включать через директиву http2 on

Для актуальных версий Nginx корректный способ включить HTTP/2 — отдельная директива http2 on, а не старый стиль listen 443 ssl http2. Директива http2 появилась в версии 1.25.1 и включается в контексте http или server; для HTTP/2 поверх TLS требуется ALPN-поддержка в OpenSSL.

server {
    listen 443 ssl;
    http2 on;

    server_name example.com;

    ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    root /var/www/example.com/public;
    index index.html;
}

HTTP/2 особенно полезен там, где много мелких ресурсов: CSS, JS, изображения, шрифты. Но он не отменяет необходимости нормального кэширования, сжатия и оптимизации frontend-сборки.

HTTP/3 / QUIC: опционально, осторожно, после тестов

Поддержка QUIC и HTTP/3 доступна в Nginx начиная с 1.25.0 и включена в Linux binary packages, но официальный модуль ngx_http_v3_module всё ещё помечен как experimental. Поэтому HTTP/3 стоит включать только после проверки клиентов, сертификатов, firewall и наблюдаемости.

Минимальный пример:

server {
    listen 443 ssl;
    listen 443 quic reuseport;

    http2 on;
    http3 on;

    server_name example.com;

    ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    location / {
        root /var/www/example.com/public;
    }
}

Для QUIC нужен UDP/443, а не только TCP/443. Если включаете HTTP/3 за cloud firewall, security group или балансировщиком, отдельно проверьте UDP. Официальная документация также рекомендует использовать reuseport вместе с quic при нескольких workers.

Что не стоит делать сразу:

включать 0-RTT без понимания replay-рисков;
считать HTTP/3 заменой HTTP/2;
включать QUIC без метрик по ошибкам соединений;
полагаться только на браузерную проверку — используйте отдельные CLI-клиенты и логи.

TLS: меньше CPU на повторные соединения

Базовая TLS-конфигурация для производительности должна включать TLS session cache. Официальная документация Nginx рекомендует для снижения нагрузки на процессор включать keep-alive, shared session cache и не использовать только built-in cache OpenSSL, потому что shared cache эффективнее между worker-процессами.

http {
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;

    server {
        listen 443 ssl;
        http2 on;

        server_name example.com;

        ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
        ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;
    }
}

Если у вас несколько Nginx-инстансов за балансировщиком, продумайте TLS ticket key rotation. В Nginx можно явно задать ssl_session_ticket_key; если ключей несколько, первый используется для шифрования новых tickets, а остальные — для расшифровки, что позволяет выполнять ротацию.

Сжатие: gzip включать выборочно, не сжимать всё подряд

Gzip снижает объём передаваемых текстовых данных, но тратит CPU. На серверах с большим количеством статических ассетов лучше заранее готовить сжатые файлы в CI/CD и отдавать их через gzip_static, а runtime-сжатие оставить для динамических текстовых ответов.

server {
    gzip on;
    gzip_min_length 1000;
    gzip_types
        text/plain
        text/css
        application/json
        application/javascript
        application/xml
        image/svg+xml;

    gzip_proxied no-cache no-store private expired auth;
}

Официальная документация указывает, что gzip_min_length задаёт минимальный размер ответа для сжатия, gzip_proxied управляет сжатием ответов на proxied-запросы, а gzip_static on позволяет отдавать заранее подготовленный .gz-файл, если клиент поддерживает gzip.

Для уже сжатых форматов — JPEG, PNG, WebP, AVIF, MP4, ZIP, WOFF2 — gzip обычно бесполезен: CPU тратится, а размер почти не меняется.

Reverse proxy: буферы, keep-alive и upstream-кэш

В Nginx 1.30.0 поведение reverse proxy стало удобнее: upstream keep-alive включён по умолчанию через переход proxy HTTP version на HTTP/1.1, начиная с изменений 1.29.7. Но это не отменяет необходимости настраивать upstream-зоны, health-подход, таймауты, буферы и кэш.

Пример upstream и proxy-блока:

upstream app_backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

server {
    listen 443 ssl;
    http2 on;

    server_name app.example.com;

    ssl_certificate     /etc/nginx/certs/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/app.example.com/privkey.pem;

    location / {
        proxy_pass http://app_backend;

        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 3s;
        proxy_send_timeout    30s;
        proxy_read_timeout    30s;
    }
}

Если вы поддерживаете конфиги для Nginx до 1.29.7, явно оставляйте старую пару директив:

proxy_http_version 1.1;
proxy_set_header Connection "";

Для Nginx 1.30.0 это обычно уже не нужно, но в смешанных окружениях такая явность помогает избежать деградации после отката версии.

Proxy cache: самый сильный рычаг для разгрузки backend

Кэш Nginx особенно полезен для HTML-страниц с коротким TTL, API-ответов с безопасной кэшируемостью, изображений, файлов и страниц, где допустима отдача stale-копии при сбое backend.

proxy_cache_path /var/cache/nginx/proxy
    levels=1:2
    keys_zone=app_cache:100m
    max_size=10g
    inactive=60m
    use_temp_path=off;

server {
    listen 443 ssl;
    http2 on;

    server_name app.example.com;

    location / {
        proxy_pass http://app_backend;

        proxy_cache app_cache;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;

        proxy_cache_lock on;
        proxy_cache_revalidate on;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;

        add_header X-Cache-Status $upstream_cache_status always;
    }
}

proxy_cache_lock on не даёт множеству одинаковых запросов одновременно прогревать один и тот же новый cache item: только один запрос идёт к backend, остальные ждут результат или истечение lock timeout. proxy_cache_use_stale updating позволяет отдавать устаревшую копию, пока она обновляется, что снижает давление на upstream при всплесках трафика.

use_temp_path=off полезен, когда cache и временные файлы находятся на одном файловом разделе: официальная документация предупреждает, что если временный файл и кэш расположены на разных файловых системах, вместо дешёвого rename может происходить копирование между файловыми системами.

Early Hints: ускорение загрузки критичных ресурсов

В Nginx 1.30.0 в stable-ветку вошла поддержка HTTP 103 Early Hints. Директива early_hints появилась в 1.29.0 и позволяет передавать клиенту 103-ответ при выполнении заданного условия; полученные от upstream 103 responses передаются клиенту без интерпретации.

Типичный сценарий — backend отдаёт Link: </app.css>; rel=preload; as=style, а Nginx пропускает Early Hints клиенту. Это может ускорить загрузку критичных CSS/JS, но требует проверки в вашем frontend-пайплайне и браузерной матрице.

map $http_sec_fetch_mode $early_hints_flag {
    navigate $http2$http3;
}

server {
    listen 443 ssl;
    http2 on;

    location / {
        early_hints $early_hints_flag;
        proxy_pass http://app_backend;
    }
}

Логи: производительность начинается с наблюдаемости

Не отключайте логи вслепую. На высоконагруженных серверах логирование действительно может стать заметной нагрузкой, но лучше сначала сделать его управляемым:

вынести access log на быстрый диск или в stdout контейнера;
использовать sampling для шумных health-check;
добавить $request_time, $upstream_response_time, $upstream_cache_status;
проверять error log после каждого изменения лимитов и таймаутов.

Пример формата:

log_format main_ext
    '$remote_addr $host "$request" $status $body_bytes_sent '
    'rt=$request_time urt=$upstream_response_time '
    'cache=$upstream_cache_status '
    'ua="$http_user_agent"';

access_log /var/log/nginx/access.log main_ext;

Главная цель логов — быстро отличать проблему Nginx от проблемы backend, сети, DNS, диска или клиента.

Безопасная проверка конфигурации и reload без простоя

Nginx поддерживает управление процессами через сигналы: reload перечитывает конфигурацию, quit выполняет graceful shutdown, reopen переоткрывает логи, stop завершает процесс быстро. Официальная документация описывает это через nginx -s <SIGNAL>.

Рабочая последовательность:

sudo nginx -t
sudo systemctl reload nginx

Если вы не используете systemd:

sudo nginx -t
sudo nginx -s reload

После reload проверьте:

sudo journalctl -u nginx --since "5 minutes ago"
sudo tail -n 100 /var/log/nginx/error.log
curl -I https://example.com

Чек-лист максимальной производительности

Установка

Nginx установлен из официального nginx.org-репозитория.
Версия проверена через nginx -v.
Сборка проверена через nginx -V.
Конфигурация проходит nginx -t.

Процессы и лимиты

worker_processes auto.
worker_connections рассчитан с учётом backend-соединений.
worker_rlimit_nofile и системный LimitNOFILE согласованы.
В логах нет too many open files.

HTTP и файлы

sendfile on.
tcp_nopush on для static-heavy нагрузки.
keepalive_timeout не завышен.
open_file_cache включён для статических сайтов.

TLS и протоколы

Используются TLS 1.2 и TLS 1.3.
Включён ssl_session_cache shared:SSL:....
HTTP/2 включён через http2 on.
HTTP/3 включён только после тестирования UDP/443 и клиентской совместимости.

Reverse proxy

Для Nginx 1.30.0 учтено новое поведение upstream keep-alive.
Для старых версий явно задано proxy_http_version 1.1.
Таймауты backend не бесконечные.
Для кэшируемых ответов включён proxy_cache.

Кэш

proxy_cache_path находится на подходящем диске.
use_temp_path=off, если temp и cache на одном разделе.
Включён proxy_cache_lock.
Настроен proxy_cache_use_stale.
В ответ добавлен X-Cache-Status для диагностики.

Итог

Максимальная производительность Nginx — это аккуратно собранная система: актуальный пакет, правильные workers, достаточные файловые лимиты, современный TLS, HTTP/2, осторожный HTTP/3, эффективная отдача файлов и кэширование upstream-ответов. Начните с официального пакета и базовых лимитов, затем включайте протоколы и кэш, а каждый шаг подтверждайте метриками, логами и нагрузочным тестом.