Оптимизация производительности Nginx: готовые конфигурации nginx.conf для высоких нагрузок | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Оптимизация производительности Nginx: готовые конфигурации nginx.conf для высоких нагрузок

06 апреля 2026 8 мин. чтения
Содержание статьи

Оптимизация производительности Nginx — это системный процесс настройки ключевых параметров конфигурационного файла nginx.conf, основанный на понимании архитектуры сервера и текущих узких мест. Эта статья предоставляет пошаговое руководство, которое поможет вам рассчитать оптимальные значения для worker_processes, worker_connections, настроить keepalive и буферы под конкретное оборудование и тип нагрузки. Вы получите готовые рабочие конфигурации для сценариев с высоким трафиком статики, API-серверов и серверов с ограниченной памятью, а также четкий план безопасного тестирования и внедрения изменений в production-среде.

Инструкции проверены на практике и направлены на решение конкретных проблем: ошибок 502, исчерпания памяти, высокого потребления CPU. Мы разберем взаимосвязь параметров и аппаратных ресурсов, чтобы вы могли осмысленно адаптировать настройки под свою инфраструктуру, избегая типичных ошибок.

Основы архитектуры Nginx и планирование оптимизации

Nginx использует асинхронную, событийно-ориентированную архитектуру. Главный (master) процесс управляет несколькими рабочими (worker) процессами, которые обрабатывают входящие соединения. Эта модель эффективно использует многоядерные процессоры и позволяет обрабатывать тысячи одновременных соединений с низким потреблением памяти.

Перед любыми изменениями необходимо собрать базовые метрики:

  • CPU: Утилизация ядер (команда top или htop).
  • Память: Потребление рабочими процессами Nginx (RSS в top).
  • Файловые дескрипторы: Ограничение системы (ulimit -n) и текущее использование.
  • Активные соединения: Можно отслеживать через nginx -V с модулем stub_status или сторонние системы мониторинга.

Ключевая формула для оценки максимального количества одновременных соединений:

max_clients = worker_processes * worker_connections

Однако это теоретический максимум. Реальное число ограничивается доступной памятью, производительностью backend-сервисов и настройками операционной системы. Анализ типа трафика (статические файлы, API с короткими запросами, long-polling) критически важен для выбора стратегии оптимизации.

Как модель обработки запросов влияет на параметры

Параметры worker_processes, worker_connections и keepalive тесно взаимосвязаны. Увеличение worker_connections без корректировки системного лимита на файловые дескрипторы (ulimit -n) приведет к ошибкам «Too many open files». Директива worker_rlimit_nofile позволяет задать лимит специально для процессов Nginx, обходя глобальные ограничения ОС.

Параметр keepalive_timeout определяет, как долго соединение с клиентом остается открытым после обработки запроса, ожидая новых. Высокие значения уменьшают накладные расходы на установку новых TCP-соединений, что полезно для статического контента, но увеличивают потребление памяти и могут исчерпать доступные worker_connections при высокой нагрузке.

Определение целевых метрик и текущих узких мест

Диагностику начинайте с анализа логов Nginx (error.log). Типовые симптомы и их возможные причины:

  • Ошибки 502 Bad Gateway: Проблемы с доступностью или производительностью backend-серверов. Проверьте таймауты в директивах proxy_connect_timeout, proxy_read_timeout.
  • Ошибки 503 Service Temporarily Unavailable: Часто указывают на исчерпание соединений в upstream-блоке. Требуется оптимизация keepalive для соединений с бэкендами.
  • Высокая утилизация CPU: Может быть вызвана неоптимальной обработкой SSL/TLS, отсутствием кэширования или неверным количеством worker_processes.
  • Рост потребления памяти (OOM kills): Слишком большие буферы (client_body_buffer_size), большое количество активных keepalive-соединений или утечки в сторонних модулях.

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

Ключевые директивы nginx.conf: детальный разбор и расчет значений

Перейдем к практической части — настройке основных директив. Все изменения вносите в основной файл конфигурации, обычно расположенный в /etc/nginx/nginx.conf.

worker_processes и worker_connections: расчет под ваше оборудование

worker_processes: Определяет количество рабочих процессов. Рекомендации:

  • worker_processes auto; — Nginx автоматически установит количество, равное числу ядер CPU. Оптимальный выбор для большинства случаев.
  • Для точного контроля укажите число. На серверах с 16+ ядрами иногда выгодно установить значение меньше количества ядер (например, 12 на 16-ядерном CPU), чтобы оставить ресурсы для других системных процессов.
  • На виртуальных машинах или облачных инстансах с shared vCPU значение auto может быть неоптимальным. Сверьтесь с фактическим количеством vCPU, которое гарантирует провайдер.

