Wêrom ferbynt curl mei localhost ynstee fan de externe URL

As curl besiket om mei localhost te ferbinen, hokker URL jo ek jûn hawwe, is it VPN it ferkearde plak om te begjinnen. In lokaal HTTP- of SOCKS-proxy kin de bedoelde earste ferbining wêze, sels as de tsjinst dy't jo wolle earne oars is. As dat proxy net mear rint, mislearret de poging nei localhost foardat curl de bestimming berikt. In antwurd fan it proxy is ek gjin bewiis dat de bestimming antwurde.

Wurkkje dizze stappen yn folchoarder ôf en stopje by de earste dy't de earste ferbiningspoging feroaret.

Lês earst de proxy-regels fan curl sels

curl lêst protokolspezifike proxy-fariabelen, lykas https_proxy en HTTPS_PROXY, en ek ALL_PROXY as gjin protokolspezifike wearde jildt. Undersykje de omjouwing fan it shell, de tsjinst of de taak dy't curl eins start, net dy fan jo hjoeddeistige terminal. In CI-baan, in systemd-ienheid en in ynteraktive shell kinne trije ferskillende sets ervje. Krekt troch te rieden fan it sichtbere shell ferliest dit ûndersyk in hiel middei.

Ien útsûndering is it wurdich te ûnthâlden. curl akseptearret http_proxy allinnich yn lytse letters; haadletters HTTP_PROXY wurde negearre, en dêrom hâldt deselde omjouwing him oars yn oare ark.

Lês de wearden fertroulik, want in proxy-URL draacht faak bewizen fan identiteit.

Kontrolearje dan it standert curl-konfiguraasjebestân op proxy- of ferbinings-oerskriuwings, en befêstigje hokker útfierber bestân jo eins rinne litte. In shell-alias, in funksje of in wrapper-skript kin opsjes tafoegje dy't nea op jo kommando-rigel ferskine.

Fergelykje trije oproppen mei TLS oan

Brûk ien goedkarde diagnostyske bestimming en itselde binêre bestân foar alle trije runs.

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 ûnderdrukt it standert curlrc en moat de earste parameter op 'e rigel wêze om te wurkjen. It ferwideret gjin proxy-omjouwingsfariabelen, wat minsken ferrast dy't dat ferwachtsje. De tredde foarm foeget in lege --proxy-wearde ta en oerskriuwt in troch de omjouwing frege proxy allinnich foar dy oprop. Fergelykje de earste ferbiningspoging yn elke útfier, net de definitive statuskoade.

Utfierbere útfier kin headers, tokens en proxy-bewizen fan identiteit bleatlegge, dus hâld it lokaal en lês fragminten foardat jo it diele.

Wat elk resultaat útslút

As it weilitten fan 'e standertkonfiguraasje de ferbining feroaret, is it konfiguraasjebestân de boarne. As it eksplisyt útskeakeljen fan it erfde proxy dat docht, is de omjouwingsfariabele de boarne. As gjin fan beide it feroaret en localhost ferskynt noch, sjoch dan nei ferbinings-oerskriuwings op 'e kommando-rigel, hostnameresolúsje en it keazen útfierbere bestân. Elk hat in oare oplossing, en gjinien is in feroaring fan routing.

It laden fan oanpaste biblioteken of ynjektearre netwurkgedrach is in lettere laach, en in omjouwingsfariabele allinnich is dêr gjin bewiis fan.

Hâld de proxy-beslissing apart fan it VPN

Sadree't curl in direkte bestimming kiest, bliuwt it bestjoeringssysteem dy ferbining routearje. It útskeakeljen fan in applikaasjeproxy skeakelet de rûte fan it VPN of syn filterbelied net út. Doch allinnich direkte tagongsfergelykings wêr't dy diagnoaze autorisearre is. In test dy't stil it belied omgiet is gjin jildich resultaat, it is in ynsidint.

As in lokaal proxy fereaske is, herstel dan syn tsjinst en adres ynstee fan syn ynstellingen te wiskjen.

As allinnich selektearre privee-bestimmingen direkte tagong nedich hawwe, foegje dan in smelle goedkarde útsûndering ta en hâld it proxy foar al it oare. Bewarje de earste flater fan it keazen paad, want in localhost-wegering, in proxy CONNECT-wegering, in sertifikaatflater en in autorisaasjeflater wize fjouwer ferskillende fazen oan.