Ինչու curl-ը միանում է localhost-ին, այլ ոչ թե հեռավոր URL-ին
Առանձնացրեք ժառանգված պրոքսին, լռելյայն curlrc ֆայլը և իրական նպատակակետը՝ նախքան VPN-ին մեղադրելը։ Երեք վերահսկվող գործարկումները TLS ստուգումը միացված են պահում։
Եթե curl-ը փորձում է միանալ localhost-ին անկախ ձեր տված URL-ից, ապա VPN-ը սկսելու սխալ տեղ է. Տեղական HTTP կամ SOCKS պրոքսին կարող է լինել նախատեսված առաջին միացումը, նույնիսկ երբ ձեզ անհրաժեշտ ծառայությունը բոլորովին այլ տեղ է։ Եթե այդ պրոքսին այլևս չի աշխատում, localhost-ի փորձը ձախողվում է նախքան curl-ը կհասնի նպատակակետին։ Պրոքսիի պատասխանը նույնպես ապացույց չէ, որ նպատակակետը պատասխանել է։
Կատարեք այս քայլերը հերթականությամբ և կանգ առեք առաջինի վրա, որը փոխում է առաջին միացման փորձը։
Նախ կարդացեք հենց curl-ի պրոքսիի կանոնները
curl-ը կարդում է արձանագրությանը հատուկ պրոքսի փոփոխականներ, օրինակ՝ https_proxy և HTTPS_PROXY, ինչպես նաև ALL_PROXY, երբ արձանագրությանը հատուկ ոչ մի արժեք չի կիրառվում։ Ստուգեք այն shell-ի, ծառայության կամ առաջադրանքի միջավայրը, որն իրականում գործարկում է curl-ը, ոչ թե ձեր ընթացիկ տերմինալինը։ CI աշխատանքը, systemd միավորը և ինտերակտիվ shell-ը կարող են ժառանգել երեք տարբեր հավաքածու։ Հենց տեսանելի shell-ից գուշակելն է, ինչի պատճառով այս հետաքննությունը կորցնում է մի ամբողջ կեսօր։
Արժե հիշել մեկ բացառություն։ curl-ը http_proxy ընդունում է միայն փոքրատառերով. մեծատառ HTTP_PROXY անտեսվում է, և դրա համար նույն միջավայրը այլ գործիքներում այլ կերպ է վարվում։
Կարդացեք արժեքները գաղտնի, որովհետև պրոքսիի URL-ը հաճախ կրում է հավատարմագրեր։
Այնուհետև ստուգեք curl-ի լռելյայն կազմաձևման ֆայլը պրոքսիի կամ միացման վերագրանցումների համար և հաստատեք, թե որ գործարկվող ֆայլն եք իրականում աշխատեցնում։ Shell-ի այլանունը, ֆունկցիան կամ փաթաթող սկրիպտը կարող են ավելացնել ընտրանքներ, որոնք երբեք չեն երևում ձեր հրամանի տողում։
Համեմատեք երեք կանչ՝ TLS-ը միացված
Երեք գործարկումների համար օգտագործեք մեկ հաստատված ախտորոշիչ նպատակակետ և նույն բինար ֆայլը։
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 ճնշում է լռելյայն curlrc-ն և աշխատելու համար պետք է լինի տողի առաջին պարամետրը։ Այն չի հեռացնում պրոքսիի միջավայրի փոփոխականները, ինչը զարմացնում է նրանց, ովքեր հենց դա են սպասում։ Երրորդ ձևը ավելացնում է դատարկ --proxy արժեք՝ շրջանցելով միջավայրի պահանջած պրոքսին միայն այդ կանչի համար։ Համեմատեք առաջին միացման փորձը յուրաքանչյուր ելքի մեջ, ոչ թե վերջնական կարգավիճակի կոդը։
Մանրամասն ելքը կարող է բացահայտել վերնագրեր, նշաններ և պրոքսիի հավատարմագրեր, ուստի պահեք այն տեղական և կարդացեք հատվածներ նախքան կիսվելը։
Ինչ է բացառում յուրաքանչյուր արդյունք
Եթե լռելյայն կազմաձևը բաց թողնելը փոխում է միացումը, աղբյուրը կազմաձևման ֆայլն է։ Եթե ժառանգված պրոքսիի բացահայտ անջատումը փոխում է այն, աղբյուրը միջավայրի փոփոխականն է։ Եթե ոչ մեկը չի փոխում այն, և localhost-ը դեռ երևում է, նայեք հրամանի տողի միացման վերագրանցումներին, հոսթի անվան լուծմանը և ընտրված գործարկվող ֆայլին։ Դրանցից յուրաքանչյուրն ունի տարբեր ուղղում, և դրանցից ոչ մեկը երթուղու փոփոխություն չէ։
Մաքսային գրադարանի բեռնումը կամ ներարկված ցանցային վարքը ավելի ուշ շերտ է, և միայն միջավայրի փոփոխականը դրա ապացույցը չէ։
Պրոքսիի որոշումը պահեք VPN-ից առանձին
Երբ curl-ը ընտրում է ուղիղ նպատակակետ, օպերացիոն համակարգը դեռ երթուղավորում է այդ միացումը։ Հավելվածի պրոքսիի անջատումը չի անջատում VPN-ի երթուղին կամ դրա զտման քաղաքականությունը։ Ուղիղ հասանելիության համեմատություններ արեք միայն այնտեղ, որտեղ այդ ախտորոշումը թույլատրված է։ Թեստը, որ լուռ շրջանցում է քաղաքականությունը, վավեր արդյունք չէ, դա միջադեպ է։
Եթե տեղական պրոքսի է անհրաժեշտ, վերականգնեք դրա ծառայությունը և հասցեն՝ փոխարենը չջնջելով դրա կարգավորումները։
Եթե ուղիղ հասանելիություն անհրաժեշտ է միայն ընտրված մասնավոր նպատակակետերին, ավելացրեք նեղ հաստատված բացառություն և պահեք պրոքսին մնացած ամեն ինչի համար։ Պահպանեք ընտրված ուղու առաջին սխալը, որովհետև localhost-ի մերժումը, պրոքսիի CONNECT մերժումը, վկայագրի ձախողումը և լիազորման սխալը նշում են չորս տարբեր փուլեր։