Чаму 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 проксі, збой сертыфіката і памылка аўтарызацыі паказваюць на чатыры розныя этапы.