Live-данные · обновлено 20 июля 2026 г.

HAProxy

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

КВКузнецов Вячеслав·Технический редактор·DevOps/SRE-техлид · опыт 10+ лет
Вакансий
65
активных в Москве
Медиана зарплаты
Индекс спроса
47/100
#172 из 327 навыков
Доля IT-рынка
0.9%
9 профессий

Коротко о навыке

HAProxy — балансировщик нагрузки и обратный прокси, который стоит перед группой серверов и распределяет между ними входящий трафик. Он умеет работать на двух уровнях: на транспортном (L4, режим TCP) — просто раскидывает соединения, не заглядывая внутрь, и на прикладном (L7, режим HTTP) — разбирает запрос, читает заголовки, URL и cookie и принимает решения на их основе. За счёт событийной однопроцессной архитектуры HAProxy держит десятки тысяч одновременных соединений на скромном железе, поэтому его ставят там, где нельзя терять ни производительность, ни отказоустойчивость.

Смысл HAProxy не в том, чтобы «раздать запросы по серверам», а в том, чтобы построить точку входа, которая переживёт падение отдельных бэкендов. Health checks постоянно проверяют, живы ли серверы, и мёртвые автоматически выводятся из ротации; ACL-правила маршрутизируют трафик по содержимому запроса; терминация TLS снимает шифрование с плеч приложения; sticky sessions привязывают пользователя к одному бэкенду. Всё это описывается в одном текстовом конфиге haproxy.cfg, а сам HAProxy почти всегда работает в паре с keepalived, чтобы не быть единственной точкой отказа.

Для этого навыка доступны ограниченные данные (менее 50 вакансий или нет зарплатных данных). Аналитика носит ориентировочный характер.

Что такое HAProxy

Что это

Балансировщик нагрузки и обратный прокси для TCP и HTTP: принимает трафик на frontend, распределяет по бэкенд-серверам, проверяет их здоровье и терминирует TLS.

Кто использует

В первую очередь DevOps-инженеры, также системные администраторы и SRE: те, кто отвечает за доступность и отказоустойчивость инфраструктуры.

Позиция на рынке

Устойчивый инфраструктурный навык из мира высокой доступности. Спрашивают не отдельно, а в связке с Nginx, keepalived, Docker и системами мониторинга.

Что такое HAProxy

HAProxy (High Availability Proxy) — это прослойка между клиентами и группой серверов, которая принимает все входящие соединения на себя и решает, какому из бэкендов их передать. Клиент видит один адрес и один порт, а за ними скрывается пул из нескольких серверов, которые можно добавлять, выводить на обслуживание и терять без простоя для пользователя. HAProxy написан на C, работает как один процесс с событийным циклом и славится тем, что стабильно держит очень высокую нагрузку при низком потреблении ресурсов — именно поэтому он десятилетиями стоит на входе крупных высоконагруженных площадок.

Frontend и backend: из чего собран конфиг

Конфигурация HAProxy строится вокруг двух секций. Frontend описывает, что слушать: адрес, порт, протокол, правила приёма трафика и логику маршрутизации. Backend описывает, куда направлять: список серверов (директивы server), алгоритм балансировки и параметры проверки здоровья. Между ними связка через use_backend и default_backend. Одному frontend может соответствовать несколько backend — например, запросы к /api уходят на одну группу серверов, а всё остальное на другую. Весь этот набор живёт в haproxy.cfg, и по нему одному можно прочитать всю схему движения трафика.

L4 и L7: два уровня балансировки

Ключевое различие, которое надо понимать, — на каком уровне HAProxy работает. В режиме TCP (L4, транспортный уровень) он балансирует соединения вслепую: видит только адреса и порты, не разбирая содержимое. Это быстро и подходит для любого протокола — баз данных, очередей, чистого TCP. В режиме HTTP (L7, прикладной уровень) HAProxy разбирает каждый запрос: читает метод, путь, заголовки и cookie, может маршрутизировать по URL, переписывать заголовки, терминировать TLS и вести детальный лог. Плата за это — чуть больше работы на запрос. Выбор режима определяет, что вообще HAProxy сможет делать с трафиком.

Понятия / Карта

Из чего состоит HAProxy

