Proč se curl připojuje na localhost místo vzdáleného URL

Pokud se curl pokouší připojit na localhost bez ohledu na URL, kterou jste zadali, VPN je špatné místo, kde začít. Místní proxy HTTP nebo SOCKS může být zamýšleným prvním spojením, i když je služba, kterou chcete, úplně jinde. Pokud tato proxy už neběží, pokus o localhost selže dřív, než se curl vůbec dostane k cíli. Odpověď proxy také není důkazem, že cíl odpověděl.

Projděte tyto kroky v pořadí a zastavte se u prvního, který změní první pokus o spojení.

Nejprve si přečtěte vlastní pravidla proxy v curl

curl čte proměnné proxy specifické pro protokol, například https_proxy a HTTPS_PROXY, a také ALL_PROXY, když se neuplatní žádná hodnota specifická pro protokol. Zkontrolujte prostředí shellu, služby nebo úlohy, která curl skutečně spouští, ne toho ve vašem aktuálním terminálu. Úloha CI, jednotka systemd a interaktivní shell mohou zdědit tři různé sady. Právě hádání podle viditelného shellu je důvod, proč tento průzkum ztratí celé odpoledne.

Jednu výjimku stojí za to si zapamatovat. curl přijímá http_proxy pouze malými písmeny; verze velkými písmeny HTTP_PROXY se ignoruje, a proto se stejné prostředí chová v jiných nástrojích jinak.

Čtěte hodnoty soukromě, protože URL proxy často nese přihlašovací údaje.

Poté zkontrolujte výchozí konfigurační soubor curl, zda neobsahuje přepisy proxy nebo připojení, a ověřte, který spustitelný soubor vlastně spouštíte. Alias shellu, funkce nebo obalový skript může přidat volby, které se na vašem příkazovém řádku nikdy neobjeví.

Porovnejte tři volání se zapnutým TLS

Použijte jeden schválený diagnostický cíl a stejný binární soubor pro všechny tři běhy.

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 potlačuje výchozí curlrc a aby fungoval, musí být prvním parametrem na řádku. Neodstraňuje proměnné prostředí proxy, což překvapuje lidi, kteří to očekávají. Třetí forma přidává prázdnou hodnotu --proxy, čímž pro toto volání přepisuje proxy vyžádanou prostředím. Porovnávejte první pokus o spojení v každém výstupu, nikoli konečný stavový kód.

Podrobný výstup může odhalit hlavičky, tokeny a přihlašovací údaje proxy, proto jej uchovávejte lokálně a před sdílením si přečtěte výňatky.

Co který výsledek vylučuje

Pokud vynechání výchozí konfigurace změní spojení, je zdrojem konfigurační soubor. Pokud jej změní výslovné vypnutí zděděné proxy, je zdrojem proměnná prostředí. Pokud nezmění ani jedno a localhost se stále objevuje, podívejte se na přepisy připojení na příkazovém řádku, překlad názvů hostitelů a zvolený spustitelný soubor. Každé z toho má jinou opravu a žádné z nich není změnou směrování.

Načítání vlastních knihoven nebo injektované chování sítě je pozdější vrstva a samotná proměnná prostředí není jeho důkazem.

Držte rozhodnutí o proxy oddělené od VPN

Jakmile curl zvolí přímý cíl, operační systém toto spojení stále směruje. Vypnutí proxy aplikace nevypíná trasu VPN ani její politiku filtrování. Srovnání přímého přístupu provádějte jen tam, kde je taková diagnostika povolena. Test, který tiše obchází politiku, není platný výsledek, je to incident.

Pokud je místní proxy nutná, obnovte její službu a adresu, místo abyste mazali její nastavení.

Pokud přímý přístup potřebují jen vybrané soukromé cíle, přidejte úzkou schválenou výjimku a proxy ponechte pro vše ostatní. Zachovejte první chybu ze zvolené cesty, protože odmítnutí localhost, odmítnutí CONNECT proxy, selhání certifikátu a chyba autorizace označují čtyři různé fáze.