De ce curl se conectează la localhost în loc de URL-ul de la distanță

Dacă curl încearcă să se conecteze la localhost indiferent de URL-ul pe care i l-ați dat, VPN-ul este locul greșit de unde să începeți. Un proxy HTTP sau SOCKS local poate fi prima conexiune dorită, chiar și atunci când serviciul pe care îl doriți este cu totul altundeva. Dacă proxy-ul respectiv nu mai rulează, încercarea către localhost eșuează înainte ca curl să ajungă la destinație. Nici un răspuns al proxy-ului nu este dovada că destinația a răspuns.

Urmați acești pași în ordine și opriți-vă la primul care schimbă prima încercare de conectare.

Citiți mai întâi regulile de proxy ale curl însuși

curl citește variabile de proxy specifice protocolului, cum ar fi https_proxy și HTTPS_PROXY, precum și ALL_PROXY atunci când nu se aplică nicio valoare specifică protocolului. Inspectați mediul shell-ului, serviciului sau sarcinii care lansează efectiv curl, nu pe cel din terminalul curent. O sarcină CI, o unitate systemd și un shell interactiv pot moșteni trei seturi diferite. Exact ghicitul din shell-ul vizibil este ceea ce face această investigație să piardă o după-amiază întreagă.

Merită reținută o excepție. curl acceptă http_proxy doar cu litere mici; varianta cu litere mari HTTP_PROXY este ignorată, motiv pentru care același mediu se comportă diferit în alte instrumente.

Citiți valorile în mod privat, deoarece un URL de proxy transportă adesea acreditări.

Apoi verificați fișierul de configurare implicit al curl pentru suprascrieri de proxy sau de conexiune și confirmați ce fișier executabil rulați de fapt. Un alias de shell, o funcție sau un script wrapper pot adăuga opțiuni care nu apar niciodată pe linia de comandă.

Comparați trei invocări cu TLS activat

Folosiți o singură destinație de diagnostic aprobată și același binar pentru toate cele trei rulări.

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 suprimă curlrc implicit și trebuie să fie primul parametru de pe linie pentru a funcționa. Nu elimină variabilele de mediu pentru proxy, ceea ce îi surprinde pe cei care se așteaptă la asta. A treia formă adaugă o valoare --proxy goală, suprascriind proxy-ul cerut de mediu doar pentru acea invocare. Comparați prima încercare de conectare din fiecare ieșire, nu codul de stare final.

Ieșirea detaliată poate expune anteturi, tokenuri și acreditări de proxy, așa că păstrați-o local și citiți fragmente înainte de a o partaja.

Ce exclude fiecare rezultat

Dacă omiterea configurației implicite schimbă conexiunea, sursa este fișierul de configurare. Dacă dezactivarea explicită a proxy-ului moștenit o schimbă, sursa este variabila de mediu. Dacă niciuna nu o schimbă și localhost apare în continuare, verificați suprascrierile de conexiune din linia de comandă, rezolvarea numelor de gazdă și executabilul ales. Fiecare are o remediere diferită și niciuna nu este o modificare de rutare.

Încărcarea de biblioteci personalizate sau comportamentul de rețea injectat este un strat ulterior, iar o variabilă de mediu singură nu este dovada acestuia.

Țineți decizia privind proxy-ul separată de VPN

Odată ce curl alege o destinație directă, sistemul de operare rutează în continuare acea conexiune. Dezactivarea unui proxy de aplicație nu dezactivează ruta VPN-ului sau politica sa de filtrare. Faceți comparații de acces direct doar acolo unde acel diagnostic este autorizat. Un test care ocolește în tăcere politica nu este un rezultat valid, este un incident.

Dacă este necesar un proxy local, restabiliți serviciul și adresa acestuia în loc să-i ștergeți setările.

Dacă doar anumite destinații private au nevoie de acces direct, adăugați o excludere îngustă aprobată și păstrați proxy-ul pentru tot restul. Păstrați prima eroare de pe calea aleasă, deoarece o respingere de localhost, o respingere CONNECT a proxy-ului, o eroare de certificat și o eroare de autorizare indică patru etape diferite.