Понятие Что это Что нужно уметь
Frontend / backend
Frontend — что слушать, backend — куда направлять трафик.
Разбивать трафик по секциям, связывать их через use_backend и default_backend.
Алгоритмы балансировки
Правило, по которому запросы делятся между серверами.
Выбирать между roundrobin и leastconn под характер нагрузки, управлять весами серверов.
Health checks
Проверки, жив ли сервер, чтобы не слать на него трафик.
Настраивать option httpchk с реальным путём и порогами fall/rise, а не пустой TCP-коннект.
ACL
Условие по параметрам запроса — путь, заголовок, адрес.
Писать ACL и маршрутизировать по ним трафик в разные backend на L7.
Терминация TLS
HAProxy снимает шифрование на входе вместо приложения.
Настраивать bind ssl с сертификатом, редирект на HTTPS, работу с бэкендами по HTTP.
Sticky sessions
Привязка пользователя к одному серверу на сессию.
Настраивать привязку через cookie или stick table и понимать, где она оправдана.
Механика / Работа

Как HAProxy распределяет трафик

Путь запроса от клиента до живого бэкенда — через проверки и правила.

Шаг 01

Приём на frontend

HAProxy принимает соединение на заданном адресе и порту, при необходимости терминирует TLS и, если работает на L7, разбирает HTTP-запрос — метод, путь, заголовки, cookie.

Шаг 02

Решение по ACL и здоровью

По ACL HAProxy выбирает нужный backend, а внутри него берёт сервер по алгоритму балансировки — но только из тех, что прошли health-проверку. Мёртвые узлы в расчёт не идут.

Шаг 03

Передача на бэкенд

Запрос уходит выбранному серверу, при sticky sessions клиент закрепляется за ним на сессию. Ответ возвращается через HAProxy, а статистика и логи фиксируют, что произошло.

Карьера / Роли

Кому нужен HAProxy

HAProxy переносится между ролями: DevOps-инженер, Системный администратор, SRE-инженер. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.

Роли с HAProxy за период

DevOps-инженер — самый заметный профиль в распределении ролей по навыку.

Ещё 1 ролей используют HAProxy

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

Практика / Задачи

Частые задачи с HAProxy

HAProxy ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами — ниже они разобраны так, как встречаются в реальной работе.

Задача 01

Базовый frontend и backend

Минимальная конфигурация: слушаем 80-й порт и раскидываем запросы по двум веб-серверам по кругу.

frontend web_in
    bind *:80
    mode http
    default_backend web_servers

backend web_servers
    mode http
    balance roundrobin
    server web1 10.0.0.11:80 check
    server web2 10.0.0.12:80 check
Задача 02

Health checks: вывод мёртвых из ротации

HTTP-проверка на заданный путь: сервер, не отдающий 200 на /health, автоматически исключается из балансировки.

backend api_servers
    mode http
    balance leastconn
    option httpchk GET /health
    http-check expect status 200
    default-server inter 3s fall 3 rise 2
    server api1 10.0.0.21:8080 check
    server api2 10.0.0.22:8080 check
Задача 03

ACL: маршрутизация по URL

Запросы к /api уходят одной группе серверов, всё остальное — другой. Решение принимается по пути запроса на L7.

frontend web_in
    bind *:80
    mode http
    acl is_api path_beg /api
    use_backend api_servers if is_api
    default_backend web_servers

backend api_servers
    server api1 10.0.0.21:8080 check

backend web_servers
    server web1 10.0.0.11:80 check
Задача 04

Терминация TLS на frontend

HAProxy снимает шифрование на входе, а к бэкендам ходит по HTTP — приложению не нужно возиться с сертификатами.

frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/site.pem
    mode http
    http-request redirect scheme https unless { ssl_fc }
    default_backend web_servers

backend web_servers
    mode http
    server web1 10.0.0.11:80 check
    server web2 10.0.0.12:80 check
Задача 05

Sticky sessions через cookie

Пользователь закрепляется за одним бэкендом на время сессии — нужно приложениям, хранящим состояние в памяти узла.

backend app_servers
    mode http
    balance roundrobin
    cookie SRVID insert indirect nocache
    server app1 10.0.0.31:8080 check cookie app1
    server app2 10.0.0.32:8080 check cookie app2
Задача 06

L4: балансировка чистого TCP

В режиме TCP HAProxy распределяет соединения к репликам базы, не разбирая содержимое — годится для любого протокола.

