Оптимальная настройка функции Keepalive в NGINX для обеспечения максимальной производительности в качестве обратного прокси-сервера

Я настраиваю функцию «Upstream Keepalive» в NGINX таким образом, чтобы обратный прокси устанавливал меньшее количество соединений, обеспечивал меньшую задержку и надежно справлялся с пиковыми нагрузками. При этом я настраиваю Размер бассейна, целенаправленно настраивайте временные ограничения и заголовки, чтобы соединения использовались повторно, а путь передачи данных оставался оптимизированным.

Центральные пункты

• HTTP/1.1 принудительно выполнить и очистить заголовки соединения
• keepalive правильно рассчитать размеры для каждого работника
• Тайм-ауты подстроить под значения бэкэнда
• Запросы/Соединение сокращать и перерабатывать
• Мониторинг для скорости соединения и задержки

Почему Upstream Keepalive значительно сокращает нагрузку при установке соединений

Без повторного использования NGINX открывает новое соединение с бэкендом для каждого запроса, что требует дополнительных рукопожатий, большего количества циклов ЦП и дополнительных ресурсов ядра; именно здесь вступает в действие Keepalive . Я настраиваю NGINX так, чтобы он кэшировал уже установленные, но в данный момент неактивные сокеты и использовал их для последующих запросов, что заметно сокращает время установления соединения. Это снижает частоту соединений в секунду, уменьшает пиковые значения задержки обработки запросов и замедляет переключение контекста в операционной системе. Особенно при использовании TLS для связи с бэкендом я заметно экономлю время за счёт повторного использования сеансов. Таким образом, цепочка ответов остаётся стабильной даже при высокой пропускной способности надежный и реагирует плавно.

Основной принцип и директива keepalive в Upstream

Директива keepalive В блоке upstream ограничивается количество промежуточно кэшируемых неактивных бэкенд-соединений на каждый рабочий процесс. Это ограничение действует не глобально, а строго для каждого рабочего процесса, поэтому я всегда слежу за количеством рабочих процессов. Когда пул заполняется, NGINX сначала закрывает соединение, которое дольше всего простаивает, чтобы освободить место для новых сокетов. Для повторного использования прокси-серверу требуется HTTP/1.1 и нейтрализованный заголовок Connection. Без этих условий пул остаётся пустым, хотя я и устанавливаю в upstreame параметр „keepalive“, что многие администраторы вначале удивлен.

upstream backend_pool {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;

    keepalive 32; # простоя для каждого рабочего процесса
    keepalive_requests 1000;   # перезапуск после N запросов
    keepalive_timeout 60s;     # время простоя
}

server {
    listen 80;
    location / {
 proxy_pass http://backend_pool;
 proxy_http_version 1.1;
 proxy_set_header Connection "";
    }
}

Обязательные директивы в блоке «Location»: HTTP/1.1 и контроль заголовков

Я принудительно настраиваю NGINX в прокси-пути на использование HTTP/1.1, поскольку Keepalive с HTTP/1.0 работает некорректно, и соединения неоправданно прерываются; директива proxy_http_version Поэтому 1.1 является обязательным. Кроме того, я удаляю заголовок Connection для обычных запросов, чтобы бэкенд не получал команду „close“. Для обновлений, таких как WebSockets, я целенаправленно устанавливаю „Connection: Upgrade“ с помощью map, не нарушая при этом обычного повторного использования. Таким образом, политика подключения остается последовательной и не зависит от заголовков клиента. Именно это небольшое изменение предотвращает множество трудноуловимых изображения ошибок.

location / {
    proxy_pass http://backend_pool;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    "" "";
}

Точная настройка: правильный выбор значений keepalive_requests и keepalive_timeout

С помощью двух регулировочных винтов я контролирую срок службы и обновление соединений, чтобы пул оставался актуальным и не мешали заброшенные сокеты; а именно: keepalive_requests и keepalive_timeout. После N запросов NGINX целенаправленно закрывает соединение и, при необходимости, восстанавливает его, что смягчает последствия старения сети. Тайм-аут простоя я устанавливаю довольно коротким — обычно от 30 до 120 секунд, чтобы бэкэнды не прерывали соединение раньше времени. Важна правильная настройка: значение NGINX никогда не должно превышать таймаут серверов приложений, иначе будут часто происходить сбросы соединений. Те, кто хочет углубить свои знания, найдут практические рекомендации в статье Таймаут keepalive, в котором объясняются типичные величины и взаимодействия.

Для удобства ориентации я привожу типичные начальные значения и их назначение в наглядной таблице Таблица. Эти ориентировочные значения служат отправной точкой и после мониторинга часто оказываются немного выше или ниже. Слишком короткий период времени приводит к ненужному повторному установлению соединений, а слишком длинный — к сохранению старых соединений. Количество запросов на одно соединение защищает от аномальных значений, не опустошая при этом пул. Используя эти ключевые показатели, я очень быстро получаю работающие По умолчанию.

