Что именно проверяет HAProxy в mode tcp?
В режиме mode tcp HAProxy работает на транспортном уровне: принимает TCP-соединение и передаёт байтовый поток выбранному backend-серверу. Он не обязан разбирать URL, заголовки HTTP или зашифрованное содержимое TLS. Такой режим применяют для HTTPS, баз данных и других протоколов поверх TCP.
Базовая активная проверка отвечает на узкий вопрос: удаётся ли установить TCP-соединение с адресом и портом. Полученный SYN/ACK означает, что сетевой путь и слушающий сокет доступны. Это сильнее обычного ping, но слабее подтверждения, что приложение способно выполнить полезную операцию.
Telegram-flow
Хотите подключить VPN без ручных настроек?
Откройте бота: он покажет trial или тариф, отправит файл подключения и QR-код прямо в Telegram.
Как включить health check для backend-сервера?
Аргумент check в строке server включает периодические проверки конкретного узла. Без него HAProxy не получает активного сигнала о готовности и может продолжать направлять новые соединения на сервер, пока состояние не изменит оператор, Runtime API или другая внешняя система.
Директива option tcp-check задаёт TCP-сценарий для backend. В простом случае достаточно подключения. Если протокол позволяет безопасный обмен, сценарий можно дополнить tcp-check connect, send и expect. Проверка должна быть идемпотентной: никаких создаваемых записей и тяжёлых пользовательских операций.
Как работают inter, fall и rise?
Параметр inter задаёт обычный интервал между проверками; в актуальной документации HAProxy значение по умолчанию равно двум секундам. Слишком редкая проверка поздно обнаружит отказ, а неоправданно частая создаст лишние соединения и шум. Интервал выбирают по допустимому времени реакции.
fall определяет число последовательных неудач до состояния DOWN, а rise — число успешных проверок до возврата в UP. Например, fall 3 и rise 2 отфильтруют одиночную потерю пакета и не вернут нестабильный узел после одного случайно удачного ответа. Это гистерезис, а не задержка ради задержки.
Почему открытый TCP-порт не означает готовность приложения?
Сокет может принимать соединения, когда рабочие процессы зависли, очередь переполнена или база данных недоступна. На уровне L4 узел выглядит живым, хотя пользовательский запрос не проходит полный цикл. Поэтому слова «доступен» и «готов» в мониторинге должны иметь разные определения.
Глубина проверки зависит от риска. Простому TCP-реле достаточно соединения. Приложению с зависимостями полезнее отдельная точка готовности или короткий протокольный обмен. Слишком глубокий health check тоже опасен: нестабильная внешняя зависимость способна вывести из ротации все исправные серверы.
Когда нужен расширенный option tcp-check?
Расширенный сценарий уместен, если сервис после подключения выдаёт предсказуемое приветствие или принимает безопасную команду чтения. HAProxy может соединиться, отправить минимальную последовательность и проверить ожидаемую часть ответа. Это приближает сигнал к готовности приложения, не превращая проверку в полноценную сессию.
Сценарий должен иметь короткий timeout, стабильный ответ и ясную причину отказа. Ему не следует зависеть от стороннего сайта, создавать учётную запись или запускать тяжёлый запрос. Проверяйте только то, без чего конкретный backend действительно не способен обслужить новое соединение.
Как проверить конфигурацию и выполнить мягкий reload?
Перед применением запустите haproxy -f ./haproxy.cfg -c и оцените код завершения. Режим -c разбирает конфигурацию без привязки к портам и без воздействия на работающий процесс. Он ловит синтаксические ошибки и неизвестные директивы, но не подтверждает доступность backend-серверов.
После успешной проверки применяют штатный reload, например через systemctl, если пакет и unit-файл его поддерживают. В корректной master-worker схеме новые соединения принимает новый процесс, а старые завершаются на прежнем. Это поведение нужно проверить для своей установки, прежде чем считать любое слово reload безусловно бесшовным.
Почему HAProxy не является универсальным балансировщиком UDP?
Mode tcp работает с TCP и не превращает HAProxy в прокси для произвольных UDP-дейтаграмм. Проверка TCP-backend ничего не говорит о доступности UDP-сервиса. Совпадение номера порта или успешный контрольный TCP-сокет не подтверждают, что реальный поток другого протокола проходит.
Это существенно для WireGuard-совместимых решений: AmneziaWG обычно передаёт туннельный трафик по UDP. Стандартный HAProxy в mode tcp не является универсальным балансировщиком такого канала. OneBucksVPN не заявляет HAProxy частью текущего VPN-тракта; статья описывает общий инструмент администрирования.
Какие короткие ответы важно запомнить?
Достаточно ли добавить check в строку server?
Для базовой проверки TCP-соединения обычно да. Но она подтверждает только доступность адреса и порта; готовность приложения требует отдельного безопасного сигнала.
Почему сервер не становится DOWN после первой ошибки?
Порог задаёт fall. Например, при fall 3 единичный сбой не исключит сервер: HAProxy дождётся трёх последовательных неудачных проверок.
Прервёт ли reload уже установленные соединения?
При правильно настроенном мягком reload они обычно продолжаются на старом процессе. Итог зависит от версии, режима запуска и unit-файла, поэтому это проверяют заранее.
Telegram-flow
Хотите подключить VPN без ручных настроек?
Откройте бота: он покажет trial или тариф, отправит файл подключения и QR-код прямо в Telegram.