Новинка Виртуальный VDS сервер в Финляндии от 390р
Выберите продукт

HAProxy с HTTP/3/QUIC: TLS‑терминация и проксирование к HTTP/1.1/2 бэкендам

Разберём включение HTTP/3/QUIC в HAProxy 2.9+: TLS‑терминация с ALPN на 443 для одновременной работы h3/h2/h1, проксирование к бэкендам HTTP/1.1 и HTTP/2, диагностика, тюнинг производительности и безопасные параметры TLS.
HAProxy с HTTP/3/QUIC: TLS‑терминация и проксирование к HTTP/1.1/2 бэкендам

HTTP/3 на базе QUIC давно перестал быть экспериментом и уже заметно ускоряет доставки для мобильных и географически распределённых пользователей: меньше задержек за счёт отказа от head-of-line blocking уровня TCP, быстрая установка соединения и более устойчивое поведение к потере пакетов. Практичный паттерн для продакшена — терминировать TLS и HTTP/3 на фронтовом HAProxy и проксировать запросы на бэкенды по HTTP/1.1 или HTTP/2. В результате мы получаем совместимость со старыми клиентами и выгоду от HTTP/3 для новых, сохраняя лаконичную конфигурацию и единый порт 443 с ALPN.

Что даёт связка HAProxy + HTTP/3/QUIC

Ключевые преимущества для фронтенда:

  • Сокращение латентности на старте за счёт QUIC и TLS 1.3.
  • Отсутствие head-of-line blocking: потеря одного пакета не блокирует весь поток запросов.
  • Единый порт 443 с ALPN: клиенты автоматически выбирают лучший доступный протокол — h3, h2 или http/1.1.
  • Прозрачная работа с привычными бэкендами: можно оставить HTTP/1.1 либо перейти на HTTP/2 там, где это приносит пользу.

Важно: HTTP/3 в HAProxy доступен в актуальных стабильных ветках (2.9/3.0+). Убедитесь, что бинарь собран с поддержкой QUIC и подходящей TLS-библиотеки.

Требования и проверка сборки

Перед настройкой проверьте окружение:

  • Версия HAProxy 2.9 или новее (желательно текущий LTS/Stable).
  • Сборка с поддержкой QUIC. Проверяем:
haproxy -vv | grep -i quic

В выводе ищем отметки о QUIC и используемой TLS-библиотеке. Если поддержки нет — используйте пакет поставщика, где QUIC включён, либо собирайте самостоятельно согласно документации вашей платформы.

  • Откройте в файрволе 443/TCP и 443/UDP (QUIC — это UDP).
  • Сертификаты TLS (желательно комплект ECDSA+RSA для лучшей совместимости) и промежуточные цепочки корректно объединены в файлы сертификатов HAProxy. При отсутствии валидного сертификата оформите SSL-сертификаты.

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

Фрагмент конфигурации HAProxy с ALPN h3,h2,http/1.1 и параметром quic на 443

Базовая схема и порты

Мы слушаем порт 80 для редиректа на HTTPS и порт 443 для TLS‑терминации. На 443 включаем alpn с приоритетом h3, далее h2, затем http/1.1. Один bind на 443 обслуживает и TCP, и UDP сокеты, так что клиенты сами договорятся о протоколе через ALPN.

Базовая конфигурация HAProxy (HTTP/3 фронт, HTTP/1.1 бэкенд)

Стартовая конфигурация, с которой удобно начать. Она включает логирование, безопасные таймауты, редирект с 80 на HTTPS, ALPN и заголовок Alt-Svc для рекламы HTTP/3.

global
  log stdout format raw daemon
  master-worker
  nbthread 2
  maxconn 10000
  tune.ssl.default-dh-param 2048
  ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
  ssl-default-bind-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
  stats socket /run/haproxy/admin.sock mode 660 level admin
  # Лёгкий тюнинг QUIC: экономичные, но практичные значения
  tune.quic.max-idle-time 5s

defaults
  mode http
  log global
  option httplog
  option dontlognull
  timeout connect 5s
  timeout client 30s
  timeout server 30s
  option http-keep-alive
  http-reuse safe
  option forwardfor

frontend fe_http
  bind :80
  http-request redirect scheme https code 301 unless { ssl_fc }

frontend fe_https
  bind :443 ssl crt /etc/haproxy/certs/ alpn h3,h2,http/1.1 quic
  # Пробрасываем схему, полезно для приложений/логики редиректов
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  # Рекомендуем клиентам HTTP/3
  http-response set-header alt-svc h3=":443"; ma=86400
  default_backend be_app_h1

