HAProxy: налаштування TCP/HTTP, SSL-термінація та 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 у професіоналів — гарантуємо стабільність і продуктивність.