frontend pg_in
    bind *:5432
    mode tcp
    default_backend pg_replicas

backend pg_replicas
    mode tcp
    balance leastconn
    option tcp-check
    server pg1 10.0.0.41:5432 check
    server pg2 10.0.0.42:5432 check
Практика / Ошибки

Ошибки новичков

Ошибка 01

Балансировать, не проверяя здоровье

Настроить распределение и забыть про health checks — значит слать трафик на упавший сервер и отдавать пользователям ошибки. Без осмысленных проверок (не просто TCP-коннект, а реальный HTTP-запрос на рабочий путь) балансировщик теряет главный смысл — отказоустойчивость.

Ошибка 02

Сам HAProxy как единственная точка отказа

Один узел HAProxy перед пулом серверов защищает бэкенды, но сам становится местом, падение которого кладёт всё. Продовая схема — минимум пара с keepalived и общим виртуальным адресом; без этого высокая доступность существует только на бумаге.

Ошибка 03

Путать L4 и L7

Пытаться маршрутизировать по URL или читать заголовки в режиме TCP — не сработает: на L4 HAProxy не видит содержимого запроса. И наоборот, гнать через L7 протокол, которому разбор HTTP не нужен, — лишняя работа. Выбор режима надо делать осознанно под задачу.

Ошибка 04

Ставить sticky sessions по привычке

Включать привязку к серверу везде «на всякий случай» — ломать равномерность балансировки и живучесть: при падении узла его пользователи теряют сессии. Sticky sessions нужны только приложениям с состоянием в памяти; правильнее делать приложение stateless.

Ошибка 05

Слепо копировать чужой конфиг

Взять готовый haproxy.cfg из интернета и запустить, не понимая директив, — почти гарантированно получить неверные таймауты, бесполезные проверки или дыру в TLS. Конфиг HAProxy читается как схема трафика; каждую строку нужно понимать, а не заклинать.

Рынок / Контекст

HAProxy в современных IT-проектах: контекст спроса

HAProxy появляется в вакансиях там, где перед группой серверов нужна надёжная точка входа: балансировка нагрузки в режимах L4 и L7, обратный прокси с маршрутизацией по заголовкам и URL, терминация TLS на входе и разгрузка бэкендов под high-load. Настраивают его чаще всего DevOps-инженеры и SRE, реже — системные администраторы, которые отвечают за отказоустойчивость сервиса. В требованиях он почти всегда идёт в связке: рядом nginx как второй прокси, keepalived для плавающего адреса и пары без единой точки отказа, health checks для автоматического вывода упавших серверов, а в кластерных сценариях — балансировка трафика к сервисам в k8s. Работодателю важно, что кандидат умеет описать backend, frontend и правила в haproxy.cfg и объяснить, чем TCP-режим отличается от разбора HTTP-запроса. К HAProxy обычно приходят уже с опытом веб-серверов и обратных прокси, когда встаёт задача масштабирования и непрерывной доступности.

Сокращает ручную работу

HAProxy востребован там, где инструмент реально ускоряет повторяемые задачи команды, а не существует отдельной теорией.

Встроен в рабочий процесс

Спрос держится дольше, когда навык нужен не эпизодически, а как часть ежедневного цикла разработки, проверки или доставки.

Закреплён в зрелом стеке

HAProxy чаще ищут там, где процесс уже стандартизирован и без этого инструмента команда теряет скорость и предсказуемость.

Сигнал рынка
Стабильный спрос

HAProxy формирует устойчивый спрос внутри своего рабочего сегмента.

Рынок / Спрос

Спрос на HAProxy на рынке

HAProxy сохраняет устойчивый прикладной спрос на рынке: 65 активных вакансий, #172 по рынку, 0.9% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.

Сила спроса
Стабильный спрос
65
активных вакансий сейчас

#172 по рынку • 0.9% IT-вакансий

Месяц к месяцу
87
июль 2026 — предварительный накопительный срез

-13 вакансий и -13% к предыдущему месяцу.

Связи / Навыки

Навыки в связке с HAProxy

HAProxy редко живёт изолированно: чаще всего рынок видит его рядом с Linux, Nginx, Ansible. Самая плотная связка сейчас - Linux: оба навыка встречаются вместе в 85% вакансий.

Главная связка: Linux • 85% вакансий. Показываем общерыночные связки HAProxy: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.

Рабочий стек вокруг HAProxy