Параметры	Назначение	ориентировочное значение	Рекомендации по тюнингу
keepalive	Размер пула idle на одного рабочего процесса	32-64	Ориентироваться на одновременную нагрузку на одного рабочего
keepalive_requests	Максимальное количество запросов на соединение	500–1000	При длительных трансляциях следует установить немного более высокое значение
keepalive_timeout	Максимальное время простоя для каждого соединения	60-е годы	Меньше или равен таймауту простоя бэкенда

Определение размера пула на основе количества одновременных подключений

Я выбираю размер пула не по количеству запросов в секунду, а по Concurrency на каждый рабочий процесс. Сначала я определяю среднее и максимальное количество параллельных запросов к бэкенду. Затем делю эти цифры на количество рабочих процессов NGINX и округляю в большую сторону. При 200 одновременных запросах и четырёх рабочих процессах получается около 50 на каждый рабочий процесс, поэтому в качестве начального значения подходит keepalive 64. Таким образом, я поддерживаю доступность сокетов, не открывая при этом излишне много открытых Соединения связывать.

Осознанное использование особенностей новейших версий NGINX

В современных версиях повторное использование часто разрешено по умолчанию, однако установлены довольно консервативные ограничения; тем не менее я ввожу эти значения явно . Это обеспечивает воспроизводимость, упрощает настройку и позволяет избежать неожиданностей после обновления. С помощью параметра „local“ я по желанию ограничиваю повторное использование одним местоположением, если профили безопасности или политики заголовков различаются. Таким образом, разделение остается четким, при этом не теряются преимущества глобального повторного использования. С помощью чётких значений я документирую свои намерения и экономлю время в дальнейшем Время анализа.

Мониторинг и показатели: действительно ли конфигурация работает?

Сначала я проверяю количество новых подключений к бэкенду в секунду; заметное снижение этого показателя свидетельствует о том, что меры дают результат Повторное использование. Затем я отслеживаю показатель `upstream_connect_time`, который при попадании в пул близок к нулю. Ошибки в логах, в частности сбросы соединений, указывают на превышение временных ограничений, лежащих в основе значений бэкенда. Кроме того, я сопоставляю загрузку ЦП бэкенда и задержки с долей повторно используемых соединений. Для более глубокого понимания Повторное использование соединений Помогут примеры, демонстрирующие эти эффекты при различных режимах нагрузки.

Быстрое устранение типичных источников ошибок

Если отсутствует HTTP/1.1 для бэкэнда, соединения остаются кратковременными, независимо от того, насколько высоко я keepalive устанавливаю. Если клиент отправляет „Connection: close“, а я передаю этот заголовок без фильтрации, бэкэнд освобождает канал сразу после отправки ответа. Если таймауты простоя не совпадают, сторона приложения прерывает соединение первой, и NGINX получает сброс при следующем запросе. Слишком большой пул держит открытым слишком много сокетов и тратит оперативную память и порты. Я проверяю эти четыре пункта при каждом анализе как Первое, потому что они на 90 % объясняют все проблемы.

Практический пример: эталонная конфигурация для высокой пропускной способности

С помощью нескольких команд я привожу сильно перегруженный прокси-сервер в рабочее состояние, обеспечивая его быструю и надежную работу, а также гарантирую корректную передачу заголовков; приведенный ниже шаблон хорошо себя зарекомендовал и легко настроить. Я устанавливаю значение keepalive равным 64, ограничиваю количество запросов на одно соединение до 1000 и устанавливаю время простоя в 60 секунд. Кроме того, я корректно передаю информацию о хосте и перенаправлении, чтобы бэкэнды могли применять логику и ограничение скорости. Такое сочетание снижает нагрузку на ЦП, сокращает время отклика и позволяет более спокойно справляться с пиковыми нагрузками. Именно так я достигаю хорошо прогнозируемой Производительность.

