Перейти к содержимому
Skip to content
← Все статьи

Оптимизация производительности Nginx: ключевые настройки

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

Worker-процессы и соединения

Самые фундаментальные параметры настройки определяют количество воркеров и число соединений на каждый:

# /etc/nginx/nginx.conf

# Установить по числу ядер CPU (auto определяет автоматически)
worker_processes auto;

# Максимум открытых файлов на воркер
worker_rlimit_nofile 65535;

events {
    # Макс. одновременных соединений на воркер
    worker_connections 4096;

    # Принимать несколько соединений за раз
    multi_accept on;

    # Использовать эффективный метод событий для Linux
    use epoll;
}

Общее число одновременных соединений: worker_processes × worker_connections. При 4 воркерах и 4096 соединениях Nginx обрабатывает 16 384 одновременных подключений.

Расчёт worker_connections

Каждое клиентское соединение обычно требует два файловых дескриптора. Безопасная формула:

worker_connections = worker_rlimit_nofile / 2

HTTP-оптимизации

http {
    # Sendfile: передача файлов на уровне ядра (без копирования в userspace)
    sendfile on;

    # Отправка заголовков и файла в одном пакете
    tcp_nopush on;

    # Отключение алгоритма Нэгла для низкой задержки
    tcp_nodelay on;

    # Поддержание соединений для уменьшения накладных расходов TCP
    keepalive_timeout 65;
    keepalive_requests 1000;

    # Уменьшение накладных расходов хеш-таблиц
    types_hash_max_size 2048;
    server_names_hash_bucket_size 64;

    # Скрыть версию Nginx (безопасность)
    server_tokens off;
}

sendfile, tcp_nopush и tcp_nodelay

Эти три директивы работают вместе для оптимизации передачи данных:

ДирективаДействиеКогда использовать
sendfileПередача файлов в пространстве ядра (zero-copy)Всегда для статических файлов
tcp_nopushОтправка заголовков и начала файла в одном TCP-пакетеВместе с sendfile для статики
tcp_nodelayОтключение буферизации Нэгла, немедленная отправка пакетовДля keepalive и проксированного контента

Gzip-сжатие

Сжатие уменьшает размер ответа на 60-80%, значительно ускоряя загрузку страниц для текстового контента:

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 5;         # 1-9, оптимум 4-6
    gzip_min_length 256;       # Не сжимать крошечные ответы
    gzip_http_version 1.1;

    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/json
        application/javascript
        application/xml
        application/rss+xml
        application/atom+xml
        application/vnd.ms-fontobject
        font/opentype
        image/svg+xml;
}

Уровень сжатия 5 обеспечивает около 90% степени сжатия уровня 9 при значительно меньшей нагрузке на CPU. Для высоконагруженных сайтов рассмотрите предварительное сжатие с gzip_static on.

Brotli-сжатие

Brotli обеспечивает на 15-25% лучшее сжатие, чем gzip для текстового контента:

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Настройка буферов

Буферы управляют хранением данных запросов и ответов в памяти. Правильный размер предотвращает дисковый I/O:

http {
    # Буферы клиентских запросов
    client_body_buffer_size 16k;      # Буфер тела POST
    client_header_buffer_size 1k;     # Буфер заголовков
    large_client_header_buffers 4 8k; # Большие заголовки (cookies)
    client_max_body_size 16m;         # Макс. размер загрузки

    # Буферы прокси (для режима обратного прокси)
    proxy_buffer_size 4k;
    proxy_buffers 8 16k;
    proxy_busy_buffers_size 32k;
}

location /api/ {
    # Увеличенные буферы для JSON-ответов API
    proxy_buffer_size 8k;
    proxy_buffers 16 32k;
    proxy_busy_buffers_size 64k;
    proxy_pass http://api_backend;
}

Кэширование статических файлов

Агрессивное кэширование статики снижает нагрузку на сервер:

# Статические ассеты с долгим кэшем
location ~* \.(jpg|jpeg|png|gif|ico|webp|avif)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    access_log off;
}

location ~* \.(css|js)$ {
    expires 7d;
    add_header Cache-Control "public";
    access_log off;
}

location ~* \.(woff|woff2|ttf|eot)$ {
    expires 365d;
    add_header Cache-Control "public, immutable";
    access_log off;
}

# Кэш открытых файлов в памяти
open_file_cache max=10000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

Оптимизация SSL/TLS

http {
    # Кэширование SSL-сессий — избегаем пересогласования
    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # Только современный TLS
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # OCSP-степлинг — ускоряет TLS-рукопожатие
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;
}

Ограничение скорости

Защита от злоупотреблений и DDoS:

http {
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        location /api/ {
            limit_req zone=api burst=20 nodelay;
            limit_req_status 429;
            proxy_pass http://api_backend;
        }

        location /login {
            limit_req zone=login burst=5;
            limit_conn addr 5;
            proxy_pass http://app_backend;
        }
    }
}

Оптимизация upstream

upstream backend {
    least_conn;

    server 10.0.1.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.2:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.3:8080 backup;

    # Keepalive-соединения к upstream
    keepalive 32;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";  # Обязательно для keepalive
    }
}

Мониторинг производительности Nginx

# Включение stub_status для базовых метрик
location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}

# Вывод:
# Active connections: 291
# server accepts handled requests
#  16630948 16630948 31070465
# Reading: 6 Writing: 179 Waiting: 106

Ключевые метрики: активные соединения, запросы в секунду, время ответа, частота ошибок (4xx/5xx) и время ответа upstream.

Итоги

Оптимизация Nginx включает настройку worker-процессов под количество ядер CPU, включение эффективного I/O с sendfile и epoll, сжатие ответов gzip или Brotli, правильный размер буферов, агрессивное кэширование статики и настройку SSL для минимальных накладных расходов на рукопожатие. Наиболее эффективные изменения — включение gzip-сжатия, настройка keepalive-соединений и правильные заголовки кэширования для статических ресурсов. Всегда проводите бенчмарк до и после изменений для измерения реального улучшения.

Проверьте ваш сайт прямо сейчас

Проверить →
Другие статьи: Инфраструктура
Инфраструктура
Пул соединений с БД: как работает и лучшие практики
16.03.2026 · 10 просм.
Инфраструктура
Мульти-CDN стратегия: отказоустойчивость, оптимизация затрат и распределение трафика
16.03.2026 · 26 просм.
Инфраструктура
Обратный прокси: как работает и зачем нужен
16.03.2026 · 15 просм.
Инфраструктура
Стратегии версионирования API: URL, заголовки и параметры запроса
16.03.2026 · 22 просм.