Почему curl подключается к localhost вместо удалённого URL

Если curl пытается подключиться к localhost независимо от указанного вами URL, VPN — это неправильное место для начала. Локальный прокси HTTP или SOCKS может быть намеренным первым подключением, даже если нужный вам сервис находится совсем в другом месте. Если этот прокси больше не работает, попытка localhost терпит неудачу ещё до того, как curl достигнет назначения. Ответ прокси тоже не доказывает, что ответило назначение.

Выполняйте эти шаги по порядку и остановитесь на первом, который изменит первую попытку подключения.

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

curl читает переменные прокси, заданные для протокола, например https_proxy и HTTPS_PROXY, а также ALL_PROXY, когда не применяется ни одно значение, специфичное для протокола. Проверьте окружение оболочки, службы или задачи, которая действительно запускает curl, а не того, что в текущем терминале. Задача CI, юнит systemd и интерактивная оболочка могут унаследовать три разных набора. Именно догадки по видимой оболочке и приводят к тому, что это расследование теряет целый день.

Одно исключение стоит запомнить. curl принимает http_proxy только строчными буквами; вариант заглавными HTTP_PROXY игнорируется, поэтому одна и та же среда ведёт себя иначе в других инструментах.

Читайте значения конфиденциально, потому что URL прокси часто содержит учётные данные.

Затем проверьте файл конфигурации curl по умолчанию на переопределения прокси или соединения и убедитесь, какой именно исполняемый файл вы запускаете. Псевдоним оболочки, функция или скрипт-обёртка могут добавить параметры, которые никогда не появляются в вашей командной строке.

Сравните три вызова с включённым TLS

Используйте одно утверждённое диагностическое назначение и один и тот же бинарный файл для всех трёх запусков.

curl -v https://service.corp.example/status
curl -q -v https://service.corp.example/status
curl -q --proxy '' -v https://service.corp.example/status

-q подавляет curlrc по умолчанию и должен быть первым параметром в строке, чтобы работать. Он не удаляет переменные окружения прокси, что удивляет тех, кто этого ожидает. Третья форма добавляет пустое значение --proxy, переопределяя запрошенный средой прокси только для этого вызова. Сравнивайте первую попытку подключения в каждом выводе, а не итоговый код состояния.

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

Что исключает каждый результат

Если пропуск конфигурации по умолчанию меняет подключение, источник — файл конфигурации. Если его меняет явное отключение унаследованного прокси, источник — переменная окружения. Если ни то ни другое его не меняет, а localhost всё равно появляется, посмотрите на переопределения соединения в командной строке, разрешение имён хостов и выбранный исполняемый файл. У каждого из них своё исправление, и ни одно из них не является изменением маршрутизации.

Загрузка собственных библиотек или внедрённое сетевое поведение — это более поздний слой, и одна переменная окружения не является его доказательством.

Держите решение о прокси отдельно от VPN

Как только curl выбирает прямое назначение, операционная система всё равно маршрутизирует это соединение. Отключение прокси приложения не отключает маршрут VPN или его политику фильтрации. Сравнения прямого доступа проводите только там, где такая диагностика разрешена. Тест, который тихо обходит политику, — не допустимый результат, а инцидент.

Если локальный прокси необходим, восстановите его службу и адрес, а не удаляйте его настройки.

Если прямой доступ нужен только отдельным частным назначениям, добавьте узкое утверждённое исключение и оставьте прокси для всего остального. Сохраните первую ошибку на выбранном пути, потому что отказ localhost, отклонение CONNECT прокси, сбой сертификата и ошибка авторизации указывают на четыре разных этапа.