Kodėl curl jungiasi prie localhost, o ne prie nuotolinio URL

Jei curl bando jungtis prie localhost nepaisydamas jūsų nurodyto URL, VPN yra netinkama vieta pradėti. Vietinis HTTP arba SOCKS tarpinis serveris gali būti numatytas pirmasis ryšys, net kai norima paslauga yra visai kitur. Jei tas tarpinis serveris nebeveikia, bandymas prie localhost nepavyksta dar prieš curl pasiekiant tikslą. Tarpinio serverio atsakymas taip pat neįrodo, kad tikslas atsakė.

Atlikite šiuos veiksmus iš eilės ir sustokite ties pirmuoju, kuris pakeičia pirmąjį ryšio bandymą.

Pirmiausia perskaitykite pačios curl tarpinio serverio taisykles

curl skaito protokolui būdingus tarpinio serverio kintamuosius, pvz., https_proxy ir HTTPS_PROXY, taip pat ALL_PROXY, kai netaikoma jokia protokolui būdinga reikšmė. Tikrinkite tos shell, paslaugos ar užduoties aplinką, kuri iš tikrųjų paleidžia curl, o ne dabartinio terminalo. CI užduotis, systemd įrenginys ir interaktyvi shell gali paveldėti tris skirtingus rinkinius. Būtent spėliojimas pagal matomą shell yra priežastis, dėl kurios šis tyrimas praranda visą popietę.

Vieną išimtį verta įsiminti. curl priima http_proxy tik mažosiomis raidėmis; didžiosiomis HTTP_PROXY ignoruojamas, todėl ta pati aplinka kituose įrankiuose elgiasi kitaip.

Skaitykite reikšmes privačiai, nes tarpinio serverio URL dažnai turi prisijungimo duomenų.

Tada patikrinkite numatytąjį curl konfigūracijos failą dėl tarpinio serverio arba ryšio perrašų ir patvirtinkite, kurį vykdomąjį failą iš tikrųjų paleidžiate. Shell alias, funkcija ar apvalkalo scenarijus gali pridėti parinkčių, kurios niekada neatsiranda jūsų komandų eilutėje.

Palyginkite tris iškvietimus su įjungtu TLS

Naudokite vieną patvirtintą diagnostinį tikslą ir tą patį dvejetainį failą visiems trims paleidimams.

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 nuslopina numatytąjį curlrc ir turi būti pirmasis eilutės parametras, kad veiktų. Jis nepašalina tarpinio serverio aplinkos kintamųjų, o tai nustebina tuos, kurie to tikisi. Trečioji forma prideda tuščią --proxy reikšmę ir panaikina aplinkos prašyto tarpinio serverio poveikį tik tam iškvietimui. Lyginkite pirmąjį ryšio bandymą kiekvienoje išvestyje, o ne galutinį būsenos kodą.

Išsami išvestis gali atskleisti antraštes, žetonus ir tarpinio serverio prisijungimo duomenis, todėl laikykite ją vietoje ir perskaitykite ištraukas prieš bendrindami.

Ką kiekvienas rezultatas atmeta

Jei numatytosios konfigūracijos praleidimas pakeičia ryšį, šaltinis yra konfigūracijos failas. Jei jį pakeičia aiškus paveldėto tarpinio serverio išjungimas, šaltinis yra aplinkos kintamasis. Jei nė vienas jo nepakeičia ir localhost vis dar rodomas, patikrinkite komandų eilutės ryšio perrašas, prieglobos vardų sprendimą ir pasirinktą vykdomąjį failą. Kiekvienas jų turi skirtingą pataisą, ir nė vienas nėra maršrutizavimo pakeitimas.

Pasirinktinių bibliotekų įkėlimas ar įterptas tinklo elgesys yra vėlesnis sluoksnis, ir vien aplinkos kintamasis nėra to įrodymas.

Laikykite tarpinio serverio sprendimą atskirai nuo VPN

Kai curl pasirenka tiesioginį tikslą, operacinė sistema vis tiek maršrutizuoja tą ryšį. Programos tarpinio serverio išjungimas neišjungia VPN maršruto ar jo filtravimo politikos. Tiesioginės prieigos palyginimus atlikite tik ten, kur ši diagnostika leidžiama. Testas, kuris tyliai apeina politiką, nėra galiojantis rezultatas, tai incidentas.

Jei reikia vietinio tarpinio serverio, atkurkite jo paslaugą ir adresą, o ne trinkite jo nustatymus.

Jei tiesioginės prieigos reikia tik pasirinktiems privatiems tikslams, pridėkite siaurą patvirtintą išimtį ir palikite tarpinį serverį viskam kitam. Išsaugokite pirmąją pasirinkto kelio klaidą, nes localhost atsisakymas, tarpinio serverio CONNECT atmetimas, sertifikato gedimas ir autorizacijos klaida nurodo keturis skirtingus etapus.