Маршрутизация TCP/UDP трафика: балансировка от HAProxy до Nginx Stream в 2026

Зачем нужна балансировка L4 и когда выбирать между HAProxy и Nginx

Балансировка нагрузки на уровне L4 работает с транспортными протоколами TCP и UDP, не анализируя содержимое передаваемых данных. Это отличает ее от балансировки уровня L7, которая работает с прикладными протоколами вроде HTTP. L4-балансировка создает единую точку входа для соединений и распределяет их между несколькими серверами-бэкендами.

Типичные сценарии использования включают организацию единого SSH-бастиона для доступа к множеству серверов, обеспечение отказоустойчивости и масштабируемости для кластеров баз данных PostgreSQL или MySQL, балансировку DNS-запросов между несколькими резолверами и предоставление контролируемого доступа к внутренним сервисам вроде Redis через один внешний IP-адрес.

Ключевой вопрос при построении такой инфраструктуры - выбор инструмента. Два основных претендента на 2026 год: проверенный временем HAProxy и модуль ngx_stream_core_module в Nginx. Выбор зависит от конкретных требований к функциональности, производительности при работе с долгоживущими соединениями и сложности администрирования.

Сценарии использования: от SSH-бастионов до кластеров PostgreSQL

Реальные задачи, которые решает L4-балансировка:

1. Единая точка входа для SSH. Вместо управления десятками SSH-ключей и белым списком IP-адресов для каждого сервера вы настраиваете один балансировщик. Все внешние подключения идут через него на порт 22, а балансировщик перенаправляет трафик на целевые бэкенды. Это упрощает контроль доступа и аудит.
2. Отказоустойчивость баз данных. В схемах репликации master-standby или master-slave клиентские приложения должны подключаться к текущему мастеру. Балансировщик с активными health checks может автоматически направлять трафик на рабочую мастер-ноду, скрывая от клиентов процесс переключения при сбое.
3. Балансировка UDP-трафика. DNS-серверы работают по протоколу UDP. Чтобы распределить нагрузку между несколькими экземплярами BIND или CoreDNS, нужен балансировщик, поддерживающий этот протокол.
4. Доступ к внутренним сервисам. Сервисы вроде кэша Redis или очереди сообщений RabbitMQ часто размещаются во внутренней сети. L4-балансировщик, размещенный на границе, может предоставлять доступ к ним извне через единый порт, дополнительно фильтруя соединения по IP-адресу источника.

Эти сценарии актуальны как для корпоративных B2B-кластеров с высокими требованиями к доступности, так и для домашних лабораторий, где важно не усложнять архитектуру.

Критерии выбора: HAProxy vs Nginx Stream в 2026

Сравнение двух технологий по ключевым параметрам:

Реклама

Выводы для 2026 года:

• Выбирайте HAProxy для сложных enterprise-сценариев, где критически важны продвинутые health checks, тонкий контроль доступа через ACL и максимальная стабильность с долгоживущими соединениями.
• Рассматривайте Nginx Stream, если ваша инфраструктура уже завязана на Nginx (для HTTP-балансировки), команда хорошо знает его синтаксис, а требования к health checks не выходят за рамки проверки доступности порта.

Для глубокого погружения в настройку HAProxy для продакшена обратитесь к нашему полному руководству по оптимизации HAProxy для production.

Классический подход: тонкая настройка HAProxy для L4-балансировки

Конфигурация HAProxy состоит из секций: global (настройки процесса), defaults (значения по умолчанию), frontend (описание входящих соединений) и backend (описание пула серверов-бэкендов). Для балансировки уровня L4 ключевая директива - mode tcp.

Рассмотрим базовую конфигурацию для балансировки порта PostgreSQL (5432) между двумя серверами:

global
    log /dev/log local0
    maxconn 4096
    daemon

defaults
    mode tcp
    timeout connect 5s
    timeout client 60m
    timeout server 60m
    log global
    option tcplog

frontend pg_frontend
    bind *:5432
    default_backend pg_backend

backend pg_backend
    balance roundrobin
    option tcp-check
    tcp-check connect port 5432
    tcp-check send PING\n
    server pg01 192.168.1.101:5432 check inter 2s fall 3 rise 2
    server pg02 192.168.1.102:5432 check inter 2s fall 3 rise 2 backup

Директива mode tcp включает режим L4-балансировки. Таймауты connect, client, server критически важны: для баз данных они устанавливаются большими (минуты), чтобы не обрывать долгие транзакции. Алгоритм balance roundrobin распределяет соединения по очереди. Сервер с меткой backup используется только при недоступности основного.

Базовая конфигурация и health checks для отказоустойчивости

Health checks - механизм проверки работоспособности бэкендов. В примере выше option tcp-check с последующими командами определяет кастомную проверку для PostgreSQL. HAProxy устанавливает TCP-соединение на порт 5432 и отправляет строку "PING". Если сервер отвечает, он считается здоровым.