backend be_app_h1
  balance roundrobin
  http-reuse safe
  server app1 127.0.0.1:8080 check
  # Добавляйте узлы по мере необходимости

Эта конфигурация уже обслуживает клиентов по HTTP/3/QUIC, HTTP/2 и HTTP/1.1, при этом к приложению она ходит по HTTP/1.1. Этого часто достаточно, особенно если приложение не получает заметной выгоды от HTTP/2 внутри приватной сети.

Вариант B: проксирование к HTTP/2 бэкенду

Если ваш бэкенд-стек хорошо масштабируется со множеством параллельных потоков (например, gRPC или активная загрузка ассетов), можно включить HTTP/2 «за» HAProxy. Есть два режима: h2c (чистый HTTP/2 без TLS) и HTTP/2 поверх TLS. Первый быстрее и проще внутри доверенной сети, второй уместен, если требуется шифрование и проверка сертификатов до точки назначения.

HTTP/2 без TLS (h2c) к бэкенду

backend be_app_h2c
  mode http
  balance roundrobin
  # Ваш origin должен уметь cleartext HTTP/2 (h2c)
  server app1 127.0.0.1:8082 proto h2 check
  server app2 127.0.0.1:8083 proto h2 check

Далее в фронтенде можно маршрутизировать часть доменов на h2c‑бэкенд:

frontend fe_https
  bind :443 ssl crt /etc/haproxy/certs/ alpn h3,h2,http/1.1 quic
  acl host_h2c hdr(host) -i h2c.example.test
  use_backend be_app_h2c if host_h2c
  default_backend be_app_h1

HTTP/2 поверх TLS к бэкенду

Когда соединение до бэкенда должно быть шифровано (например, между датацентрами), используйте TLS с ALPN на серверных линиях. Внутренний CA можно указать для проверки, либо временно ослабить проверку на этапе миграции.

backend be_app_h2_tls
  balance roundrobin
  # Если есть корпоративный CA, укажите verify required ca-file /etc/ssl/internal_ca.pem
  server app1 app.internal:8443 ssl verify none alpn h2,http/1.1 check
  server app2 app2.internal:8443 ssl verify none alpn h2,http/1.1 check

При маршрутизации:

frontend fe_https
  bind :443 ssl crt /etc/haproxy/certs/ alpn h3,h2,http/1.1 quic
  acl host_h2tls hdr(host) -i h2tls.example.test
  use_backend be_app_h2_tls if host_h2tls
  default_backend be_app_h1

ALPN: порядок имеет значение

Строка alpn h3,h2,http/1.1 на фронтенде определяет приоритет предложений клиенту. Современные браузеры выберут h3, если поддерживают QUIC и видят UDP‑443. Если UDP закрыт либо клиент старый — произойдёт откат на h2 или http/1.1. На серверных строках ALPN помогает HAProxy выбрать протокол к апстриму: для TLS‑бэкендов явное alpn h2,http/1.1 гарантирует попытку HTTP/2 прежде, чем fallback на HTTP/1.1.

Логи, диагностика и проверка

  • Проверка с клиента:
curl -I --http3 https://example.test
curl -I --http2 https://example.test
curl -I https://example.test
  • Проверка UDP‑доступности (с внешнего узла):
nmap -sU -p 443 example.test
  • Мониторинг QUIC‑сессий через сокет управления:
echo 'show quic' | socat - /run/haproxy/admin.sock

Чтобы видеть выбранный протокол на фронте, добавьте кастомный формат логов, включающий %[ssl_fc_alpn], и анализируйте долю h3/h2/h1 в трафике.

Проверка HTTP/3 и HTTP/2 через curl и мониторинг QUIC-сессий

Тюнинг производительности: практичные пресеты

Оптимальные значения зависят от профиля трафика. Ниже — безопасная отправная точка и пояснения, куда смотреть при росте нагрузки.

  • Конкурентность: nbthread, привязка к CPU и maxconn под пиковую RPS. Не забываем о лимитах ядра и дескрипторов.
  • Таймауты: timeout connect 5s, timeout client/server 30s подходят для большинства сайтов; для API с длительными потоками увеличивайте аккуратно.
  • HTTP‑reuse: http-reuse safe снижает издержки установки соединений к бэкендам, не ломая совместимость.
  • HTTP/2: при активном использовании настроить лимит потоков и размер окна. Аккуратно повышайте tune.h2.max-concurrent-streams и следите за нагрузкой на приложение.
  • QUIC: начинайте с консервативного tune.quic.max-idle-time. Если много мобильных клиентов — разумно увеличить до 10–15s, чтобы уменьшить частоту новых рукопожатий.