upstream app_backend {
    server 10.0.1.10:3000 max_fails=2 fail_timeout=30s;
    server 10.0.1.11:3000 max_fails=2 fail_timeout=30s;

    keepalive 64;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

server {
    listen 80;
    server_name example.com;

    location / {
 proxy_pass http://app_backend;
 proxy_http_version 1.1;
 proxy_set_header Connection "";
 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;
    }
}

Хостинг-среды и аспекты эксплуатации, которые действительно имеют значение

Я часто размещаю NGINX перед сервисами PHP-FPM, Node.js или Java и слежу за тем, чтобы сетевые задержки оставались минимальными, а таймауты бэкенда были стабильными; это обеспечивает Планируемость. Надежная сетевая конфигурация ядра с соответствующими ограничениями на количество сокетов предотвращает конфликты между большим количеством открытых соединений. Равномерное распределение ресурсов ЦП и быстрые пути доступа к хранилищу помогают бэкендам поддерживать короткие времена отклика. Кроме того, я обеспечиваю версионирование конфигураций, чтобы изменения оставались отслеживаемыми. Благодаря такой дисциплине система стабильно работает даже при пиковых нагрузках реагирующий.

Лучшие практики для текущих операций

Я начинаю с keepalive 32–64, 500–1000 запросов на соединение и 60 секунд времени простоя, затем систематически измеряю показатели и корректирую значения; это позволяет быстро успехи. Каждое изменение я сопровождаю показателями скорости соединений, задержки и характера ошибок, пока кривые не станут более стабильными. Размер пула я подбираю исходя из количества одновременных запросов, а не из сырой пропускной способности в секунду. Время ожидания никогда не превышает аналогичных значений в бэкенд-стеке, иначе возникает риск спорадических сбросов. Те, кто хочет более тонко настроить работу, найдут рекомендации по тонкой настройке в разделе Оптимизация запросов Keepalive, что позволяет легко управлять процессом переработки.

Синхронизация таймаутов прокси и TCP-Keepalive

Помимо параметров Keepalive, я точно настраиваю временные ограничения на передачу данных. Три составляющие: proxy_connect_timeout, proxy_send_timeout и proxy_read_timeout определяет, насколько терпеливо NGINX ведет себя при установке соединения, отправке и приеме данных. Я никогда не устанавливаю эти значения выше, чем их аналоги в бэкенде, а устанавливаю чуть ниже, чтобы ошибки выявлялись на ранней стадии и не переходили на сторону приложения. Кроме того, я включаю proxy_socket_keepalive, чтобы операционная система через определённые промежутки времени отправляла сигналы активности по неактивным сокетам и выявляла полуоткрытые соединения. Это позволяет избежать ситуации, когда «мертвые» соединения остаются в пуле и вызывают всплески задержки при следующем запросе.

server {
    listen 80;

    location / {
 proxy_pass http://backend_pool;

 proxy_connect_timeout 3s;   # быстро завершить попытку, если подключение невозможно
 proxy_send_timeout    30s;  # запись в бэкенд
 proxy_read_timeout    30s;  # ответы от бэкенда
 proxy_socket_keepalive on;  # включить TCP-keepalive на уровне ОС
    }
}

Для длительных потоков (например, SSE или WebSockets) я увеличиваю исключительно таймаут чтения, в то время как таймаут подключения остается неизменным. Таким образом, я быстро реагирую на неисправные адреса, но при этом не прерываю обработку легитимных ответов, требующих длительного времени.

Планирование ресурсов: worker_connections, FD и эфемеричные порты

Чистый пул Keepalive бесполезен, если исчерпаны лимиты дескрипторов файлов или диапазоны портов. Поэтому я планирую рабочие_соединения и worker_rlimit_nofile с запасом. Приблизительно рассчитываю: открытые FD ≈ (одновременные подключения клиентов + одновременные подключения к бэкенду + сокети в пуле в режиме ожидания) на каждый рабочий процесс. Если я использую несколько апстримов с пулами, потребность умножается. Также я обращаю внимание на диапазон эфемеранных портов системы, поскольку NGINX выступает в качестве TCP-клиента в направлении бэкенда и накапливает состояния TIME_WAIT.

worker_processes auto;
worker_rlimit_nofile 131072;

events {
    worker_connections 8192;
}

Примеры настроек # для Linux (sysctl):
net.core.somaxconn = 4096
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 15

Я действую осторожно: не отключаю TIME_WAIT слишком резко, а снижаю частоту подключений с помощью Keepalive. Таким образом, параметры ядра остаются в безопасных пределах, а поведение системы — предсказуемым.

Зоны Upstream, стратегия балансировки нагрузки и ротация DNS

Если рабочих процессов несколько, я передаю состояние балансировщика через зона, чтобы показатели отказов и нагрузки оставались стабильными. Сокеты Keepalive по-прежнему остаются привязанными к каждому рабочему процессу, но их распределение становится более равномерным. В случае динамических бэкендов, которые перемещаются через DNS, я устанавливаю „resolve“ в строках сервера и определите резолвер. Важно: при ротации IP-адресов пул не сразу перерабатывает все старые сокеты; поэтому я считаю, что keepalive_requests и установить реалистичные временные рамки, чтобы обновление вступило в силу в кратчайшие сроки.

upstream backend_pool {
    zone backend_zone 128k;  # — распределение состояния балансировщика
    least_conn; # — равномерное распределение при длительных запросах

 server app-1.internal:8080 resolve;
    server app-2.internal:8080 resolve;

 keepalive 64;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

resolver 10.0.0.2 valid=30s;
resolver_timeout 5s;

proxy_next_upstream error timeout http_502 http_504;
proxy_next_upstream_tries 2;  # — небольшое количество целенаправленных повторений

Для сессий, привязанных к конкретному узлу бэкенда (например, в режиме Sticky State), я сочетаю повторное использование с ip_hash или внешний механизм управления сессиями. Это позволяет избежать нарушения когерентности сессий при использовании пула соединений.

TLS для бэкенда: SNI, повторное использование сеансов и шифры

Чем активнее используется TLS в бэкэнд-тракте, тем важнее становится функция Keepalive. Я включаю SNI, задаю ожидаемое имя и обеспечиваю повторное использование сеанса TLS. Это снижает затраты на рукопожатие и сглаживает пики задержки. Я осторожно подбираю набор шифров и протоколов, не блокируя при этом старые бэкенды. При проверке сертификата (опционально) цепочка доверия должна быть полной, иначе соединения будут периодически обрываться.

upstream https_backend {
    server backend.example.local:443;
    keepalive 32;
}

server {
    listen 443 ssl;

 location / {
 proxy_pass https://https_backend;
 proxy_http_version 1.1;
 proxy_set_header Connection "";

        proxy_ssl_server_name on;
 proxy_ssl_name backend.example.local;
 proxy_ssl_session_reuse on;
 proxy_ssl_protocols TLSv1.2 TLSv1.3;
        proxy_ssl_ciphers HIGH:!aNULL:!MD5;
 # optional: proxy_ssl_verify on;
 # optional: proxy_ssl_trusted_certificate /etc/nginx/ca.pem;
    }
}

Если я сам контролирую серверную часть, я включаю там сессионные тикеты или кэши и с помощью метрик проверяю, растут ли показатели возобновления соединений. В сочетании с Keepalive я таким образом добиваюсь стабильно низких значений времени установления соединения и рукопожатия.

Особые случаи: gRPC, WebSockets и аутентификация, привязанная к соединению

На сайте gRPC NGINX работает на верхнем уровне по протоколу HTTP/2. В данном случае наилучшие результаты часто дают небольшое количество долговечных соединений с большим количеством потоков; пул остается небольшим, но стабильным. Для WebSockets Я устанавливаю длительные таймауты чтения и оставляю логику обработки заголовков из решения с использованием map, чтобы соединения при обновлении не закрывались случайно. NTLM или другие методы аутентификации, связанные с соединением, требуют фиксации соединения (Connection Pinning); я выделяю такие пути в отдельные локации и сокращаю там использование пулов или повторное использование, чтобы не допустить смешивания протоколов безопасности между клиентами.

Пример gRPC для #
location /grpc.Service/ {
    grpc_pass grpc://backend_pool;
    grpc_read_timeout 300s;  Разрешить длинные потоки для #
}

Важно определить единую политику подключения для каждого маршрута и широко применять Keepalive только там, где это не имеет семантического значения.

Измеримость на практике: журналы доступа с временными метками Upstream

Я дополняю журнал доступа показателями Upstream. Так я могу с первого взгляда определить, пришло ли ответное сообщение из сокета пула (очень малое время соединения), и как часто возникают ошибки бэкенда. Кроме того, я регистрирую номер соединения и количество запросов, проходящих через текущее клиентское соединение, чтобы выявить взаимосвязи.

log_format upstream_timing '$remote_addr - $host "$request" '
 'up=$upstream_addr '
 'sc=$status usc=$upstream_status '
                           'cc=$connection cr=$connection_requests '
 'tc=$upstream_connect_time '
 'th=$upstream_header_time '
 'tr=$upstream_response_time';

access_log /var/log/nginx/access_upstream.log upstream_timing;

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

Стратегия внедрения и настройка с минимальными рисками

Я действую пошагово: делаю небольшие шаги, измеряю результаты, вношу корректировки. Сначала умеренно активирую Keepalive, а затем настраиваю таймауты и количество запросов на соединение. Изменения ввожу путем перезагрузки страницы, не разрывая активных соединений. Таким образом, риск остается минимальным, а результаты легко отслеживать.

# Проверить изменения и загрузить их без простоев
nginx -t && nginx -s reload

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

Краткое руководство по настройке обратного прокси-сервера

Я использую HTTP/1.1, очищаю заголовок Connection и выбираю размер пула исходя из количества одновременных запросов, а не из RPS; это способствует Производительность. С помощью параметров keepalive_requests и keepalive_timeout я поддерживаю соединения в активном состоянии и избегаю неприятных сюрпризов из-за устаревших сокетов. Мониторинг показывает, стремится ли показатель upstream_connect_time к нулю и снижается ли частота соединений с бэкендом. При возникновении ошибок я сначала проверяю версию протокола, передачу заголовков, тайм-ауты и размер пула. Так ваш прокси-сервер NGINX будет стабильно работать даже при высокой нагрузке отзывчивый и предсказуемым.