worker_connections: Максимальное число одновременных соединений, которое может обработать один рабочий процесс. Расчет:

  1. Узнайте системный лимит на файловые дескрипторы: ulimit -n (например, 1024).
  2. Установите worker_connections меньше этого значения, учитывая, что на процесс Nginx также тратятся дескрипторы на логи, файлы статики, соединения с бэкендами.
  3. Для высоких нагрузок увеличьте системный лимит и используйте директиву worker_rlimit_nofile.

Пример для сервера с 8 ядрами и лимитом в 65536 дескрипторов:

worker_processes 8;
worker_rlimit_nofile 65536;

events {
    worker_connections 8192; # 65536 / 8 = 8192
    use epoll; # для Linux
    multi_accept on;
}

keepalive: баланс между скоростью и потреблением ресурсов

Настройки keepalive находятся в блоках http, server или location.

  • keepalive_timeout: Время в секундах, в течение которого keepalive-соединение с клиентом остается открытым.
    • Для API с множеством коротких запросов: keepalive_timeout 15;
    • Для серверов статического контента: keepalive_timeout 30 25; (таймаут 30с, заголовок Keep-Alive: timeout=25 в ответе).
  • keepalive_requests: Количество запросов, которые можно сделать через одно keepalive-соединение. После достижения лимита соединение закрывается. Значение 1000 является хорошим компромиссом для большинства сценариев.

Не забудьте также настроить keepalive для соединений с upstream-серверами (бэкендами), что критически важно для производительности. Подробные конфигурации для построения отказоустойчивых кластеров вы найдете в статье: Nginx как балансировщик нагрузки: продвинутая настройка.

Оптимизация буферов и таймаутов для предотвращения ошибок

Неправильные настройки буферов — частая причина ошибок 413 (Request Entity Too Large) и 400 (Bad Request).

  • client_body_buffer_size: Определяет размер буфера для тела запроса клиента. Если запрос превышает этот размер, тело записывается во временный файл, что замедляет обработку. Для API, принимающих JSON, достаточно 16k-64k. Для загрузки файлов может потребоваться 1M или больше.
    client_body_buffer_size 64k;
  • client_header_buffer_size и large_client_header_buffers: Управляют буферизацией заголовков запроса.
    client_header_buffer_size 2k;
large_client_header_buffers 4 8k;
  • Таймауты: Защищают от медленных клиентов.
    client_body_timeout 12s;
client_header_timeout 12s;
send_timeout 10s;

Готовые конфигурации nginx.conf для типовых сценариев высокой нагрузки

Ниже представлены готовые блоки конфигурации. Вставляйте их в соответствующие секции вашего nginx.conf и адаптируйте под свои нужды.

Сценарий 1: Сервер статического контента (высокий трафик, низкая задержка)

Оптимизирован для раздачи изображений, CSS, JS, видео. Акцент на эффективное использование keepalive и отправку файлов.

user www-data;
worker_processes auto;
worker_rlimit_nofile 100000;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 4096;
    use epoll;
    multi_accept on;
}

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

    # Базовые оптимизации отправки
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Keepalive для клиентов
    keepalive_timeout 30;
    keepalive_requests 1000;

    # Буферы
    client_body_buffer_size 128k;
    client_header_buffer_size 3k;
    large_client_header_buffers 4 16k;
    client_max_body_size 20m; # для загрузки файлов

    # Таймауты
    client_body_timeout 15s;
    client_header_timeout 15s;
    send_timeout 15s;

    # Кэширование статики в памяти (опционально)
    open_file_cache max=200000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    # Пример server блока
    server {
        listen 80;
        server_name example.com;
        root /var/www/html;

        location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff2)$ {
            expires 365d;
            add_header Cache-Control "public, immutable";
            access_log off;
        }
    }
}

Сценарий 2: API-сервер (микросервисы, множество коротких запросов)

Конфигурация для backend API, где важна скорость обработки тысяч коротких запросов в секунду (RPS).

