Pse curl lidhet me localhost në vend të URL-së së largët

Nëse curl përpiqet të lidhet me localhost pavarësisht URL-së që i dhatë, VPN-ja është vendi i gabuar për të filluar. Një proxy HTTP ose SOCKS lokal mund të jetë lidhja e parë e synuar, edhe kur shërbimi që dëshironi ndodhet diku tjetër. Nëse ai proxy nuk punon më, përpjekja drejt localhost dështon përpara se curl të arrijë cakun. As përgjigjja e proxy-t nuk është provë që caku u përgjigj.

Ndiqu këto hapa me radhë dhe ndaloni në të parin që ndryshon përpjekjen e parë të lidhjes.

Fillimisht lexoni rregullat e proxy-t të vetë curl

curl lexon variabla proxy specifike për protokollin, si https_proxy dhe HTTPS_PROXY, si dhe ALL_PROXY kur nuk zbatohet asnjë vlerë specifike për protokollin. Inspektoni mjedisin e shell-it, shërbimit ose detyrës që nis vërtet curl, jo atë të terminalit tuaj aktual. Një punë CI, një njësi systemd dhe një shell interaktiv mund të trashëgojnë tre grupe të ndryshme. Është pikërisht hamendja nga shell-i i dukshëm ajo që e bën këtë hetim të humbasë një pasdite të tërë.

Një përjashtim ia vlen të mbahet mend. curl e pranon http_proxy vetëm me shkronja të vogla; forma me shkronja të mëdha HTTP_PROXY injorohet, dhe për këtë arsye i njëjti mjedis sillet ndryshe në mjete të tjera.

Lexoni vlerat në mënyrë private, sepse një URL proxy shpesh mbart kredenciale.

Më pas kontrolloni skedarin e konfigurimit të parazgjedhur të curl për zëvendësime proxy ose lidhjeje, dhe konfirmoni cilin skedar ekzekutues po ekzekutoni vërtet. Një alias shell, një funksion ose një skript mbështjellës mund të shtojnë opsione që nuk shfaqen kurrë në rreshtin tuaj të komandës.

Krahasoni tri thirrje me TLS të ndezur

Përdorni një cak diagnostik të miratuar dhe të njëjtin binar për të tre ekzekutimet.

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 e shtyp skedarin curlrc të parazgjedhur dhe duhet të jetë parametri i parë në rresht që të funksionojë. Nuk i heq variablat e mjedisit të proxy-t, gjë që i habit ata që e presin pikërisht këtë. Forma e tretë shton një vlerë --proxy bosh, duke zëvendësuar proxy-n e kërkuar nga mjedisi vetëm për atë thirrje. Krahasoni përpjekjen e parë të lidhjes në çdo dalje, jo kodin e statusit përfundimtar.

Dalja e detajuar mund të ekspozojë tituj, shenja dhe kredenciale proxy, prandaj mbajeni lokale dhe lexoni fragmente përpara se ta shpërndani.

Çfarë përjashton çdo rezultat

Nëse heqja e konfigurimit të parazgjedhur ndryshon lidhjen, burimi është skedari i konfigurimit. Nëse çaktivizimi i qartë i proxy-t të trashëguar e ndryshon atë, burimi është variabla e mjedisit. Nëse asnjëra nuk e ndryshon dhe localhost shfaqet ende, shikoni zëvendësimet e lidhjes në rreshtin e komandës, zgjidhjen e emrave të host-eve dhe skedarin ekzekutues të zgjedhur. Secili prej tyre ka një rregullim tjetër, dhe asnjë prej tyre nuk është ndryshim i rrugëtimit.

Ngarkimi i bibliotekave të personalizuara ose sjellja e rrjetit e injektuar është një shtresë e mëvonshme, dhe një variabël mjedisi e vetme nuk është provë e saj.

Mbajeni vendimin për proxy-n të ndarë nga VPN-ja

Pasi curl zgjedh një cak të drejtpërdrejtë, sistemi operativ vazhdon ta rrugëtojë atë lidhje. Çaktivizimi i një proxy aplikacioni nuk çaktivizon rrugën e VPN-së ose politikën e saj të filtrimit. Kryeni krahasime të aksesit të drejtpërdrejtë vetëm aty ku ai diagnostikim është i autorizuar. Një test që anashkalon në heshtje politikën nuk është rezultat i vlefshëm, është incident.

Nëse kërkohet një proxy lokal, rivendosni shërbimin dhe adresën e tij në vend që të fshini cilësimet e tij.

Nëse vetëm disa cakë privatë të zgjedhur kanë nevojë për akses të drejtpërdrejtë, shtoni një përjashtim të ngushtë të miratuar dhe mbajeni proxy-n për gjithçka tjetër. Ruani gabimin e parë nga rruga e zgjedhur, sepse refuzimi nga localhost, refuzimi CONNECT nga proxy, dështimi i certifikatës dhe gabimi i autorizimit tregojnë katër faza të ndryshme.