навыки, которые рынок чаще всего видит рядом в одной вакансии

Навык Зачем рядом Доля
Одна из самых плотных рыночных связок рядом с HAProxy.
85%
Часто встречается рядом с HAProxy в одном рабочем сценарии.
80%
Часто встречается рядом с HAProxy в одном рабочем сценарии.
78%
Поддерживает соседние процессы и усиливает рабочий контур навыка.
71%
Поддерживает соседние процессы и усиливает рабочий контур навыка.
71%
Поддерживает соседние процессы и усиливает рабочий контур навыка.
69%
Вход / Старт

Порог входа

Рынок редко нанимает только под один навык: ниже показываем, какой стек обычно ждут рядом с HAProxy на старте.

Что нужно на старте

Стартовый стек

26.5
навыков в медианной вакансии

Медианная вакансия с HAProxy ожидает около 26.5 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.

Карьера / Резюме

HAProxy в резюме: что значит "знаю HAProxy"

В резюме владение HAProxy показывает, что вы понимаете, как строить отказоустойчивую инфраструктуру. Ниже — что означает навык на разных уровнях и что указать.

Уровень Что значит Что показать
Beginner
Установил HAProxy, написал простой конфиг с одним frontend/backend.
Настройка базовой балансировки для двух веб-серверов
Junior developer
Использовал HAProxy для терминирования SSL и маршрутизации по URL.
Конфигурация frontend/backend, health checks, stats page
Middle developer
Писал ACL, настраивал stick tables, рандом/leastconn, мониторинг.
Canary deployment через веса, keepalived для отказоустойчивости
QA automation
Использовал HAProxy для переключения между окружениями, снятия метрик.
Изменение backend на лету через stats socket, нагрузочное тестирование
Data/ML
Настраивал проксирование для API и WebSocket в ML-сервисах.
Балансировка gRPC/HTTP2, ACL для микросервисов
DevOps junior
Развернул HAProxy в Docker, настроил базовые health checks и мониторинг.
Docker Compose с HAProxy, интеграция с Prometheus
SRE/platform
Проектировал отказоустойчивую пару HAProxy + keepalived, автоматизировал конфиг.
Ansible-роль для HAProxy, мониторинг и алертинг, canary/blue-green
Сравнение / Инструменты

HAProxy в инфраструктурном стеке

С чем HAProxy работает в реальных проектах.

Инструмент За что отвечает Когда нужен Граница

keepalived

Отказоустойчивость самого HAProxy

Нужна точка входа без единой точки отказа

Даёт только переключение адреса, но не балансировку сам по себе.

Nginx

Веб-сервер и раздача контента

Нужны статика, кэш и динамика на том же фронте

Балансировка у Nginx беднее по алгоритмам и TCP-режиму.

Docker

Упаковка и запуск HAProxy

Разворачиваете балансировщик в контейнерной среде

Один контейнер без оркестрации не даёт отказоустойчивости.

Ansible

Автоматизация конфигурации

Конфиг нужно тиражировать и держать как код

Не управляет трафиком в рантайме — только раскатывает конфиг.

Prometheus

Сбор метрик и наблюдаемость

Нужен мониторинг состояния бэкендов и задержек

Только наблюдает — на само распределение трафика не влияет.

Навык / Применение

Где используется HAProxy

HAProxy ставят везде, где нужна отказоустойчивая точка входа: от одного пула веб-серверов до отказоустойчивых пар и балансировки баз данных.

Сценарий 01

Точка входа веб-сервиса

HAProxy стоит перед пулом веб- или API-серверов, распределяет запросы, снимает упавшие узлы с ротации и терминирует TLS. Классическая роль на входе...

Сценарий 02

Балансировка баз данных и очередей

В режиме TCP HAProxy балансирует соединения к репликам PostgreSQL, кластерам Galera, брокерам очередей. Умные health-проверки отправляют трафик только на живой...

Сценарий 03

Отказоустойчивая пара с keepalived

Два узла HAProxy делят виртуальный адрес по VRRP: активный обслуживает трафик, резервный подхватывает при падении. Так убирают единственную точку отказа на самом...

Сценарий 04

Маршрутизация микросервисов

По ACL на путь и заголовки HAProxy раскидывает запросы разным группам сервисов, поддерживает HTTP/2 и gRPC, разделяет публичный и внутренний трафик на одной точке...

