curl आपकी PAC फ़ाइल नहीं पढ़ सकता: उसके बजाय proxy पास करें

कॉन्फ़िग फ़ाइल में PAC फ़ाइल का पता और proxy का एंडपॉइंट एक-दूसरे के बदले इस्तेमाल होने वाले लगते हैं, और वे नहीं हैं। एक नीति प्रोग्राम है जिसका मूल्यांकन हर URL के लिए करना पड़ता है; दूसरा एक होस्ट और पोर्ट है जो कनेक्शन स्वीकार करता है। curl केवल दूसरे को समझता है। PAC पता --proxy को पास करना एक श्रेणी की गलती है जो भ्रमित करने वाले तरीके से विफल होती है, आमतौर पर किसी वेब सर्वर तक लंबे CONNECT टाइमआउट के बाद।

हर एक वास्तव में क्या है

यह स्पष्ट कहता है curl के अक्सर पूछे जाने वाले प्रश्न: curl JavaScript या PAC की कोई व्याख्या नहीं देता। curl के चारों ओर एक PAC-समझदार रैपर ऐसा कर सकता है, पर curl स्वयं नहीं, और कोई फ़्लैग इसे ब्राउज़र नहीं बनाता।

ब्राउज़र क्यों काम करता है और curl क्यों नहीं

ब्राउज़र सिस्टम की proxy कॉन्फ़िगरेशन के साथ एकीकृत होता है, PAC फ़ाइल लाता है और आपके द्वारा खोले जा रहे URL के विरुद्ध उसके नियम चलाता है। वही मूल्यांकन PAC फ़ाइल की सेवा है, और वह ब्राउज़र के अंदर होता है, आपके टर्मिनल के अंदर नहीं।

PAC फ़ाइल को curl से डाउनलोड करने पर केवल उसका टेक्स्ट मिलता है। इससे 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 को जानने तथा उसके बारे में अनुमान लगाने के बीच यही अंतर है।