Параметры check inter 2s fall 3 rise 2 означают:

• inter 2s - интервал между проверками - 2 секунды.
• fall 3 - после трех неудачных проверок сервер помечается как недоступный.
• rise 2 - после двух успешных проверок сервер возвращается в строй.

Для generic TCP-сервиса без специфичного протокола можно использовать простую проверку доступности порта: option tcp-check без дополнительных команд. Статусы серверов (UP, DOWN, MAINT) можно отслеживать через встроенную stats-панель (требует отдельной настройки) или командой haproxy -c -f /etc/haproxy/haproxy.cfg, которая валидирует конфигурацию и показывает состояние бэкендов.

Больше готовых конфигураций для различных протоколов, включая MySQL и DNS, вы найдете в нашем руководстве HAProxy для маршрутизации TCP и UDP трафика.

Продвинутые сценарии: SSL-оффлоадинг и контроль доступа (ACL)

HAProxy может терминалировать SSL/TLS соединения даже для не-HTTP протоколов. Это полезно для безопасного доступа к базе данных из публичной сети. Конфигурация предполагает загрузку SSL-сертификата:

frontend secure_pg_frontend
    bind *:5433 ssl crt /etc/ssl/private/pg.pem
    mode tcp
    default_backend pg_backend

Здесь клиенты подключаются по TLS на порт 5433. HAProxy расшифровывает трафик и перенаправляет его в незашифрованном виде на бэкенды в доверенной сети. Файл pg.pem должен содержать приватный ключ и сертификат.

Access Control Lists (ACL) позволяют фильтровать входящие соединения. Пример ниже разрешает подключение к порту PostgreSQL только из определенной подсети:

Реклама

frontend pg_frontend_acl
    bind *:5432
    mode tcp
    tcp-request connection reject if !{ src -f /etc/haproxy/trusted_ips.lst }
    default_backend pg_backend

Файл trusted_ips.lst содержит список разрешенных IP-адресов или сетей в формате CIDR. Соединения с других адресов будут немедленно разорваны.

Современная альтернатива: мощь модуля ngx_stream_core_module в Nginx

Модуль Stream добавляет в Nginx функциональность L4-балансировки. В большинстве дистрибутивов он скомпилирован по умолчанию. Если нет, требуется пересборка Nginx с флагом --with-stream.

Конфигурация строится вокруг блока stream, который находится на одном уровне с блоком http. Внутри него используются знакомые по HTTP-балансировке директивы upstream и server. Пример балансировки SSH-трафика:

stream {
    upstream ssh_backend {
        server 192.168.1.11:22;
        server 192.168.1.12:22;
        server 192.168.1.13:22;
    }

    server {
        listen 2222;
        proxy_pass ssh_backend;
        proxy_timeout 1h;
        proxy_connect_timeout 10s;
    }
}

Внешние клиенты подключаются к порту 2222 на Nginx, который прозрачно передает TCP-поток на один из трех бэкендов на порту 22. Директива proxy_timeout задает максимальное время бездействия соединения, после которого оно будет закрыто. Для SSH это значение должно быть большим.

Балансировка UDP-трафика: кейс с DNS-серверами

Для работы с UDP в блоке server добавляется директива udp. Важно корректно настроить таймауты, так как UDP - протокол без установления соединения.

stream {
    upstream dns_servers {
        server 192.168.2.10:53;
        server 192.168.2.11:53;
    }

    server {
        listen 53 udp reuseport;
        proxy_pass dns_servers;
        proxy_timeout 3s;
    }
}

Параметр reuseport позволяет создать несколько сокетов для обработки входящих пакетов, что повышает производительность на многопроцессорных системах. Таймаут proxy_timeout для UDP определяет, как долго Nginx будет ждать ответа от бэкенда, прежде чем считать операцию завершенной.

В сравнении с HAProxy, который получил полноценную поддержку UDP в версии 2.0, Nginx Stream предлагает более простой и лаконичный синтаксис для таких конфигураций.

Интеграция с экосистемой Nginx: логи, мониторинг и переменные

Модуль Stream поддерживает форматирование логов с помощью директивы log_format внутри блока stream. Можно использовать специальные переменные:

stream {
    log_format basic '$remote_addr [$time_local] $protocol '
                     '$status $bytes_sent $bytes_received '
                     '$upstream_addr $upstream_connect_time';

    access_log /var/log/nginx/stream-access.log basic;
}

Переменная $protocol будет содержать "TCP" или "UDP", $upstream_addr - IP и порт выбранного бэкенда. Это упрощает отладку.

Для мониторинга можно использовать встроенный модуль stub_status, настроенный в блоке server внутри stream, или специализированные экспортеры для Prometheus вроде nginx-vts-exporter, если Nginx собран с модулем nginx-module-vts.

Проверить корректность конфигурации можно стандартной командой nginx -t. Она работает и для конфигов внутри блока stream. Активные соединения можно посмотреть, например, с помощью ss -tpn | grep nginx.