По направлениям

HAProxy заметен в 1 направлениях рынка с долей выше 5%.

Направление Контекст Доля
Инфраструктура
Замена аппаратных балансировщиков, отказоустойчивая пара с keepalived.
91.8%
Менеджмент
Мониторинг через stats page, интеграция с Prometheus/Grafana.
3.3%
Безопасность
Часть спроса по навыку сосредоточена в этом направлении.
2.5%
Аналитика
Часть спроса по навыку сосредоточена в этом направлении.
2.5%
Направления показывают, в каких частях IT-рынка навык заметен чаще всего, без разбивки по ролям.
Инструмент / Возможности

Что умеет HAProxy

Возможности, за которые его ставят на входе высоконагруженных систем.

Балансировка L4 и L7

Работает и с чистым TCP для любых протоколов, и с HTTP для маршрутизации по содержимому запроса — один инструмент на оба уровня.

Автоматический вывод мёртвых узлов

Health checks постоянно опрашивают серверы и убирают из ротации те, что перестали отвечать, возвращая их при восстановлении.

Терминация TLS и маршрутизация

Снимает шифрование на входе, редиректит на HTTPS и разводит трафик по backend через ACL на путь, заголовки и адрес.

Наблюдаемость из коробки

Встроенная страница статистики и метрики показывают состояние бэкендов, задержки и коды ответов в реальном времени.

Сравнение / Контекст

HAProxy, Nginx и облачный балансировщик

Три способа закрыть балансировку — у каждого своя зона.

HAProxy vs Nginx

Nginx — прежде всего веб-сервер: раздаёт статику, кэширует, обслуживает динамику, а балансировка у него одна из функций. HAProxy заточен только под балансировку и проксирование и делает это тоньше —...

HAProxy vs облачный балансировщик

Управляемый балансировщик облачного провайдера сам масштабируется и не требует своей отказоустойчивой пары — его просто включают и не обслуживают. HAProxy даёт полный контроль над логикой,...

HAProxy vs Ingress в Kubernetes

В кластерах Kubernetes балансировку на входе закрывает Ingress-контроллер, работающий с динамическим набором подов, — и HAProxy как раз может быть таким контроллером. Разница не в идеях, а в среде:...

Практика / Workflow

Как HAProxy используется в реальном проекте

Этап Что происходит Артефакт
1 Проектирование трафика
Какие frontend, какие backend, как маршрутизировать
Схема движения трафика
2 Написание конфига
haproxy.cfg: секции, серверы, ACL, таймауты
Готовый haproxy.cfg
3 Проверки здоровья
option httpchk, пороги fall/rise, алгоритм балансировки
Автовывод мёртвых узлов
4 TLS и безопасность
Терминация TLS, редиректы, ограничения по ACL
Защищённая точка входа
5 Отказоустойчивость
Пара с keepalived, виртуальный адрес по VRRP
Схема без единой точки отказа
6 Наблюдаемость
Страница статистики, метрики в Prometheus, алерты
Мониторинг балансировщика
Инструмент / Оркестрация

HAProxy: запуск и базовая структура конфигурации

HAProxy — это демон, который читает конфигурационный файл (обычно /etc/haproxy/haproxy.cfg). Рассмотрим минимальный запуск и структуру.

Установка и запуск

apt install haproxy для Ubuntu/Debian, yum install haproxy для CentOS/RHEL. Запуск: systemctl start haproxy.

Секция global

Глобальные настройки процесса: maxconn, daemon, pidfile, параметры SSL.

Секция defaults

Значения по умолчанию для всех последующих фронтендов и бэкендов: mode, timeout connect/client/server.

Секция frontend

Слушает порт, принимает соединения. Определяет bind и default_backend.

Секция backend

Определяет список серверов, алгоритм балансировки и health checks.

Секция listen

Совмещает frontend и backend для простых случаев.

Пример: балансировка двух веб-серверов

Полный конфиг с global, defaults, frontend www, backend web_servers с health check каждые 3с.

Reload без разрыва соединений

systemctl reload haproxy или SIGHUP — перечитывает конфиг без обрыва текущих соединений.

Практика / HAProxy

HAProxy: лучшие практики и типичные ошибки новичков

Практика 01

Используйте health checks

Без check в строке сервера HAProxy не будет знать, жив ли бэкенд. Обязательно настройте option httpchk или tcpchk.

