Защо curl се свързва с localhost вместо с отдалечения URL

Ако curl се опитва да се свърже с localhost независимо от URL адреса, който му давате, VPN е грешното място, от което да започнете. Локален HTTP или SOCKS прокси сървър може да е предвидената първа връзка, дори когато услугата, която искате, е съвсем другаде. Ако този прокси сървър вече не работи, опитът към localhost се проваля, преди curl изобщо да достигне дестинацията. Отговорът от прокси сървъра също не е доказателство, че дестинацията е отговорила.

Изпълнете тези стъпки по ред и спрете на първата, която промени първия опит за свързване.

Прочетете първо собствените правила на curl за прокси

curl чете специфични за протокола променливи за прокси, като https_proxy и HTTPS_PROXY, както и ALL_PROXY, когато не се прилага стойност за конкретния протокол. Проверете средата на обвивката, услугата или задачата, която действително стартира curl, а не тази в текущия ви терминал. CI задача, systemd unit и интерактивна обвивка могат да наследят три различни набора. Точно отгатването по видимата обвивка е причината това разследване да загуби цял следобед.

Едно изключение си заслужава да се запомни. 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 от прокси, провал на сертификат и грешка при оторизация посочват четири различни етапа.