Оптимизация производительности 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-соединений и правильные заголовки кэширования для статических ресурсов. Всегда проводите бенчмарк до и после изменений для измерения реального улучшения.
Проверьте ваш сайт прямо сейчас
Проверить →