Тестируем отдельный backend по HTTPS: curl --connect-to сохраняет имя сервиса

За балансировщиком работают три backend, и ошибка возникает лишь иногда. Для проверки конкретного экземпляра нужен запрос напрямую к его адресу и порту. Но приложение ожидает публичное имя, а сертификат относится к этому имени. Опция connect-to позволяет изменить сетевую точку подключения, сохранив логическое назначение запроса.

Разделите имя сервиса и транспортный адрес

curl --connect-to api.example:443:192.0.2.31:8443 --connect-timeout 5 --max-time 15 -v https://api.example/health

Первая пара определяет соединение, которое нужно перенаправить. Вторая — фактический адрес и порт. HTTP-запрос по-прежнему относится к api.example. TLS использует это имя для server name и проверки сертификата. Backend должен действительно обслуживать HTTPS на 8443; направление HTTPS на обычный HTTP-порт даст ошибку протокола.

В отличие от resolve, здесь удобно менять и порт назначения. Это полезно, когда внешний вход принимает 443, а отдельный backend — 8443. Сама опция не превращает частный сертификат backend в доверенный. Если у него другая удостоверенная идентичность, нужно тестировать именно её с соответствующим URL, а не подавлять ошибку через insecure.

Выберите корректный участок проверки

Прямой доступ к backend должен быть предусмотрен сетью и политикой сервиса. Балансировщик может добавлять авторизацию, client certificate или другие обязательные данные. Тогда прямой ответ 401 не обязательно означает неисправность экземпляра: вы обошли компонент, который выполняет часть контракта.

Проверьте, какие заголовки и параметры действительно нужны для диагностического read-only запроса. Не копируйте доверенные внутренние заголовки клиента без понимания модели безопасности приложения. Для воспроизведения лучше отдельный health-путь, рассчитанный на такую проверку из разрешённой сети.

Сравните экземпляры одинаковым запросом

Выполните вызов для каждого адреса, сохраняя URL, метод, тело и ограничения времени. Зафиксируйте адрес соединения и идентификатор backend в ответе или его журнале. Если два узла отвечают ожидаемо, а третий отдаёт старую версию, появляется конкретная причина нестабильности за балансировщиком.

Если все backend исправны напрямую, вернитесь к общему входу. Причина может быть в маршрутизации балансировщика, проверке upstream TLS, обработке Host или соединении между уровнями. Успех прямой проверки исключает лишь часть пути, поэтому отдельно сравните входящий запрос и тот, который балансировщик отправляет дальше.

Подробный вывод curl помогает заметить прокси. Если соединение идёт через него, убедитесь, что фактическая схема действительно позволяет направить трафик к выбранному backend. Для прямого разрешённого теста настройте адресный обход прокси и сохраните это условие в отчёте.

После исправления проблемного экземпляра повторите прямой вызов, затем серию запросов через общий вход. Стабильный ответ обоих уровней завершает проверку исходной задачи: отдельный backend исправен и корректно участвует в обслуживании сервиса.

Разбирайте доступность по участкам сетевого пути. Курс Linux и Bash для DevOps-инженеров включает сеть, порты и HTTP на учебном сервере. Откройте программу, чтобы превратить такой приём в последовательный способ локализации ошибок сервиса.

Ещё по теме

• Медленный HTTPS-запрос: раскладываем время curl на DNS, TCP, TLS и ожидание ответа
• curl завершился успешно после HTTP 500: сохраняем тело ошибки и код отказа