Оптимизация под конкретные сервисы: PostgreSQL, MySQL и не только

Балансировка трафика СУБД имеет специфику. Для транзакционных workload важно persistence - закрепление соединения от одного клиента за одним бэкендом на время жизни сессии. Иначе транзакция, начатая на одном сервере, может продолжиться на другом, что приведет к ошибке.

Решение в HAProxy: использовать алгоритм балансировки balance source. Он хэширует IP-адрес источника и всегда направляет соединения с этого адреса на один и тот же бэкенд (при неизменном составе пула серверов).

backend db_backend
    mode tcp
    balance source
    server db1 10.0.1.1:3306 check
    server db2 10.0.1.2:3306 check

Решение в Nginx Stream: использовать директиву hash в блоке upstream.

upstream mysql_backend {
    hash $remote_addr consistent;
    server 10.0.1.1:3306;
    server 10.0.1.2:3306;
}

Параметр consistent улучшает алгоритм, минимизируя перераспределение хэшей при добавлении или удалении сервера из пула.

Таймауты должны соответствовать поведению БД. Для PostgreSQL с долгими аналитическими запросами устанавливайте timeout server в HAProxy или proxy_timeout в Nginx на несколько часов. Для протокола PostgreSQL важно, чтобы балансировщик корректно обрабатывал startup-пакет, но и HAProxy, и Nginx Stream справляются с этим прозрачно.

Реклама

Краткие выжимки конфигураций:

• MySQL (порт 3306): Используйте persistence (source/hash). Настройте health check, который отправляет SELECT 1 для проверки не только доступности порта, но и работоспособности самого mysqld.
• PostgreSQL (порт 5432): Аналогично MySQL, но health check может быть проще - успешное TCP-подключение часто достаточно. Для определения мастера в репликационном кластере потребуется внешний скрипт, меняющий вес бэкендов.

Сборка отказоустойчивой архитектуры: от конфигов до мониторинга

Один балансировщик - это единая точка отказа. Для production-среды нужна отказоустойчивая пара. Распространенный паттерн - активный-пассивный кластер с использованием keepalived и VRRP. Один балансировщик получает виртуальный IP-адрес (VIP), второй находится в горячем резерве и подхватывает VIP при сбое первого.

Альтернатива - активный-активный схема с DNS-балансировкой, где на оба балансировщика указывает запись A с round-robin. Это сложнее в управлении состоянием сессий, но дает лучшую утилизацию ресурсов.

Мониторинг должен охватывать три уровня:

1. Сам балансировщик: загрузка CPU, память, количество открытых сокетов (метрика curr_conn в HAProxy stats).
2. Состояние бэкендов: процент доступных серверов в пуле, история переключений статусов.
3. Сквозная доступность сервиса: периодические тестовые подключения с клиентских машин к виртуальному IP и порту.

Перед выкатом в production выполните чек-лист:

• Проверьте конфигурацию на синтаксические ошибки (haproxy -c, nginx -t).
• Протестируйте отказоустойчивость: поочередно останавливайте бэкенды и наблюдайте, как балансировщик исключает их из пула.
• Сымитируйте сбой самого балансировщика (в паре активный-пассивный) и убедитесь, что VIP мигрирует на резервный узел.
• Проверьте работу SSL-оффлоадинга, если он настроен, с помощью openssl s_client.
• Убедитесь, что логи пишутся в ожидаемом формате и содержат достаточно информации для отладки.

Итоговые рекомендации на 2026 год:

• Выбирайте HAProxy для сложных кластеров баз данных, где необходимы продвинутые health checks и ACL, а также для высоконагруженных B2B-систем. Изучите практическое руководство по настройке маршрутизации и балансировки в HAProxy.
• Используйте Nginx Stream, если ваша команда уже глубоко знает Nginx, требуется быстрая интеграция с существующей инфраструктурой мониторинга или основная задача - балансировка UDP-трафика с минимальными настройками.
• Независимо от выбора, тестируйте конфигурацию в staging-среде, максимально приближенной к production. Сверяйте версии ПО (HAProxy 2.8+, Nginx 1.25+ с модулем Stream) с используемыми в статье директивами.

Для принятия окончательного решения о выборе технологии в вашем стеке ознакомьтесь со сравнительным анализом в статье Балансировка нагрузки в 2026: Nginx, HAProxy и Keepalived. А чтобы глубже понять логику работы разных алгоритмов распределения трафика, изучите материал Алгоритмы балансировки нагрузки 2026.

Если в процессе настройки инфраструктуры вам потребуется интегрировать сервисы ИИ, например для анализа логов или мониторинга, рассмотрите использование агрегатора API AiTunnel. Он предоставляет единый интерфейс для доступа к более чем 200 моделям нейросетей, включая GPT, Gemini и Claude, с оплатой в рублях и без необходимости использовать VPN.

Реклама