Kāpēc curl savienojas ar localhost, nevis ar attālo URL

Ja curl mēģina savienoties ar localhost neatkarīgi no jūsu dotā URL, VPN ir nepareizā vieta, kur sākt. Lokāls HTTP vai SOCKS starpniekserveris var būt paredzētais pirmais savienojums, pat ja vēlamais pakalpojums atrodas pavisam citur. Ja šis starpniekserveris vairs nedarbojas, mēģinājums uz localhost neizdodas, pirms curl vispār sasniedz galamērķi. Arī starpniekservera atbilde nav pierādījums, ka galamērķis ir atbildējis.

Izpildiet šos soļus secīgi un apstājieties pie pirmā, kas maina pirmo savienojuma mēģinājumu.

Vispirms izlasiet paša curl starpniekservera noteikumus

curl lasa protokolam raksturīgos starpniekservera mainīgos, piemēram, https_proxy un HTTPS_PROXY, kā arī ALL_PROXY, ja nepiemērojas neviena protokolam raksturīga vērtība. Pārbaudiet tās čaulas, pakalpojuma vai uzdevuma vidi, kas faktiski palaiž curl, nevis jūsu pašreizējā termināļa vidi. CI uzdevums, systemd vienība un interaktīva čaula var mantot trīs dažādas kopas. Tieši minēšana pēc redzamās čaulas ir iemesls, kāpēc šī izmeklēšana zaudē veselu pēcpusdienu.

Vienu izņēmumu ir vērts atcerēties. curl pieņem http_proxy tikai ar mazajiem burtiem; ar lielajiem burtiem rakstīto HTTP_PROXY ignorē, tāpēc tā pati vide citos rīkos uzvedas citādi.

Lasiet vērtības privāti, jo starpniekservera URL bieži satur akreditācijas datus.

Pēc tam pārbaudiet noklusējuma curl konfigurācijas failu attiecībā uz starpniekservera vai savienojuma pārrakstīšanu un apstipriniet, kuru izpildāmo failu jūs faktiski palaižat. Čaulas aizstājvārds, funkcija vai ietvērējskripts var pievienot opcijas, kas nekad neparādās jūsu komandrindā.

Salīdziniet trīs izsaukumus ar ieslēgtu TLS

Visām trim palaišanām izmantojiet vienu apstiprinātu diagnostikas galamērķi un to pašu bināro failu.

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 nomāc noklusējuma curlrc un, lai darbotos, tam jābūt rindas pirmajam parametram. Tas neizņem starpniekservera vides mainīgos, kas pārsteidz tos, kuri to gaida. Trešā forma pievieno tukšu --proxy vērtību un atceļ vides pieprasīto starpniekserveri tikai šim izsaukumam. Salīdziniet pirmo savienojuma mēģinājumu katrā izvadē, nevis galīgo statusa kodu.

Detalizēta izvade var atklāt galvenes, marķierus un starpniekservera akreditācijas datus, tāpēc glabājiet to lokāli un pirms kopīgošanas izlasiet fragmentus.

Ko katrs rezultāts izslēdz

Ja noklusējuma konfigurācijas izlaišana maina savienojumu, avots ir konfigurācijas fails. Ja to maina mantotā starpniekservera skaidra atspējošana, avots ir vides mainīgais. Ja neviens to nemaina un localhost joprojām parādās, apskatiet komandrindas savienojuma pārrakstīšanu, resursdatora nosaukumu atrisināšanu un izvēlēto izpildāmo failu. Katram no tiem ir cits labojums, un neviens no tiem nav maršrutēšanas izmaiņas.

Pielāgotu bibliotēku ielāde vai ievadīta tīkla uzvedība ir vēlāks slānis, un tikai vides mainīgais nav tā pierādījums.

Turiet starpniekservera lēmumu atsevišķi no VPN

Kad curl izvēlas tiešu galamērķi, operētājsistēma joprojām maršrutē šo savienojumu. Lietotnes starpniekservera atspējošana neatslēdz VPN maršrutu vai tā filtrēšanas politiku. Veiciet tiešas piekļuves salīdzinājumus tikai tur, kur šī diagnostika ir atļauta. Tests, kas klusi apiet politiku, nav derīgs rezultāts, tas ir incidents.

Ja nepieciešams lokāls starpniekserveris, atjaunojiet tā pakalpojumu un adresi, nevis dzēsiet tā iestatījumus.

Ja tieša piekļuve nepieciešama tikai atlasītiem privātiem galamērķiem, pievienojiet šauru apstiprinātu izņēmumu un saglabājiet starpniekserveri visam citam. Saglabājiet pirmo kļūdu izvēlētajā ceļā, jo localhost atteikums, starpniekservera CONNECT noraidījums, sertifikāta kļūme un autorizācijas kļūda norāda četrus dažādus posmus.