Kial curl konektiĝas al localhost anstataŭ al la fora URL

Se curl provas konektiĝi al localhost sendepende de la URL, kiun vi donis, la VPN estas la malĝusta loko por komenci. Loka HTTP aŭ SOCKS prokurilo povas esti la intencita unua konekto, eĉ kiam la servo, kiun vi volas, troviĝas tute aliloke. Se tiu prokurilo jam ne funkcias, la provo al localhost malsukcesas antaŭ ol curl eĉ atingas la celon. Ankaŭ respondo de prokurilo ne pruvas, ke la celo respondis.

Trairu ĉi tiujn paŝojn en ordo kaj haltu ĉe la unua, kiu ŝanĝas la unuan konekpropon.

Unue legu la proprajn prokurilajn regulojn de curl

curl legas protokol-specifajn prokurilajn variablojn, kiel https_proxy kaj HTTPS_PROXY, kaj ankaŭ ALL_PROXY, kiam neniu protokol-specifa valoro validas. Kontrolu la medion de la ŝelo, servo aŭ tasko, kiu vere lanĉas curl, ne tiun en via nuna terminalo. CI-tasko, systemd-unuo kaj interaga ŝelo povas heredi tri malsamajn arojn. Ĝuste diveni laŭ la videbla ŝelo estas kiel ĉi tiu esploro perdas tutan posttagmezon.

Unu escepto indas esti memorata. curl akceptas http_proxy nur per minuskloj; majuskla HTTP_PROXY estas ignorata, kaj tial la sama medio kondutas malsame en aliaj iloj.

Legu la valorojn private, ĉar prokurila URL ofte portas akreditaĵojn.

Poste kontrolu la defaŭltan konfiguran dosieron de curl pri prokurilaj aŭ konektaj anstataŭigoj, kaj konfirmu, kiun plenumeblon vi vere rulas. Ŝela alinomo, funkcio aŭ ĉirkaŭa skripto povas aldoni opciojn, kiuj neniam aperas en via komandlinio.

Komparu tri alvokojn kun TLS ŝaltita

Uzu unu aprobitan diagnozan celon kaj la saman binaran dosieron por ĉiuj tri ruloj.

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 subpremas la defaŭltan curlrc kaj devas esti la unua parametro en la linio por funkcii. Ĝi ne forigas prokurilajn medivariablojn, kio surprizas homojn, kiuj tion atendas. La tria formo aldonas malplenan --proxy-valoron, anstataŭigante medipetitan prokurilon nur por tiu alvoko. Komparu la unuan konekpropon en ĉiu eligo, ne la finan statuskodon.

Detala eligo povas malkaŝi kapojn, ĵetonojn kaj prokurilajn akreditaĵojn, do tenu ĝin loke kaj legu eltiraĵojn antaŭ ol dividi ĝin.

Kion ĉiu rezulto ekskludas

Se preterlasi la defaŭltan agordon ŝanĝas la konekton, la konfigura dosiero estas la fonto. Se eksplicite malŝalti la hereditan prokurilon ŝanĝas ĝin, la medivariablo estas la fonto. Se nek unu nek la alia ŝanĝas ĝin kaj localhost ankoraŭ aperas, rigardu komandliniajn konektajn anstataŭigojn, gastignoman solvon kaj la elektitan plenumeblon. Ĉiu el ili havas malsaman riparon, kaj neniu el ili estas ŝanĝo de enkursigo.

Ŝarĝado de propraj bibliotekoj aŭ enĵetita reta konduto estas posta tavolo, kaj medivariablo sola ne estas pruvo pri ĝi.

Tenu la prokurilan decidon aparte de la VPN

Post kiam curl elektas rektan celon, la operaciumo ankoraŭ enkursigas tiun konekton. Malŝalti aplikaĵan prokurilon ne malŝaltas la itineron de la VPN aŭ ĝian filtradan politikon. Faru rektalirajn komparojn nur tie, kie tiu diagnostiko estas rajtigita. Testo, kiu silente preterpasas politikon, ne estas valida rezulto, ĝi estas incidento.

Se loka prokurilo necesas, restarigu ĝian servon kaj adreson anstataŭ forigi ĝiajn agordojn.

Se nur elektitaj privataj celoj bezonas rektan aliron, aldonu mallarĝan aprobitan escepton kaj konservu la prokurilon por ĉio alia. Konservu la unuan eraron de la elektita vojo, ĉar rifuzo de localhost, malakcepto de prokura CONNECT, atestila malsukceso kaj rajtiga eraro indikas kvar malsamajn etapojn.