Waarom curl aan localhost koppel in plaas van die afgeleë URL

As curl probeer om aan localhost te koppel ongeag die URL wat jy gegee het, is die VPN die verkeerde plek om te begin. 'n Plaaslike HTTP- of SOCKS-proxy kan die bedoelde eerste verbinding wees, selfs wanneer die diens wat jy wil hê heeltemal elders is. As daardie proxy nie meer loop nie, misluk die localhost-poging voordat curl ooit die bestemming bereik. 'n Proxy-antwoord is ook nie bewys dat die bestemming geantwoord het nie.

Werk hierdie stappe in volgorde deur en stop by die eerste een wat die eerste verbindingspoging verander.

Lees curl se eie proxy-reëls eerste

curl lees protokolspesifieke proxy-veranderlikes soos https_proxy en HTTPS_PROXY, plus ALL_PROXY wanneer geen protokolspesifieke waarde van toepassing is nie. Ondersoek die omgewing van die dop, diens of taak wat curl werklik begin, nie dié in jou huidige terminaal nie. 'n CI-werk, 'n systemd-eenheid en 'n interaktiewe dop kan drie verskillende stelle erwe. Om uit die sigbare dop te raai, is hoe hierdie ondersoek 'n middag mors.

Een uitsondering is die moeite werd om te memoriseer. curl aanvaar http_proxy slegs in kleinletters; hoofletter HTTP_PROXY word geïgnoreer, en daarom gedra dieselfde omgewing hom anders in ander gereedskap.

Lees die waardes privaat, want 'n proxy-URL dra dikwels geloofsbriewe.

Kontroleer dan die verstek curl-konfigurasielêer vir proxy- of verbindings-oorheersings, en bevestig watter uitvoerbare lêer jy werklik hardloop. 'n Dop-alias, 'n funksie of 'n wrapper-skrip kan opsies byvoeg wat nooit op jou opdraglyn verskyn nie.

Vergelyk drie aanroepe met TLS aan

Gebruik een goedgekeurde diagnostiese bestemming en dieselfde binêre lêer vir al drie lopies.

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 onderdruk die verstek curlrc en moet die eerste parameter op die lyn wees om te werk. Dit verwyder nie proxy-omgewingsveranderlikes nie, wat mense verras wat verwag dat dit wel so is. Die derde vorm voeg 'n leë --proxy-waarde by en oorheers slegs vir daardie aanroep 'n proxy wat deur die omgewing versoek is. Vergelyk die eerste verbindingspoging in elke uitset, nie die finale statuskode nie.

Uitgebreide uitset kan koptekste, tokens en proxy-geloofsbriewe blootlê, so hou dit plaaslik en lees uittreksels voordat jy dit deel.

Wat elke resultaat uitsluit

As die weglating van die verstekkonfigurasie die verbinding verander, is die konfigurasielêer die bron. As die eksplisiete deaktivering van die geërfde proxy dit verander, is die omgewingsveranderlike die bron. As nie een dit verander nie en localhost verskyn steeds, kyk na verbindings-oorheersings op die opdraglyn, gasheernaamoplossing en die gekose uitvoerbare lêer. Elkeen daarvan het 'n ander regstelling, en nie een van hulle is 'n roeteverandering nie.

Pasgemaakte biblioteeklaai of ingevoegde netwerkgedrag is 'n latere laag, en 'n omgewingsveranderlike alleen is nie bewys daarvan nie.

Hou die proxy-besluit apart van die VPN

Sodra curl 'n direkte bestemming kies, roeteer die bedryfstelsel steeds daardie verbinding. Om 'n toepassingsproxy te deaktiveer, deaktiveer nie die VPN se roete of sy filterbeleid nie. Doen direkte-toegang-vergelykings net waar daardie diagnostiek gemagtig is. 'n Toets wat stilweg beleid omseil, is nie 'n geldige resultaat nie, dit is 'n voorval.

As 'n plaaslike proxy vereis word, herstel sy diens en adres eerder as om sy instellings te verwyder.

As slegs geselekteerde private bestemmings direkte toegang nodig het, voeg 'n noue goedgekeurde uitsluiting by en hou die proxy vir alles anders. Bewaar die eerste fout van die gekose pad, want 'n localhost-weiering, 'n proxy CONNECT-verwerping, 'n sertifikaatfout en 'n magtigingsfout dui vier verskillende stadia aan.