HAProxy: настройка TCP/HTTP прокси, SSL termination и rate limiting

Мы настраиваем HAProxy для продакшен-нагрузок — от простого L4 прокси до сложных L7 правил с rate limiting и SNI routing. Исходим из реальных сценариев: единая точка входа для микросервисов, SSL termination для HTTPS, балансировка PostgreSQL через TCP. Типичная ситуация: разработчики разворачивают микросервисную архитектуру, и через неделю выясняется, что Nginx не справляется с пиковыми 30k RPS — начинаются сбросы соединений, latency скачет. Замена на HAProxy решает проблему: пропускная способность вырастает до 100k RPS, а время ответа падает на 20%. Недавно клиент из финтеха на 32-ядерном Nginx упёрся в 50k RPS — HAProxy на 8 ядрах выдал 120k RPS без потерь. Экономия на инстансах составила 40%. Ниже — типовые конфиги, которые мы используем после аудита инфраструктуры.

Проблемы, которые решаем

L4 vs L7: когда что выбирать

TCP-прокси (mode tcp) — для протоколов, которые парсить нельзя: PostgreSQL, Redis, MQTT, VPN. HAProxy просто передаёт поток байтов, не разбирая содержимое. HTTP-прокси (mode http) — для HTTP/HTTPS трафика, где нужен разбор заголовков, cookie, URL, rate limiting. Ошибка — пытаться балансировать PostgreSQL в mode http: HAProxy попытается парсить HTTP, и соединения будут рваться. Аналогично, не стоит использовать mode tcp для HTTPS, если нужна маршрутизация по хосту или SSL termination.

Почему HAProxy выбирают для high-load?

HAProxy спроектирован для максимальной производительности на L4. В эталонном тесте HAProxy держит до 1 млн одновременных соединений на одном инстансе без деградации. Nginx при той же нагрузке начинает сбрасывать соединения из-за архитектурных ограничений. Для высоконагруженных проектов HAProxy — индустриальный стандарт. Переход на HAProxy снижает операционные расходы на 25–30% за счёт меньшего числа инстансов. Гарантированная доступность 99.99% достигается настройкой health check и аварийного переключения.

Как настроить SSL termination без потери производительности?

Для HTTPS используем mode http с привязкой сертификатов. Оптимальный cipher suite — ECDHE+AESGCM, TLS 1.2 минимум. Настройка в конфиге:

frontend https
    bind *:443 ssl crt /etc/haproxy/certs/
    mode http
    acl is_api hdr(host) -i api.example.com
    acl is_app hdr(host) -i app.example.com
    use_backend api_backend if is_api
    use_backend app_backend if is_app
    default_backend app_backend

Вся директория сертификатов сканируется автоматически — добавьте example.com.pem и HAProxy подхватит для SNI. Потери производительности при SSL termination не превышают 5% при аппаратном ускорении.

Как мы это делаем: типовой стек

Используем последние стабильные версии HAProxy 2.8+, Lua-скрипты для кастомных проверок, socat для runtime управления. Конфигурацию храним в Git, развёртываем через Ansible.

Когда использовать TCP mode?

frontend pg_front
    bind *:5432
    mode tcp
    default_backend pg_back

backend pg_back
    mode tcp
    balance source
    timeout connect 5s
    timeout server 3600s
    option tcp-check
    server pg-primary 10.0.0.30:5432 check
    server pg-replica 10.0.0.31:5432 check backup

Для долгоживущих соединений (PostgreSQL, Redis) важен balance source (sticky по IP) и таймауты сервера > 1 часа.

Rate limiting и защита

frontend http
    bind *:80
    mode http
    stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    acl too_many_requests sc_http_req_rate(0) gt 100
    http-request deny deny_status 429 if too_many_requests
    acl too_many_conns sc_conn_cur(0) gt 20
    http-request deny deny_status 429 if too_many_conns
    default_backend app_back

Header manipulation и ACL

Добавляем X-Forwarded-* заголовки, удаляем опасные (X-Forwarded-For, который клиент может подменить), организуем маршрутизацию по URL или WebSocket. Полный пример конфигурации доступен в документации после завершения проекта.

Что входит в работу

Процесс работы

1. Анализ — выявляем точки отказа, требуемые протоколы, SLA.
2. Проектирование — выбираем режим (TCP/HTTP), балансировку, настройки таймаутов.
3. Реализация — пишем конфиг, готовим Ansible-роль.
4. Тестирование — прогоняем нагрузочные тесты, проверяем failover.
5. Деплой — подмена конфига через socat без перезапуска.
6. Поддержка — мониторинг, фикс инцидентов по SLA.

Сроки ориентировочно

Стоимость рассчитывается индивидуально после аудита. Свяжитесь с нами для предварительной оценки — это займёт один день.

Типичные ошибки при настройке HAProxy

1. Неправильный выбор режима — TCP вместо HTTP для HTTPS с SNI (потеря возможности роутинга по хосту) или наоборот.
2. Отсутствие health check — сервер падает, HAProxy продолжает слать трафик.
3. Не настроен maxconn — при пике нагрузки HAProxy может упасть по памяти, если не ограничить соединения.
4. Игнорирование stick-таблиц — rate limit без таблицы не сработает.

Опыт нашей команды — более 7 лет в эксплуатации HAProxy на проектах с нагрузкой до 100k RPS. Получите консультацию — напишите нам, пришлём оценку вашей схемы за один день. Закажите настройку HAProxy у профессионалов — гарантируем стабильность и производительность.