Внутренний API уходит через корпоративный прокси: проверяем curl и NO_PROXY

Внутренний API доступен из сети сервера, но curl получает страницу корпоративного прокси или ошибку CONNECT. При этом другой клиент работает. Возможная причина — переменные окружения: curl направляет запрос через прокси, который не знает внутреннее имя либо не имеет права соединяться с ним.

Посмотрите фактическое соединение

curl --connect-timeout 5 --max-time 15 -v https://inventory.internal.example/health

В подробном выводе видно использование proxy-переменной и адрес промежуточного соединения. Для HTTPS обычно появляется CONNECT к целевому имени. Это означает, что вы проверяете путь через прокси, а не прямую доступность API с сервера. Успешное разрешение имени локальным DNS ещё не подтверждает, что его разрешит сам прокси.

Проверьте значения https_proxy, HTTPS_PROXY, all_proxy, ALL_PROXY, no_proxy и NO_PROXY в окружении запуска. Не копируйте их целиком в отчёт: URL прокси может содержать учётные данные. Важны имя узла, схема, порт и список исключений. Для HTTP curl намеренно принимает http_proxy в нижнем регистре, что тоже может объяснять различия окружений.

Сравните разрешённый прямой путь

curl --noproxy inventory.internal.example --connect-timeout 5 --max-time 15 -v https://inventory.internal.example/health

Такую проверку выполняют, когда прямой доступ к внутреннему API предусмотрен политикой сети. Она исключает прокси для указанного имени на один вызов. Если запрос теперь работает, сопоставьте ошибку прокси и прямой ответ: это конкретное основание корректировать исключение, а не отключать прокси для всех назначений.

Если прямая проверка тоже не работает, разделите её этапы. Ошибка разрешения имени относится к локальному DNS, таймаут соединения — к пути и правилам, отказ сертификата — к TLS. Удаление прокси-переменной не исправляет эти причины автоматически.

Закрепите исключение в нужном окружении

Для одного сервиса задайте точное имя в no_proxy. Если требуется доменный суффикс или диапазон IP, проверьте правила сопоставления установленного curl. Поддержка CIDR появилась в curl 7.86.0. Другие приложения могут трактовать NO_PROXY иначе, поэтому работоспособность curl не доказывает эквивалентное поведение Java-клиента или браузера.

Учтите имя в URL. Исключение для IP не обязательно покрывает запрос по DNS-имени, даже когда оно разрешается в этот IP. Для понятной конфигурации описывайте именно те имена, которыми пользуется приложение. При redirect на другое имя решение о прокси потребуется и для следующего назначения.

После изменения проверьте внутренний API и один внешний сервис, который должен по-прежнему идти через прокси. В подробном выводе подтвердите оба маршрута. Это покажет, что исправлено точное исключение и сохранена исходная схема выхода в сеть.

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

Ещё по теме

• Тестируем отдельный backend по HTTPS: curl --connect-to сохраняет имя сервиса
• curl завершился успешно после HTTP 500: сохраняем тело ошибки и код отказа