Не забывайте профилировать не только сам HAProxy, но и апстримы: рост параллелизма HTTP/2 может упереться во внутренние пулы подключений, блокировки, GC и т. п.

Безопасность TLS и совместимость

  • HTTP/3 обязан использовать TLS 1.3; на фронте логично ограничить набор шифров до современных (см. ssl-default-bind-ciphersuites в примере).
  • Комплект сертификатов с ECDSA и RSA помогает старым клиентам. Убедитесь, что цепочки оформлены корректно.
  • Alt-Svc безопасно рекламирует h3, но не навязывает; клиенты сами переключатся при возможности.
  • Следите за OCSP stapling и сроками действия цепочки, чтобы избежать деградации при возобновлениях рукопожатий.
FastFox SSL
Надежные SSL-сертификаты
Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Плавная миграция и откат

Стратегия внедрения без сюрпризов выглядит так:

  1. Откройте UDP‑443 на периметре, разверните фронт с ALPN, но сначала оставьте alt-svc только на небольшой доле доменов.
  2. Наблюдайте логи: доля h3, латентность, ошибки, загрузка CPU/сетевого стека.
  3. Увеличивайте процент доменов/трафика, переводимых на HTTP/3.
  4. Для быстрого отката достаточно убрать h3 из alpn на фронтенде и перезагрузить конфигурацию.

Частые ошибки и их признаки

  • Забыт UDP‑443 в файрволе: HTTP/3 не виден, клиенты всегда откатываются на h2/h1. Проверьте порты и маршрутизацию.
  • Некорректная цепочка сертификатов: всплеск рукопожатий/ошибок, нестабильные возобновления. Пересоберите файл crt с полной цепочкой.
  • Не тот порядок ALPN: если http/1.1 стоит раньше h2, некоторые клиенты никогда не выберут HTTP/2. Следите за порядком — h3,h2,http/1.1.
  • Слишком агрессивные таймауты: на мобильных сетях возможны ложные обрывы. Поднимите tune.quic.max-idle-time и timeout client.
  • h2c к бэкенду без поддержки: origin не умеет HTTP/2 без TLS, соединения рвутся. Используйте proto h2 только там, где это подтверждено.

Чеклист перед продакшеном

  • HAProxy 2.9/3.0+ с поддержкой QUIC (haproxy -vv подтверждает).
  • Открыты 443/TCP и 443/UDP; мониторинг доступности снаружи.
  • На фронтах: bind :443 ssl crt ... alpn h3,h2,http/1.1 quic, корректный Alt-Svc.
  • Бэкенды: явный ALPN для TLS‑узлов, proto h2 — только к h2c‑совместимым приложениям.
  • Логи включают %[ssl_fc_alpn] для разбора распределения по протоколам.
  • Таймауты и reuse согласованы с профилем трафика, есть headroom по maxconn.
  • Подготовлен план отката: убрать h3 из ALPN и перезагрузить конфигурацию.

Итог: включение HTTP/3/QUIC в HAProxy — это небольшое изменение фронта, которое приносит реальную выгоду в производительности и устойчивости соединений, не требуя замены ваших существующих бэкендов. Начните с консервативной конфигурации, измеряйте, постепенно добавляйте HTTP/2 к тем апстримам, где он даст наибольший эффект, и держите под рукой понятный сценарий отката.

Поделиться статьей

Вам будет интересно

Как безопасно выполнить bootstrap MariaDB Galera после полного останова

Как безопасно выполнить bootstrap MariaDB Galera после полного останова

После одновременной остановки всех узлов Galera обычного запуска MariaDB недостаточно. Сначала найдите сервер с последней транзакц ...
CoreDNS в Kubernetes: исправляем CrashLoopBackOff, SERVFAIL и DNS-петлю

CoreDNS в Kubernetes: исправляем CrashLoopBackOff, SERVFAIL и DNS-петлю

Разберём, почему CoreDNS перезапускается или отвечает SERVFAIL, как обнаружить замкнутую пересылку DNS-запросов, проверить доступн ...
Apache Kafka KRaft на VDS: отдельные controller и broker

Apache Kafka KRaft на VDS: отдельные controller и broker

Соберём новый Kafka-кластер без ZooKeeper на шести Linux VDS: три узла controller образуют отказоустойчивый metadata quorum, а три ...