Miért csatlakozik a curl localhostra a távoli URL helyett

Ha a curl a megadott URL-től függetlenül localhostra próbál csatlakozni, a VPN a rossz kiindulópont. Egy helyi HTTP- vagy SOCKS-proxy lehet a szándékolt első kapcsolat, még akkor is, ha a kívánt szolgáltatás egészen máshol található. Ha ez a proxy már nem fut, a localhost felé tett kísérlet még azelőtt meghiúsul, hogy a curl egyáltalán elérné a célt. A proxy válasza sem bizonyítja, hogy a cél válaszolt.

Haladjon végig ezeken a lépéseken sorrendben, és álljon meg az elsőnél, amely megváltoztatja az első kapcsolódási kísérletet.

Először a curl saját proxy-szabályait olvassa el

A curl protokollspecifikus proxy-változókat olvas, például https_proxy és HTTPS_PROXY, valamint ALL_PROXY, ha egyetlen protokollspecifikus érték sem érvényes. Azt a shellt, szolgáltatást vagy feladatot vizsgálja meg, amely valójában elindítja a curlt, nem a jelenlegi terminálét. Egy CI-feladat, egy systemd-egység és egy interaktív shell három különböző készletet örökölhet. Éppen a látható shellből való találgatás az, amitől ez a vizsgálat egy egész délutánt elpazarol.

Egy kivételt érdemes megjegyezni. A curl a http_proxy csak kisbetűvel fogadja el; a nagybetűs HTTP_PROXY figyelmen kívül marad, ezért ugyanaz a környezet másként viselkedik más eszközökben.

Az értékeket bizalmasan olvassa, mert a proxy URL gyakran hitelesítő adatokat hordoz.

Ezután ellenőrizze a curl alapértelmezett konfigurációs fájlját proxy- vagy kapcsolatfelülírások után, és erősítse meg, melyik végrehajtható fájlt futtatja valójában. Egy shell-alias, egy függvény vagy egy burkolószkript olyan kapcsolókat adhat hozzá, amelyek soha nem jelennek meg a parancssorban.

Hasonlítson össze három hívást bekapcsolt TLS-sel

Használjon egy jóváhagyott diagnosztikai célt és ugyanazt a bináris fájlt mindhárom futáshoz.

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 elnyomja az alapértelmezett curlrc fájlt, és a működéshez a sor első paraméterének kell lennie. Nem távolítja el a proxy környezeti változóit, ami azokat lepi meg, akik éppen ezt várják. A harmadik forma egy üres --proxy értéket ad hozzá, és csak erre a hívásra írja felül a környezet által kért proxyt. Minden kimenetben az első kapcsolódási kísérletet hasonlítsa össze, nem a végső állapotkódot.

A részletes kimenet fejléceket, tokeneket és proxy-hitelesítő adatokat tehet közzé, ezért tartsa helyben, és megosztás előtt olvasson részleteket.

Mit zár ki az egyes eredmények

Ha az alapértelmezett konfiguráció elhagyása megváltoztatja a kapcsolatot, a forrás a konfigurációs fájl. Ha az örökölt proxy kifejezett letiltása változtat rajta, a forrás a környezeti változó. Ha egyik sem változtat rajta, és a localhost továbbra is megjelenik, nézze meg a parancssori kapcsolatfelülírásokat, a hosztnév-feloldást és a kiválasztott végrehajtható fájlt. Mindegyiknek más a javítása, és egyik sem útvonalváltoztatás.

Az egyéni könyvtárbetöltés vagy a befecskendezett hálózati viselkedés későbbi réteg, és egy környezeti változó önmagában nem bizonyíték rá.

Tartsa a proxy döntését külön a VPN-től

Amint a curl közvetlen célt választ, az operációs rendszer továbbra is irányítja azt a kapcsolatot. Egy alkalmazásproxy letiltása nem tiltja le a VPN útvonalát vagy szűrési szabályzatát. Közvetlen hozzáférési összehasonlításokat csak ott végezzen, ahol ez a diagnosztika engedélyezett. Az a teszt, amely csendben megkerüli a szabályzatot, nem érvényes eredmény, hanem incidens.

Ha helyi proxyra van szükség, állítsa helyre a szolgáltatását és címét ahelyett, hogy törölné a beállításait.

Ha csak bizonyos privát céloknak van szükségük közvetlen hozzáférésre, adjon hozzá egy szűk, jóváhagyott kivételt, és tartsa meg a proxyt minden másra. Őrizze meg a választott útvonal első hibáját, mert a localhost elutasítása, a proxy CONNECT elutasítása, a tanúsítványhiba és az engedélyezési hiba négy különböző szakaszt jelöl.