curl रिमोट URL के बजाय localhost से क्यों जुड़ता है

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

इन चरणों को क्रम में पूरा करें और पहले ऐसे चरण पर रुकें जो पहला कनेक्शन प्रयास बदलता है।

पहले curl के अपने proxy नियम पढ़ें

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

एक अपवाद याद रखने लायक है। curl http_proxy को केवल छोटे अक्षरों में स्वीकार करता है; बड़े अक्षरों वाला HTTP_PROXY अनदेखा किया जाता है, इसलिए वही वातावरण दूसरे उपकरणों में अलग व्यवहार करता है।

मानों को निजी तौर पर पढ़ें, क्योंकि proxy URL में अक्सर क्रेडेंशियल होते हैं।

फिर डिफ़ॉल्ट curl कॉन्फ़िगरेशन फ़ाइल में proxy या कनेक्शन के ओवरराइड जाँचें, और पुष्टि करें कि आप वास्तव में कौन-सी निष्पादन योग्य फ़ाइल चला रहे हैं। कोई 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 वातावरण चरों को नहीं हटाता, जो उन लोगों को चौंकाता है जो ठीक यही अपेक्षा करते हैं। तीसरा रूप एक खाली --proxy मान जोड़ता है, और केवल उसी आह्वान के लिए वातावरण द्वारा अनुरोधित proxy को ओवरराइड करता है। हर आउटपुट में पहला कनेक्शन प्रयास तुलना करें, अंतिम स्थिति कोड नहीं।

विस्तृत आउटपुट हेडर, टोकन और proxy क्रेडेंशियल उजागर कर सकता है, इसलिए इसे स्थानीय रखें और साझा करने से पहले अंश पढ़ें।

प्रत्येक परिणाम क्या बाहर करता है

अगर डिफ़ॉल्ट कॉन्फ़िगरेशन छोड़ देने से कनेक्शन बदलता है, तो स्रोत कॉन्फ़िगरेशन फ़ाइल है। अगर विरासत में मिले proxy को स्पष्ट रूप से बंद करने से यह बदलता है, तो स्रोत वातावरण चर है। अगर इनमें से कोई भी इसे नहीं बदलता और localhost फिर भी दिखता है, तो कमांड-लाइन कनेक्शन ओवरराइड, होस्टनाम रिज़ॉल्यूशन और चुनी गई निष्पादन योग्य फ़ाइल देखें। इनमें से हर एक का अलग समाधान है, और इनमें से कोई भी रूटिंग परिवर्तन नहीं है।

कस्टम लाइब्रेरी लोड होना या इंजेक्ट किया गया नेटवर्क व्यवहार बाद की परत है, और अकेला वातावरण चर इसका प्रमाण नहीं है।

proxy का निर्णय VPN से अलग रखें

एक बार curl सीधा गंतव्य चुन ले, तो ऑपरेटिंग सिस्टम अब भी उस कनेक्शन को रूट करता है। किसी ऐप्लिकेशन proxy को बंद करने से VPN का रूट या उसकी फ़िल्टरिंग नीति बंद नहीं होती। सीधे पहुँच की तुलना केवल वहीं करें जहाँ वह नैदानिकी अधिकृत हो। जो परीक्षण चुपचाप नीति को बायपास करता है वह मान्य परिणाम नहीं है, वह घटना है।

अगर स्थानीय proxy आवश्यक हो, तो उसकी सेटिंग्स मिटाने के बजाय उसकी सेवा और पता बहाल करें।

अगर केवल चुने हुए निजी गंतव्यों को सीधी पहुँच चाहिए, तो एक संकीर्ण स्वीकृत अपवाद जोड़ें और बाकी सबके लिए proxy रखें। चुने गए मार्ग की पहली त्रुटि सुरक्षित रखें, क्योंकि localhost का इनकार, proxy के CONNECT का अस्वीकार, प्रमाणपत्र विफलता और प्राधिकरण त्रुटि चार अलग चरणों की ओर संकेत करते हैं।