Практика 02

Разделяйте frontend и backend

Даже для простого сценария пишите отдельно frontend и backend — это облегчает будущее расширение.

Практика 03

Настройте таймауты разумно

Для API обычно 5-30с, для веб-сокетов — 3600с. Используйте timeout connect, timeout server, timeout client.

Практика 04

Используйте ACL для тонкой маршрутизации

ACL позволяют направлять трафик в зависимости от заголовков, пути, метода. Избегайте одного backend для всего.

Практика 05

Включайте статистику, но защищайте её

Stats page — мощный инструмент мониторинга, но без пароля её оставлять нельзя. Используйте stats auth.

Практика 06

Мониторьте через Prometheus

Современные версии HAProxy умеют экспортировать метрики в формате Prometheus для интеграции с Grafana.

Практика 07

Используйте balance leastconn для долгих сессий

Для WebSocket или Streaming предпочтительнее leastconn, чтобы равномерно распределять нагрузку.

Практика 08

Настройте maxconn для бэкенда

Ограничьте число соединений к серверу через maxconn, чтобы слабый бэкенд не упал при всплеске.

Практика / Безопасность

Безопасность HAProxy: что нельзя делать

Риск 01

Не открывайте stats page без аутентификации

Stats page показывает IP серверов, состояния, метрики. Всегда ставьте stats auth и ограничьте доступ по IP.

Риск 02

Не допускайте раскрытия внутренних IP через заголовки

Настройте option forwardfor и удалите Server-заголовок через http-response set-header Server Hidden.

Риск 03

Не используйте один сертификат SSL без защиты приватного ключа

Храните приватные ключи в защищённом месте, используйте chroot.

Риск 04

Не выставляйте HAProxy в интернет без ограничения соединений

DDoS может исчерпать maxconn. Ограничьте общее число соединений в global и для каждого фронтенда.

Риск 05

Не запускайте HAProxy от root без необходимости

Используйте cap_net_bind_service или перенаправление через iptables для портов <1024.

Риск 06

Не забывайте обновлять HAProxy

В старых версиях найдены уязвимости (например, CVE-2021-20226). Регулярно обновляйте пакет.

Риск 07

Не используйте mode tcp для HTTP-маршрутизации

В TCP-режиме HAProxy не понимает HTTP и не может использовать ACL по заголовкам.

Риск 08

Не забывайте про option redispatch

Если сервер выпал, а сессия привязана через stick table, без redispatch запрос не перенаправится.

Будущее / Роль

Перспективы HAProxy

Перспективы HAProxy завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.

Сигнал 01

Балансировка в мире Kubernetes

С ростом контейнеров и оркестрации балансировка уходит внутрь кластеров, и HAProxy живёт там как Ingress-контроллер. Навык не исчезает, а смещается: те же понятия — backend,...

Сигнал 02

Наблюдаемость как обязательный слой

От балансировщика всё чаще ждут не только распределения трафика, но и детальных метрик: задержки, коды ответов, состояние бэкендов в Prometheus и трассировке. Умение вытащить...

Сигнал 03

Современные протоколы на входе

HTTP/2, gRPC и запрос на QUIC/HTTP/3 двигают требования к точке входа. HAProxy развивается вслед за протоколами, и от инженера ждут понимания, как балансировать не только...

Практика / Портфолио

Портфолио с HAProxy: с чего начать

Проект 01

Отказоустойчивая точка входа веб-сервиса

HAProxy перед пулом из двух-трёх веб-серверов в Docker: frontend с терминацией TLS, backend с health-проверками и leastconn, ACL для разведения /api и статики, включённая страница статистики. Показывает, что вы...

Проект 02

Пара HAProxy + keepalived с автоматизацией

Два узла HAProxy с общим виртуальным адресом по VRRP, конфиг вынесен в Ansible-роль, метрики уходят в Prometheus. Демонстрирует главное, чего ждёт работодатель: балансировщик, который сам не является единственной точкой...

Обучение / Маршрут

Как изучить HAProxy

Базовый конфиг HAProxy собирается за вечер — frontend, backend, пара серверов. Но понимание, которого ждёт работодатель — L4 против L7, здравые health checks, отказоустойчивая пара — приходит только с практикой на реальной инфраструктуре.

Этап 01

