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 जान्ने र त्यसबारे अनुमान गर्नेबीचको फरक त्यही हो।