curl तुमची PAC फाईल वाचू शकत नाही: त्याऐवजी proxy पास करा

कॉन्फिग फाईलमध्ये PAC फाईलचा पत्ता आणि proxy चा एंडपॉइंट परस्पर बदलण्यायोग्य वाटतात, पण तसे नाही. एक धोरण कार्यक्रम आहे जो प्रत्येक URL साठी मूल्यांकन करावा लागतो; दुसरा कनेक्शन स्वीकारणारा होस्ट आणि पोर्ट आहे. curl फक्त दुसरा समजतो. PAC पत्ता --proxy ला पास करणे ही श्रेणीची चूक आहे जी गोंधळात टाकणाऱ्या पद्धतीने अयशस्वी होते, सामान्यतः वेब सर्व्हरकडे दीर्घ CONNECT कालबाह्यतेनंतर.

प्रत्येक प्रत्यक्षात काय आहे

हे स्पष्टपणे सांगते curl बद्दलचे वारंवार विचारले जाणारे प्रश्न: curl JavaScript किंवा PAC चे कोणतेही अर्थविवेचन देत नाही. curl भोवतीचे PAC समजणारे आवरण हे करू शकते, पण curl स्वतः नाही, आणि कोणतेही फ्लॅग त्याला ब्राउझर बनवत नाही.

ब्राउझर का चालतो आणि curl का नाही

ब्राउझर सिस्टमच्या proxy कॉन्फिगरेशनशी एकत्र येतो, PAC फाईल आणतो आणि तुम्ही उघडत असलेल्या URL विरुद्ध तिचे नियम चालवतो. तेच मूल्यांकन PAC फाईल देत असलेली सेवा आहे, आणि ते तुमच्या टर्मिनलमध्ये नाही, ब्राउझरच्या आत घडते.

curl ने PAC फाईल डाउनलोड केल्यास फक्त तिचा मजकूर मिळतो. त्यामुळे curl धोरणाची अंमलबजावणी करत नाही, आणि proxy शोधण्यासाठी ती हाताने वाचणे हे त्याच मूल्यांकनाचे हाताने केलेले स्वरूप आहे, चुकीची शाखा निवडण्याची तितकीच शक्यता. तुम्ही वाचत असाल, तर फाईलमधील पहिल्या proxy नावाऐवजी तुमच्या होस्टशी जुळणारे return विधान वाचा. बहुतेक PAC फाईलमध्ये अनेक असतात, आणि तुम्हाला लागू होणारी शाखा एकच असते.

मंजूर HTTP proxy आणि मंजूर HTTPS सेवेसाठी, एक उदाहरण विनंती अशी आहे:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

पहिला पत्ता proxy चा श्रोता आहे, दुसरा तुम्हाला हवी असलेली सेवा आहे. हे उदाहरण एंडपॉइंट आहेत, कोणी केलेली चाचणी नाही, म्हणून ते तुमच्या संस्थेच्या स्कीम, पोर्ट आणि प्रमाणीकरण प्रवाहाने बदला.

या गंतव्यासाठी proxy निवडा

व्यवस्थापकाला विचारा की धोरण तुम्हाला आवश्यक असलेल्या URL साठी कोणता proxy निवडते, संस्थेकडे कोणता proxy आहे हे नव्हे. PAC नियम अंतर्गत सेवा, सार्वजनिक साइट्स आणि अपयश-स्विचिंग स्थितींसाठी वेगवेगळे निकाल देऊ शकतात, आणि आज तुमच्या URL शी जुळणारा नियम संपादनानंतर दुसऱ्याशी जुळू शकतो.

कार्यप्रवाहाला एकापेक्षा जास्त ज्ञात विनंत्या हव्या असल्यास, व्यवस्थापक-समर्थित स्थिर सेटिंग किंवा मंजूर PAC-समज असलेले एकत्रीकरण वापरा. एक कॉपी केलेला पत्ता हार्डकोड करणे धोरण बदलेपर्यंत आणि तो पत्ता का निवडला हे कोणालाही आठवत नाही तोपर्यंत चालते.

मग curl काय वारसाहक्काने घेतो ते पहा. proxy पर्यावरण चल आणि NO_PROXY तुम्ही पास केलेला proxy ओव्हरराइड करू शकतात किंवा वगळू शकतात, आणि तुमच्या लक्ष्याशी जुळणारे वगळणे विनंती गपचूप थेट पाठवते. प्रत्येक वगळणे पुसण्याऐवजी किंवा सर्वकाही एका पत्त्यातून जबरदस्ती करण्याऐवजी इच्छित धोरण टिकवा. विनंती एकदा -v सह चालवा आणि ती प्रत्यक्षात कोणत्या पत्त्याशी जोडली गेली ते तपासा.

दोन TLS ओळखी वेगळ्या ठेवा

HTTPS proxy सह, दोन TLS कनेक्शन कार्यरत आहेत: तुमचे proxy कडे आणि proxy चे गंतव्याकडे. प्रत्येकाकडे तपासण्यासाठी स्वतःची ओळख आहे, आणि यापैकी कोणत्याही एकासाठी तपासणी बंद करणे हे PAC दुरुस्ती नाही, पहिल्या समस्येत जोडलेली दुसरी समस्या आहे.

तपासणी सुरू ठेवा आणि मिळणारे अपयश वाचा. proxy प्रमाणीकरण आव्हान, पोहोचू न शकणारा proxy आणि वेबसाइटचा नकार हे तीन वेगळे निकाल आहेत, आणि फक्त पहिला क्रेडेन्शियल्सशी संबंधित आहे. VPN ला अजूनही खाजगी proxy पर्यंत परवानगी असलेला मार्ग द्यावा लागतो, proxy होस्टसाठी नाव विश्लेषणासह, यापैकी काहीही यशस्वी होण्यापूर्वी.

एंडपॉइंट, स्कीम, पोर्ट, प्रमाणीकरण पद्धत, वगळणी आणि proxy पर्यंतचा VPN मार्ग लिहून ठेवा. तेच नोंद पुढील विनंती पुनरुत्पादनीय करते, आणि तुमचा proxy जाणणे व त्याबद्दल अंदाज लावणे यातील फरक तोच आहे.