curl रिमोट URL को सट्टा localhost मा किन जोडिन्छ

तपाईंले दिनुभएको URL लाई वास्ता नगरी curl localhost मा जोडिन खोज्छ भने, VPN सुरु गर्ने गलत ठाउँ हो. स्थानीय HTTP वा SOCKS प्रोक्सी नै अभिप्रेत पहिलो जडान हुन सक्छ, तपाईंलाई चाहिने सेवा पूर्ण रूपमा अन्तै भए पनि। त्यो प्रोक्सी अब चलिरहेको छैन भने, curl गन्तव्यमा पुग्नुअघि नै localhost को प्रयास असफल हुन्छ। प्रोक्सीको जवाफ पनि गन्तव्यले जवाफ दिएको प्रमाण होइन।

यी चरणहरू क्रममा गर्नुहोस् र पहिलो जडान प्रयास बदल्ने पहिलो चरणमा रोक्नुहोस्।

पहिले curl का आफ्नै प्रोक्सी नियमहरू पढ्नुहोस्

curl प्रोटोकल-विशिष्ट प्रोक्सी भेरिएबलहरू पढ्छ, जस्तै https_proxy र HTTPS_PROXY, साथै प्रोटोकल-विशिष्ट मान लागू नहुँदा ALL_PROXY. curl लाई वास्तवमा सुरु गर्ने शेल, सेवा वा कार्यको वातावरण जाँच्नुहोस्, तपाईंको हालको टर्मिनलको होइन। एउटा CI कार्य, systemd इकाई र अन्तरक्रियात्मक शेलले तीन फरक सेटहरू वंशानुगत रूपमा पाउन सक्छन्। देखिने शेलबाट अनुमान गर्नु नै यो जाँचले पूरै दिउँसो बर्बाद गर्ने कारण हो।

एउटा अपवाद सम्झन लायक छ। curl ले http_proxy लाई साना अक्षरमा मात्र स्वीकार्छ; ठूला अक्षरको HTTP_PROXY लाई बेवास्ता गरिन्छ, त्यसैले एउटै वातावरण अन्य उपकरणमा फरक व्यवहार गर्छ।

मानहरू गोप्य रूपमा पढ्नुहोस्, किनकि प्रोक्सी URL मा प्रायः प्रमाणहरू हुन्छन्।

त्यसपछि पूर्वनिर्धारित curl कन्फिगरेसन फाइलमा प्रोक्सी वा जडान ओभरराइडहरू जाँच्नुहोस्, र तपाईंले वास्तवमा कुन कार्यान्वयनयोग्य फाइल चलाइरहनुभएको छ पुष्टि गर्नुहोस्। शेल उपनाम, फंक्शन वा र्यापर स्क्रिप्टले तपाईंको आदेश लाइनमा कहिल्यै नदेखिने विकल्पहरू थप्न सक्छ।

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 को अस्वीकार, प्रमाणपत्र असफलता र अधिकार त्रुटिले चार फरक चरणहरू देखाउँछन्।