HAProxy 3.4 вышел 3 июня 2026 года как LTS-релиз популярного балансировщика нагрузки и reverse proxy. Главная ценность версии — динамическое управление backend-разделами через Runtime API, улучшенная наблюдаемость через OpenTelemetry и доработки производительности на серверах с большим числом ядер.
HAProxy 3.4 переводит часть управления трафиком в Runtime API
HAProxy используют там, где нужно распределять входящие запросы между несколькими серверами, защищать приложения от перегрузки, завершать TLS-соединения и маршрутизировать HTTP/TCP-трафик. Для читателя без DevOps-бэкграунда HAProxy можно представить как диспетчера на входе в приложение: он принимает запрос, выбирает подходящий сервер и следит, чтобы сбой одного узла не остановил весь сервис.
В релизе HAProxy 3.4 разработчики сделали акцент на инфраструктурах, где состав сервисов часто меняется: контейнеры пересоздаются, новые версии выкатываются постепенно, часть backend-узлов появляется и исчезает автоматически. В таких условиях каждое изменение конфигурации через полный reload становится лишней операционной нагрузкой.
HAProxy 3.4 позволяет создавать, наполнять серверами, публиковать и удалять backend-разделы через Runtime API. Это значит, что управляющий слой или оркестратор может добавлять новые направления маршрутизации без полной перезагрузки процесса HAProxy.
Это особенно полезно для платформенных команд, которые обслуживают много внутренних сервисов. Например, новая версия приложения может получить собственный backend, пройти проверку, попасть в маршрутизацию и затем быть удалена после завершения тестового окна. Раньше подобный сценарий чаще требовал заранее подготовленных конфигурационных блоков или аккуратной перезагрузки.
Динамические backend-разделы упрощают выкатывание сервисов
Backend в HAProxy — это группа серверов, куда отправляются запросы после обработки на frontend-стороне. Если frontend отвечает за входящий трафик и правила маршрутизации, backend описывает конечные узлы приложения: адреса, порты, проверки доступности, алгоритм балансировки.
HAProxy 3.4 добавляет команды Runtime API для работы с backend-разделами в живом процессе. Такой подход хорошо ложится на современные схемы доставки: blue-green deployment, canary-релизы, временные окружения для тестирования, автоматическое подключение новых сервисов.
Смысл изменения проще всего понять через жизненный цикл:
| Сценарий | Прежний подход | Практический эффект HAProxy 3.4 |
| Появился новый сервис | Подготовка конфигурации и reload | Backend можно создать во время работы HAProxy |
| Нужно добавить серверы в маршрут | Изменение файла конфигурации или заранее созданного блока | Серверы добавляются через Runtime API |
| Тестовый backend больше не нужен | Ручная чистка конфигурации и reload | Backend можно удалить из работающего процесса |
| Оркестратор управляет маршрутами | Нужны внешние шаблоны и синхронизация конфигов | Управление ближе к модели control plane |
Это изменение не отменяет обычные конфигурационные файлы. Базовая схема HAProxy остаётся привычной: администратор задаёт глобальные параметры, frontend-разделы, правила маршрутизации и постоянные backend-группы. Новая возможность расширяет сценарии, где часть инфраструктуры должна жить динамически.
HAProxy 3.4 снижает расходы памяти на сложных HTTP-сценариях
В HAProxy 3.4 переработана работа с буферами. Буфер — область памяти, через которую прокси обрабатывает данные запроса и ответа. В простых сценариях буферы остаются небольшими, а при проверке тела запроса или других тяжёлых операциях может понадобиться больше памяти.
Раньше администраторам нередко приходилось увеличивать общий параметр tune.bufsize, если отдельные рабочие сценарии требовали больших буферов. Такой способ решал проблему для конкретной нагрузки, но мог раздувать потребление памяти для всех соединений.
В версии 3.4 крупные буферы могут выделяться по требованию для задач, связанных с inspection-нагрузкой. Для ожидающих и повторяемых запросов HAProxy также может использовать более компактные буферы. Практический смысл простой: прокси лучше подстраивается под реальную нагрузку, а не заставляет всю систему жить по параметрам самого тяжёлого сценария.
Разработчики также заявили прирост request rate до 20% на системах с большим числом CPU-ядер. В релизе появились более тонкие настройки CPU affinity: HAProxy может точнее распределять рабочие потоки по процессорной топологии. Для небольшого VPS разница может быть незаметной, а для крупных edge-узлов и API-шлюзов это даёт больше запаса при пиковом трафике.
OpenTelemetry заменяет устаревающий OpenTracing
Наблюдаемость в HAProxy 3.4 стала ближе к современным стековым инструментам. Релиз добавил поддержку OpenTelemetry в виде add-on и одновременно перевёл OpenTracing в статус deprecated. По опубликованным release notes, OpenTracing планируют полностью убрать в HAProxy 3.5.
OpenTelemetry нужен для распределённой трассировки: он помогает увидеть путь запроса через несколько сервисов, прокси, баз данных и очередей. Для бизнеса это превращается в более понятную диагностику: команда быстрее видит, где именно растёт задержка — на входном прокси, в API, в сервисе авторизации или в базе данных.
Для HAProxy это особенно полезно в роли входной точки. Если балансировщик уже участвует в трассировке, инженеры получают полный контекст запроса с самого края инфраструктуры. При расследовании медленных ответов это экономит время: исчезает слепая зона между клиентом и первым приложением.
Переход с OpenTracing на OpenTelemetry стоит учитывать заранее. Командам, которые уже собирают трассы через OpenTracing, понадобится проверить совместимость пайплайна, агента, collector-компонентов и формата метаданных до перехода на будущую ветку HAProxy 3.5.
TLS, ACME и криптография стали удобнее для API-шлюзов
HAProxy давно используют как точку завершения TLS: клиент подключается по HTTPS, а HAProxy принимает сертификат, расшифровывает трафик и передаёт запрос дальше по внутренним правилам. В версии 3.4 этот слой получил несколько заметных доработок.
В релизе улучшены ACME-возможности, связанные с автоматической выдачей и управлением сертификатами. Среди изменений — поддержка IP-адресов в Subject Alternative Name для ACME-сертификатов и поддержка External Account Binding. Для инфраструктур с большим числом доменов это уменьшает ручную работу вокруг сертификатов и делает управление HTTPS более предсказуемым.
Появилась поддержка TLS certificate compression по RFC 8879. Сжатие сертификата уменьшает объём данных, которые передаются во время TLS-рукопожатия. На практике выигрыш зависит от сети, размера цепочки сертификатов и поведения клиентов, но для задержек на краю сети даже небольшая экономия байтов бывает заметной.
Отдельное направление — криптографические операции на уровне прокси. HAProxy 3.4 добавляет встроенные возможности для JWT decryption и AES encryption/decryption. Это полезно для API-шлюзов, где часть проверок и преобразований токенов удобнее выполнять до передачи запроса во внутренний сервис.
Проверки доступности и обработка ошибок стали гибче
HAProxy 3.4 расширил детектор «glitches» на HTTP/1. Под этим термином разработчики понимают необычные HTTP-сообщения, которые могут быть следствием ошибки клиента, нестандартного поведения сервера или попытки атаки на протокол. Ранее такая логика охватывала HTTP/2 и QUIC, теперь она работает и для HTTP/1.
Если соединение набирает слишком много подобных событий, HAProxy может закрыть его более аккуратно: релиз описывает попытку graceful close при достижении 75% заданного порога. Для администраторов это даёт дополнительный инструмент против шумного или подозрительного трафика без резкого обрыва в каждой ситуации.
Также появился новый раздел healthcheck, который позволяет описывать переиспользуемые проверки доступности. Это полезно, когда несколько backend-групп используют одинаковую или похожую схему проверки: HTTP-запрос к /health, TCP-проверку, Redis-check, SMTP-check и другие варианты.
Для крупных конфигураций это снижает дублирование. Проверка описывается один раз, затем назначается нужным серверам. Такой подход облегчает ревизию конфигурации: проще понять, какие сервисы проверяются одинаково, а где правила отличаются намеренно.
Итог
Релиз 3.4 относится к ветке LTS и доступен в официальном каталоге исходников HAProxy. При этом на странице загрузки уже присутствуют патч-релизы ветки 3.4, включая HAProxy 3.4.2 от 3 июля 2026 года. Для рабочего обновления обычно разумнее смотреть на актуальный патч-релиз выбранной ветки, а не фиксироваться на первом выпуске 3.4.0.
Перед переходом стоит проверить несколько зон риска:
- используются ли OpenTracing-интеграции, которые придётся переводить на OpenTelemetry;
- есть ли кастомные настройки Stats page, поскольку отображение версии теперь требует
stats show-version; - завязаны ли внутренние инструменты на старое поведение буферов, логов или health-check-конфигураций;
- поддерживают ли текущие пакеты дистрибутива нужную ветку HAProxy или потребуется официальный репозиторий/сборка из исходников.
Основная цель обновления HAProxy до версии 3.4 для большинства администраторов заключается в упрощении управления в условиях динамичной инфраструктуры. Эта версия особенно полезна в ситуациях, когда HAProxy используется не как простой статический балансировщик между двумя серверами, а как ключевой компонент платформы. В таких условиях маршруты могут часто изменяться, трафик увеличивается, требуется сквозная трассировка, а перезагрузка процесса становится критическим риском.