Разобраться, что делает балансировщик

Понять задачу целиком: зачем нужна балансировка, чем обратный прокси отличается от балансировщика, что такое отказоустойчивость и горизонтальное...

Этап 02

Собрать первый конфиг

Написать haproxy.cfg с одним frontend и одним backend на два-три сервера, поднять в Docker, проверить, что запросы распределяются. Включить встроенную...

Этап 03

Health checks и алгоритмы

Настроить проверки здоровья (option httpchk), погонять roundrobin и leastconn, погасить один бэкенд и убедиться, что трафик уходит на живые. Это ядро...

Этап 04

L7: ACL и маршрутизация

Перейти в режим HTTP, написать ACL по пути и заголовкам, развести трафик по разным backend через use_backend. Здесь HAProxy становится управляемой точкой...

Курсы · по данным рынка

Где учить HAProxy

Соответствие — доля тем навыка, которые охватывает программа курса

Практика / Первый запуск

Как начать изучать HAProxy

Три шага от первого конфига до отказоустойчивой пары.

Шаг 01

Поднять базовый конфиг

Написать haproxy.cfg с одним frontend и одним backend на пару серверов, запустить в Docker и убедиться, что запросы распределяются. Включить встроенную страницу статистики и наблюдать за...

Шаг 02

Добавить проверки и правила

Настроить health checks, погасить один бэкенд и увидеть, как трафик уходит на живой. Перейти в режим HTTP, написать ACL по пути и развести запросы по разным backend.

Шаг 03

Собрать отказоустойчивую схему

Настроить терминацию TLS, поднять пару HAProxy + keepalived с виртуальным адресом и вынести конфиг в Ansible-роль. Так навык переходит из учебного в продовый.

Старт / Документация

Официальные ресурсы и быстрый старт

Для инструментов вроде HAProxy на одной странице полезно держать и объяснение роли на рынке, и быстрые переходы к официальным ресурсам.

Частые вопросы

Вопросы и ответы

Что такое HAProxy простыми словами?

Это программа-посредник, которая стоит перед группой серверов и распределяет между ними входящий трафик. Пользователь обращается к одному адресу, а HAProxy решает, какому из серверов передать запрос, и не шлёт трафик на упавшие. Так сервис выдерживает нагрузку и переживает отказ отдельных узлов.

Чем HAProxy отличается от Nginx?

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

В чём разница между L4 и L7 балансировкой?

На L4 (режим TCP) HAProxy распределяет соединения, не заглядывая внутрь: видит только адреса и порты, зато работает с любым протоколом и очень быстро. На L7 (режим HTTP) он разбирает запрос — путь, заголовки, cookie — и может маршрутизировать по содержимому, терминировать TLS, вести подробный лог. Выбор режима определяет, что HAProxy сможет делать с трафиком.

Кому нужен навык HAProxy?

Прежде всего DevOps-инженерам, а также системным администраторам и SRE — всем, кто отвечает за доступность инфраструктуры. Его почти не спрашивают отдельно: он идёт в связке с Nginx, keepalived, Docker, Ansible и мониторингом. К HAProxy обычно приходят, уже поработав с веб-серверами и обратными прокси.

Как HAProxy обеспечивает отказоустойчивость?

На двух уровнях. Он постоянно проверяет здоровье бэкендов health-проверками и автоматически выводит из ротации те, что перестали отвечать. А чтобы сам балансировщик не был единственной точкой отказа, его разворачивают парой с keepalived: два узла делят виртуальный адрес, и при падении активного трафик мгновенно подхватывает резервный.

Что такое sticky sessions и когда они нужны?

Это привязка пользователя к одному бэкенду на время сессии — через cookie или stick table. Нужна приложениям, которые хранят состояние сессии в памяти конкретного узла: без привязки пользователя перекинет на другой сервер, и сессия потеряется. Но привязка ломает равномерность балансировки, поэтому правильнее делать приложение stateless, а sticky sessions использовать только там, где иначе нельзя.

Сложно ли освоить HAProxy?

Базовый конфиг с frontend, backend и парой серверов собирается за вечер — синтаксис haproxy.cfg прозрачный. Сложность не в директивах, а в понимании: чем L4 отличается от L7, как настроить осмысленные health checks, как построить пару без единой точки отказа. Это приходит с практикой на реальной инфраструктуре, а не с чтением примеров.