Зошто curl се поврзува со localhost наместо со далечинскиот URL

Ако curl се обидува да се поврзе со localhost без оглед на URL-то што сте го дале, VPN е погрешното место за почеток. Локален HTTP или SOCKS прокси може да биде предвидената прва врска, дури и кога услугата што ја сакате е сосема на друго место. Ако тој прокси повеќе не работи, обидот кон localhost пропаѓа пред curl воопшто да стигне до целта. Ниту одговорот од прокси не е доказ дека целта одговорила.

Изведете ги овие чекори по ред и застанете на првиот што го менува првиот обид за поврзување.

Прво прочитајте ги сопствените прокси правила на curl

curl чита прокси променливи специфични за протоколот, како https_proxy и HTTPS_PROXY, како и ALL_PROXY кога не се применува ниту една вредност специфична за протоколот. Проверете ја околината на shell-от, услугата или задачата што всушност го стартува curl, а не онаа во тековниот терминал. CI задача, systemd единица и интерактивен shell можат да наследат три различни множества. Токму погодувањето од видливиот shell е причината оваа истрага да изгуби цело попладне.

Вреди да се запамети еден исклучок. curl прифаќа http_proxy само со мали букви; големите букви HTTP_PROXY се игнорираат, поради што истата околина се однесува поинаку во други алатки.

Читајте ги вредностите приватно, бидејќи URL-то на прокси често носи акредитиви.

Потоа проверете ја стандардната конфигурациска датотека на curl за заобиколувања на прокси или врска и потврдете која извршна датотека навистина ја извршувате. Alias во shell, функција или скрипта за обвиткување можат да додадат опции што никогаш не се појавуваат на вашата командна линија.

Спорете три повикувања со вклучен 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 од прокси, неуспехот на сертификатот и грешката при авторизација означуваат четири различни фази.