user www-data;
worker_processes auto;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 2048;
    use epoll;
    multi_accept on;
}

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

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Короткие keepalive для быстрого освобождения соединений
    keepalive_timeout 10s;
    keepalive_requests 5000; # Высокое значение для API

    # Буферы под небольшие JSON-запросы
    client_body_buffer_size 16k;
    client_header_buffer_size 2k;
    large_client_header_buffers 2 4k;
    client_max_body_size 5m;

    # Таймауты
    client_body_timeout 10s;
    client_header_timeout 10s;
    send_timeout 10s;
    reset_timedout_connection on; # Сброс зависших соединений

    # Upstream для балансировки нагрузки на бэкенды
    upstream api_backend {
        least_conn; # Алгоритм балансировки для API
        server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
        server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
        keepalive 32; # Кэш keepalive-соединений к бэкендам
    }

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

        location / {
            proxy_pass http://api_backend;
            proxy_http_version 1.1;
            proxy_set_header Connection ""; # Важно для upstream keepalive
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

Для углубленного изучения алгоритмов балансировки и выбора оптимальной стратегии под ваше приложение смотрите наше руководство: Балансировка нагрузки в Nginx: алгоритмы и стратегии.

Сценарий 3: Сервер с ограниченными ресурсами (малая память)

Настройки для виртуальных машин или контейнеров с 512MB-1GB RAM. Приоритет — предотвращение исчерпания памяти.

user www-data;
worker_processes 1; # Один процесс для экономии памяти
worker_rlimit_core 0; # Отключение core dump для экономии места

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 768; # Ограниченное число соединений
    use epoll;
}

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

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Агрессивный keepalive_timeout для быстрого освобождения памяти
    keepalive_timeout 5 5;
    keepalive_requests 200;

    # Минимальные буферы
    client_body_buffer_size 8k;
    client_header_buffer_size 1k;
    large_client_header_buffers 2 2k;
    client_max_body_size 2m;

    # Таймауты
    client_body_timeout 5s;
    client_header_timeout 5s;
    send_timeout 5s;
    reset_timedout_connection on;

    # Отключение ненужных логов для экономии IO
    access_log off;
    # или логирование только ошибок
    # access_log /var/log/nginx/access.log combined buffer=32k flush=5s;

    server {
        listen 80;
        server_name small.example.com;
        root /var/www/html;

        # Базовый кэш статики без использования open_file_cache
        location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
            expires 30d;
            add_header Cache-Control "public";
        }
    }
}

План безопасного тестирования и внедрения изменений

Любые изменения в конфигурации production-сервера требуют строгой процедуры тестирования. Следуйте этому плану, чтобы минимизировать риски.

Нагрузочное тестирование: инструменты и ключевые метрики

Перед внедрением на боевой сервер протестируйте новую конфигурацию на stage-среде, максимально похожей на production.

  1. Проверка синтаксиса: nginx -t
  2. Применение конфигурации на тестовом сервере: nginx -s reload
  3. Нагрузочное тестирование: Используйте инструменты вроде wrk или ab (ApacheBench).
    # Пример с wrk: 10 потоков, 100 соединений, тест длительностью 30 секунд
wrk -t10 -c100 -d30s --latency http://your-test-server.com/

# Пример с ab: 1000 запросов, 10 одновременных соединений
ab -n 1000 -c 10 http://your-test-server.com/
  4. Ключевые метрики для сравнения «до/после»:
    • RPS (Requests Per Second): Количество успешно обработанных запросов в секунду.
    • Latency (Задержка): Среднее, 95-й и 99-й процентили времени ответа.
    • Количество ошибок: HTTP-статусы 5xx, таймауты.
    • Потребление ресурсов: Память (RSS) и CPU каждого worker-процесса.

Процедура отката и мониторинг после внедрения

После успешного тестирования на stage запланируйте внедрение на production.

  1. Резервное копирование текущей конфигурации: cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup_$(date +%Y%m%d)
  2. Плавный reload: Применяйте изменения командой nginx -s reload. Она позволяет мастер-процессу загрузить новую конфигурацию и плавно перезапустить рабочие процессы без разрыва established-соединений.
  3. Мониторинг в реальном времени (первые 1-2 часа):
    • Проверяйте error.log на наличие новых ошибок: tail -f /var/log/nginx/error.log
    • Следите за использованием памяти и CPU.
    • Используйте status page Nginx (если модуль stub_status включен) для отслеживания активных соединений и запросов.
  4. Процедура отката при проблемах: Если возникли критические ошибки, немедленно верните старую конфигурацию:
    cp /etc/nginx/nginx.conf.backup_* /etc/nginx/nginx.conf
nginx -s reload

Для построения комплексной системы мониторинга и автоматического реагирования на атаки, которая дополнит оптимизацию производительности, изучите руководство: Защита Nginx от DDoS-атак.

Адаптация под версии Nginx и операционные системы

Рекомендации в этой статье актуальны для основных стабильных версий Nginx 1.18+, включая 1.20 и 1.22. Однако всегда проверяйте документацию для вашей конкретной версии (nginx -V).

  • Директива reuseport (в блоке listen): Доступна с версии 1.9.1. Позволяет каждому worker-процессу слушать на отдельном socket, что может уменьшить lock contention и улучшить производительность на многопроцессорных системах.
  • Настройки операционной системы:
    • Linux: Проверьте и при необходимости настройте параметры сетевого стека в /etc/sysctl.conf (например, net.core.somaxconn, net.ipv4.tcp_tw_reuse).
    • Файловые дескрипторы: Убедитесь, что значение worker_rlimit_nofile не превышает системный хард-лимит, установленный в /etc/security/limits.conf.
  • FreeBSD: В блоке events вместо use epoll; используйте use kqueue;.

Перед применением любых сетевых настроек ОС тщательно изучите их влияние. Для создания максимально защищенного и оптимизированного сервера рекомендуем ознакомиться с нашим актуальным руководством: Защита Nginx в 2026, где собраны лучшие практики безопасности и производительности.

Поделиться:
Сохранить гайд? В закладки браузера