Файл с именем /check.txt на хосте прокси кажется очевидной целью проверки. Подвох в том, что явный прямой слушатель Squid — не обычный сайт, отдающий корень документов этого хоста.

Запрос в стиле источника, например HEAD /check.txt HTTP/1.1, опускает абсолютную цель, ожидаемую для обычного HTTP-запроса через прямой прокси. В зависимости от конфигурации он может быть отклонён или обработан другой локальной службой. Любой результат может сказать меньше, чем подсказывает панель.

Выберите службу, которую нужно держать доступной

ПроверкаПолезное доказательство
TCP-соединение со слушателем проксиДоступный процесс принимает это соединение.
CONNECT к контролируемой целиПрокси принимает этот запрос туннеля.
Получение HTTP через проксиВыбранный путь запроса может вернуть ожидаемый ответ.

В третьем случае запросу нужна цель, например:

HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internal

Имя хоста приведено лишь для примера. Используйте контролируемую конечную точку, которую прокси умеет разрешать и к которой ему намеренно разрешён доступ. http-check send в HAProxy поддерживает выбор метода, URI, версии и заголовков; настройте этот запрос явно, вместо того чтобы неизменно наследовать пример сервера-источника.

HEAD позволяет проверить статус ответа и заголовки. Он не может проверить тело ответа, которое никогда не передаётся. Если контракт здоровья требует маркер в теле, выберите подходящую проверку GET и проверьте этот маркер.

Когда задействована аутентификация прокси, держите учётную запись проверки и ограничения по источникам узкими. Освобождение всего слушателя от аутентификации ради зелёной отметки меняет защищаемую службу.

Наконец, решите, что должна убирать неудачная проверка. Контролируемый сбой источника может одновременно обвалить проверку пересылки у каждого прокси. Это может быть ровно та зависимость, которую вы хотите измерять, или причина держать здоровье слушателя и сквозную доступность отдельными сигналами.

Похожие статьи