Что это
Балансировщик нагрузки и обратный прокси для TCP и HTTP: принимает трафик на frontend, распределяет по бэкенд-серверам, проверяет их здоровье и терминирует TLS.
HAProxy — высокопроизводительный балансировщик нагрузки и обратный прокси для TCP и HTTP. Он стоит перед группой серверов, распределяет между ними трафик, проверяет их здоровье и снимает упавшие с ротации — так строят отказоустойчивую точку входа.
HAProxy — балансировщик нагрузки и обратный прокси, который стоит перед группой серверов и распределяет между ними входящий трафик. Он умеет работать на двух уровнях: на транспортном (L4, режим TCP) — просто раскидывает соединения, не заглядывая внутрь, и на прикладном (L7, режим HTTP) — разбирает запрос, читает заголовки, URL и cookie и принимает решения на их основе. За счёт событийной однопроцессной архитектуры HAProxy держит десятки тысяч одновременных соединений на скромном железе, поэтому его ставят там, где нельзя терять ни производительность, ни отказоустойчивость.
Смысл HAProxy не в том, чтобы «раздать запросы по серверам», а в том, чтобы построить точку входа, которая переживёт падение отдельных бэкендов. Health checks постоянно проверяют, живы ли серверы, и мёртвые автоматически выводятся из ротации; ACL-правила маршрутизируют трафик по содержимому запроса; терминация TLS снимает шифрование с плеч приложения; sticky sessions привязывают пользователя к одному бэкенду. Всё это описывается в одном текстовом конфиге haproxy.cfg, а сам HAProxy почти всегда работает в паре с keepalived, чтобы не быть единственной точкой отказа.
Для этого навыка доступны ограниченные данные (менее 50 вакансий или нет зарплатных данных). Аналитика носит ориентировочный характер.
Балансировщик нагрузки и обратный прокси для TCP и HTTP: принимает трафик на frontend, распределяет по бэкенд-серверам, проверяет их здоровье и терминирует TLS.
В первую очередь DevOps-инженеры, также системные администраторы и SRE: те, кто отвечает за доступность и отказоустойчивость инфраструктуры.
Устойчивый инфраструктурный навык из мира высокой доступности. Спрашивают не отдельно, а в связке с Nginx, keepalived, Docker и системами мониторинга.
HAProxy (High Availability Proxy) — это прослойка между клиентами и группой серверов, которая принимает все входящие соединения на себя и решает, какому из бэкендов их передать. Клиент видит один адрес и один порт, а за ними скрывается пул из нескольких серверов, которые можно добавлять, выводить на обслуживание и терять без простоя для пользователя. HAProxy написан на C, работает как один процесс с событийным циклом и славится тем, что стабильно держит очень высокую нагрузку при низком потреблении ресурсов — именно поэтому он десятилетиями стоит на входе крупных высоконагруженных площадок.
Конфигурация HAProxy строится вокруг двух секций. Frontend описывает, что слушать: адрес, порт, протокол, правила приёма трафика и логику маршрутизации. Backend описывает, куда направлять: список серверов (директивы server), алгоритм балансировки и параметры проверки здоровья. Между ними связка через use_backend и default_backend. Одному frontend может соответствовать несколько backend — например, запросы к /api уходят на одну группу серверов, а всё остальное на другую. Весь этот набор живёт в haproxy.cfg, и по нему одному можно прочитать всю схему движения трафика.
Ключевое различие, которое надо понимать, — на каком уровне HAProxy работает. В режиме TCP (L4, транспортный уровень) он балансирует соединения вслепую: видит только адреса и порты, не разбирая содержимое. Это быстро и подходит для любого протокола — баз данных, очередей, чистого TCP. В режиме HTTP (L7, прикладной уровень) HAProxy разбирает каждый запрос: читает метод, путь, заголовки и cookie, может маршрутизировать по URL, переписывать заголовки, терминировать TLS и вести детальный лог. Плата за это — чуть больше работы на запрос. Выбор режима определяет, что вообще HAProxy сможет делать с трафиком.
Путь запроса от клиента до живого бэкенда — через проверки и правила.
Приём на frontend
HAProxy принимает соединение на заданном адресе и порту, при необходимости терминирует TLS и, если работает на L7, разбирает HTTP-запрос — метод, путь, заголовки, cookie.
Решение по ACL и здоровью
По ACL HAProxy выбирает нужный backend, а внутри него берёт сервер по алгоритму балансировки — но только из тех, что прошли health-проверку. Мёртвые узлы в расчёт не идут.
Передача на бэкенд
Запрос уходит выбранному серверу, при sticky sessions клиент закрепляется за ним на сессию. Ответ возвращается через HAProxy, а статистика и логи фиксируют, что произошло.
HAProxy переносится между ролями: DevOps-инженер, Системный администратор, SRE-инженер. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.
DevOps-инженер — самый заметный профиль в распределении ролей по навыку.
Ещё 1 ролей используют HAProxy
Текущий срез показывает активные вакансии сейчас. Распределение по ролям рассчитано по расширенной исторической выборке, поэтому значения могут быть выше текущего количества активных вакансий.
HAProxy ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами — ниже они разобраны так, как встречаются в реальной работе.
Базовый 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 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 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 Терминация 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 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 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 Настроить распределение и забыть про health checks — значит слать трафик на упавший сервер и отдавать пользователям ошибки. Без осмысленных проверок (не просто TCP-коннект, а реальный HTTP-запрос на рабочий путь) балансировщик теряет главный смысл — отказоустойчивость.
Один узел HAProxy перед пулом серверов защищает бэкенды, но сам становится местом, падение которого кладёт всё. Продовая схема — минимум пара с keepalived и общим виртуальным адресом; без этого высокая доступность существует только на бумаге.
Пытаться маршрутизировать по URL или читать заголовки в режиме TCP — не сработает: на L4 HAProxy не видит содержимого запроса. И наоборот, гнать через L7 протокол, которому разбор HTTP не нужен, — лишняя работа. Выбор режима надо делать осознанно под задачу.
Включать привязку к серверу везде «на всякий случай» — ломать равномерность балансировки и живучесть: при падении узла его пользователи теряют сессии. Sticky sessions нужны только приложениям с состоянием в памяти; правильнее делать приложение stateless.
Взять готовый haproxy.cfg из интернета и запустить, не понимая директив, — почти гарантированно получить неверные таймауты, бесполезные проверки или дыру в TLS. Конфиг HAProxy читается как схема трафика; каждую строку нужно понимать, а не заклинать.
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 сохраняет устойчивый прикладной спрос на рынке: 65 активных вакансий, #172 по рынку, 0.9% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.
#172 по рынку • 0.9% IT-вакансий
-13 вакансий и -13% к предыдущему месяцу.
HAProxy редко живёт изолированно: чаще всего рынок видит его рядом с Linux, Nginx, Ansible. Самая плотная связка сейчас - Linux: оба навыка встречаются вместе в 85% вакансий.
Главная связка: Linux • 85% вакансий. Показываем общерыночные связки HAProxy: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.
навыки, которые рынок чаще всего видит рядом в одной вакансии
Рынок редко нанимает только под один навык: ниже показываем, какой стек обычно ждут рядом с HAProxy на старте.
Медианная вакансия с HAProxy ожидает около 26.5 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.
В резюме владение HAProxy показывает, что вы понимаете, как строить отказоустойчивую инфраструктуру. Ниже — что означает навык на разных уровнях и что указать.
С чем HAProxy работает в реальных проектах.
Отказоустойчивость самого HAProxy
Нужна точка входа без единой точки отказа
Даёт только переключение адреса, но не балансировку сам по себе.
Веб-сервер и раздача контента
Нужны статика, кэш и динамика на том же фронте
Упаковка и запуск HAProxy
Разворачиваете балансировщик в контейнерной среде
Один контейнер без оркестрации не даёт отказоустойчивости.
Автоматизация конфигурации
Конфиг нужно тиражировать и держать как код
Не управляет трафиком в рантайме — только раскатывает конфиг.
Сбор метрик и наблюдаемость
Нужен мониторинг состояния бэкендов и задержек
Только наблюдает — на само распределение трафика не влияет.
HAProxy ставят везде, где нужна отказоустойчивая точка входа: от одного пула веб-серверов до отказоустойчивых пар и балансировки баз данных.
HAProxy стоит перед пулом веб- или API-серверов, распределяет запросы, снимает упавшие узлы с ротации и терминирует TLS. Классическая роль на входе...
В режиме TCP HAProxy балансирует соединения к репликам PostgreSQL, кластерам Galera, брокерам очередей. Умные health-проверки отправляют трафик только на живой...
Два узла HAProxy делят виртуальный адрес по VRRP: активный обслуживает трафик, резервный подхватывает при падении. Так убирают единственную точку отказа на самом...
HAProxy заметен в 1 направлениях рынка с долей выше 5%.
Возможности, за которые его ставят на входе высоконагруженных систем.
Работает и с чистым TCP для любых протоколов, и с HTTP для маршрутизации по содержимому запроса — один инструмент на оба уровня.
Health checks постоянно опрашивают серверы и убирают из ротации те, что перестали отвечать, возвращая их при восстановлении.
Снимает шифрование на входе, редиректит на HTTPS и разводит трафик по backend через ACL на путь, заголовки и адрес.
Встроенная страница статистики и метрики показывают состояние бэкендов, задержки и коды ответов в реальном времени.
Три способа закрыть балансировку — у каждого своя зона.
Nginx — прежде всего веб-сервер: раздаёт статику, кэширует, обслуживает динамику, а балансировка у него одна из функций. HAProxy заточен только под балансировку и проксирование и делает это тоньше —...
Управляемый балансировщик облачного провайдера сам масштабируется и не требует своей отказоустойчивой пары — его просто включают и не обслуживают. HAProxy даёт полный контроль над логикой,...
В кластерах Kubernetes балансировку на входе закрывает Ingress-контроллер, работающий с динамическим набором подов, — и HAProxy как раз может быть таким контроллером. Разница не в идеях, а в среде:...
HAProxy — это демон, который читает конфигурационный файл (обычно /etc/haproxy/haproxy.cfg). Рассмотрим минимальный запуск и структуру.
apt install haproxy для Ubuntu/Debian, yum install haproxy для CentOS/RHEL. Запуск: systemctl start haproxy.
Глобальные настройки процесса: maxconn, daemon, pidfile, параметры SSL.
Значения по умолчанию для всех последующих фронтендов и бэкендов: mode, timeout connect/client/server.
Слушает порт, принимает соединения. Определяет bind и default_backend.
Определяет список серверов, алгоритм балансировки и health checks.
Совмещает frontend и backend для простых случаев.
Полный конфиг с global, defaults, frontend www, backend web_servers с health check каждые 3с.
systemctl reload haproxy или SIGHUP — перечитывает конфиг без обрыва текущих соединений.
Без check в строке сервера HAProxy не будет знать, жив ли бэкенд. Обязательно настройте option httpchk или tcpchk.
Даже для простого сценария пишите отдельно frontend и backend — это облегчает будущее расширение.
Для API обычно 5-30с, для веб-сокетов — 3600с. Используйте timeout connect, timeout server, timeout client.
ACL позволяют направлять трафик в зависимости от заголовков, пути, метода. Избегайте одного backend для всего.
Stats page — мощный инструмент мониторинга, но без пароля её оставлять нельзя. Используйте stats auth.
Современные версии HAProxy умеют экспортировать метрики в формате Prometheus для интеграции с Grafana.
Для WebSocket или Streaming предпочтительнее leastconn, чтобы равномерно распределять нагрузку.
Ограничьте число соединений к серверу через maxconn, чтобы слабый бэкенд не упал при всплеске.
Stats page показывает IP серверов, состояния, метрики. Всегда ставьте stats auth и ограничьте доступ по IP.
Настройте option forwardfor и удалите Server-заголовок через http-response set-header Server Hidden.
Храните приватные ключи в защищённом месте, используйте chroot.
DDoS может исчерпать maxconn. Ограничьте общее число соединений в global и для каждого фронтенда.
Используйте cap_net_bind_service или перенаправление через iptables для портов <1024.
В старых версиях найдены уязвимости (например, CVE-2021-20226). Регулярно обновляйте пакет.
В TCP-режиме HAProxy не понимает HTTP и не может использовать ACL по заголовкам.
Если сервер выпал, а сессия привязана через stick table, без redispatch запрос не перенаправится.
Перспективы HAProxy завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.
С ростом контейнеров и оркестрации балансировка уходит внутрь кластеров, и HAProxy живёт там как Ingress-контроллер. Навык не исчезает, а смещается: те же понятия — backend,...
От балансировщика всё чаще ждут не только распределения трафика, но и детальных метрик: задержки, коды ответов, состояние бэкендов в Prometheus и трассировке. Умение вытащить...
HTTP/2, gRPC и запрос на QUIC/HTTP/3 двигают требования к точке входа. HAProxy развивается вслед за протоколами, и от инженера ждут понимания, как балансировать не только...
HAProxy перед пулом из двух-трёх веб-серверов в Docker: frontend с терминацией TLS, backend с health-проверками и leastconn, ACL для разведения /api и статики, включённая страница статистики. Показывает, что вы...
Два узла HAProxy с общим виртуальным адресом по VRRP, конфиг вынесен в Ansible-роль, метрики уходят в Prometheus. Демонстрирует главное, чего ждёт работодатель: балансировщик, который сам не является единственной точкой...
Базовый конфиг HAProxy собирается за вечер — frontend, backend, пара серверов. Но понимание, которого ждёт работодатель — L4 против L7, здравые health checks, отказоустойчивая пара — приходит только с практикой на реальной инфраструктуре.
Разобраться, что делает балансировщик
Понять задачу целиком: зачем нужна балансировка, чем обратный прокси отличается от балансировщика, что такое отказоустойчивость и горизонтальное...
Собрать первый конфиг
Написать haproxy.cfg с одним frontend и одним backend на два-три сервера, поднять в Docker, проверить, что запросы распределяются. Включить встроенную...
Health checks и алгоритмы
Настроить проверки здоровья (option httpchk), погонять roundrobin и leastconn, погасить один бэкенд и убедиться, что трафик уходит на живые. Это ядро...
L7: ACL и маршрутизация
Перейти в режим HTTP, написать ACL по пути и заголовкам, развести трафик по разным backend через use_backend. Здесь HAProxy становится управляемой точкой...
Соответствие — доля тем навыка, которые охватывает программа курса
Три шага от первого конфига до отказоустойчивой пары.
Написать haproxy.cfg с одним frontend и одним backend на пару серверов, запустить в Docker и убедиться, что запросы распределяются. Включить встроенную страницу статистики и наблюдать за...
Настроить health checks, погасить один бэкенд и увидеть, как трафик уходит на живой. Перейти в режим HTTP, написать ACL по пути и развести запросы по разным backend.
Настроить терминацию TLS, поднять пару HAProxy + keepalived с виртуальным адресом и вынести конфиг в Ansible-роль. Так навык переходит из учебного в продовый.
Для инструментов вроде HAProxy на одной странице полезно держать и объяснение роли на рынке, и быстрые переходы к официальным ресурсам.
Это программа-посредник, которая стоит перед группой серверов и распределяет между ними входящий трафик. Пользователь обращается к одному адресу, а HAProxy решает, какому из серверов передать запрос, и не шлёт трафик на упавшие. Так сервис выдерживает нагрузку и переживает отказ отдельных узлов.
Nginx — это в первую очередь веб-сервер, который умеет раздавать статику, кэшировать и попутно балансировать. HAProxy заточен только под балансировку и проксирование и делает это тоньше: больше алгоритмов, полноценный TCP-режим, детальная статистика. Nginx берут как универсальный фронт, HAProxy — когда в приоритете именно балансировка и контроль трафика.
На L4 (режим TCP) HAProxy распределяет соединения, не заглядывая внутрь: видит только адреса и порты, зато работает с любым протоколом и очень быстро. На L7 (режим HTTP) он разбирает запрос — путь, заголовки, cookie — и может маршрутизировать по содержимому, терминировать TLS, вести подробный лог. Выбор режима определяет, что HAProxy сможет делать с трафиком.
Прежде всего DevOps-инженерам, а также системным администраторам и SRE — всем, кто отвечает за доступность инфраструктуры. Его почти не спрашивают отдельно: он идёт в связке с Nginx, keepalived, Docker, Ansible и мониторингом. К HAProxy обычно приходят, уже поработав с веб-серверами и обратными прокси.
На двух уровнях. Он постоянно проверяет здоровье бэкендов health-проверками и автоматически выводит из ротации те, что перестали отвечать. А чтобы сам балансировщик не был единственной точкой отказа, его разворачивают парой с keepalived: два узла делят виртуальный адрес, и при падении активного трафик мгновенно подхватывает резервный.
Это привязка пользователя к одному бэкенду на время сессии — через cookie или stick table. Нужна приложениям, которые хранят состояние сессии в памяти конкретного узла: без привязки пользователя перекинет на другой сервер, и сессия потеряется. Но привязка ломает равномерность балансировки, поэтому правильнее делать приложение stateless, а sticky sessions использовать только там, где иначе нельзя.
Базовый конфиг с frontend, backend и парой серверов собирается за вечер — синтаксис haproxy.cfg прозрачный. Сложность не в директивах, а в понимании: чем L4 отличается от L7, как настроить осмысленные health checks, как построить пару без единой точки отказа. Это приходит с практикой на реальной инфраструктуре, а не с чтением примеров.