खाजगी API वर Requests ProxyError? आधी वातावरण तपासा

VPN सुरू आहे, अंतर्गत डॅशबोर्ड ब्राउझरमध्ये उघडतो, आणि Python स्क्रिप्ट अजूनही प्रॉक्सी त्रुटी देते। त्या चित्रात बोगद्यात काहीही चुकलेले नाही: इंटरप्रिटर स्वतःच्या वातावरणातून प्रॉक्सी पत्ता वाचतो आणि विनंती तिथे पाठवतो। हे मार्गदर्शक प्रक्रिया प्रत्यक्षात जे वातावरण पाहते ते वाचते, सर्वात अरुंद वगळणूक लागू करते आणि त्यानंतरच स्पष्ट सत्र धोरण विचारात घेते। प्रत्येक पायरी अशा आदेशाने संपते ज्याचा आउटपुट पुढे जायचे की नाही हे ठरवते।

प्रक्रिया प्रत्यक्षात जे वातावरण पाहते ते वाचा

डेस्कटॉप प्रॉक्सी सेटिंग्ज, shell निर्यात आणि systemd युनिटच्या Environment= ओळी या तीन वेगळे स्रोत आहेत, आणि Requests फक्त शेवटचा वारसाहक्काने मिळालेला स्रोत वाचते। खालील निदान त्या shell, कंटेनर किंवा युनिटमध्ये चालवा जे अपयशी स्क्रिप्ट चालवते, तुमच्या इंटरॅक्टिव्ह टर्मिनलमध्ये नाही। तुमच्या लॉगिन shell मध्ये निर्यात केलेला व्हेरिएबल कंटेनर प्रक्रियेला अदृश्य असतो, आणि हेच अंतर कुठूनही अचानक दिसणाऱ्या प्रॉक्सीबद्दलच्या अनेक तक्रारी समजावून सांगते। दोन्ही आदेश तोच डेटा वेगळ्या तपशील पातळीवर छापतात।

env | grep -i -E 'proxy|requests_ca_bundle|curl_ca_bundle'
python3 -c "import os;[print(k,'=',v) for k,v in sorted(os.environ.items()) if 'proxy' in k.lower()]"

प्रत्येक व्हेरिएबलचे दोन्ही शब्दलेखन वाचले जातात, आणि डुप्लिकेट नोंदी प्रक्रियेला त्या मिळाल्या त्या क्रमाने लागू होतात, त्यामुळे जुना HTTP_PROXY नुकतेच निर्यात केलेले मूल्य मागे टाकू शकतो। CA-बंडल व्हेरिएबल्स इथेही महत्त्वाचे आहेत, कारण ते कोडमध्ये कुठेही न दिसता verify कशात विरघळते ते बदलतात। आउटपुट रिकामे असल्यास वातावरण तुमची समस्या नाही आणि हा विभाग वाचणे थांबवू शकता। जर ते तुम्हाला माहीत नसलेली प्रॉक्सी सूचीबद्ध करत असेल, तर काहीही बदलण्यापूर्वी ती सेट करणारी फाइल किंवा युनिट शोधा।

विशिष्ट URL सह Requests काय करेल ते विचारा। हा कॉल पॅकेट न पाठवता त्या विनंतीसाठी एकत्रित प्रॉक्सी, verify आणि cert मूल्ये दाखवतो।

python3 -c "import requests;s=requests.Session();print(s.merge_environment_settings('https://api.corp.example/status',{},None,None,None))"

खाजगी होस्टसाठी रिकामी नसलेली proxies नोंद हे तुमचे उत्तर आहे, आणि छापलेले verify मूल्य विनंती कोणत्या CA-बंडलवर विश्वास ठेवेल ते सांगते। दोन्ही बरोबर वाटत असल्यास अपयश स्टॅकमध्ये पुढे आहे आणि तुम्ही पडताळणी विभागाकडे जावे। कोडवरून अंदाज लावू नका: एकत्रीकरण प्रत्येक विनंतीसाठी होते, म्हणूनच एक सत्र दोन होस्टसाठी वेगळे वागू शकते।

काहीही अक्षम करण्यापूर्वी खाजगी होस्ट वगळा

इतर गंतव्यांसाठी प्रॉक्सी खरोखर आवश्यक असल्यास, अरुंद उपाय म्हणजे या होस्टसाठी वगळणूक। विद्यमान यादीत जोडा, ती बदलू नका, कारण NO_PROXY पुसल्यास त्यावर अवलंबून असलेले इतर सर्व अंतर्गत गंतव्य तुटते। खालील आदेश नोंद जोडतात आणि नंतर Requests ला विचारतात की बायपास लागू होतो का।

export NO_PROXY="${NO_PROXY:+$NO_PROXY,}api.corp.example,.corp.example"
python3 -c "import requests;print(requests.utils.should_bypass_proxies('https://api.corp.example/status',None))"

जुळणी होस्ट प्रत्ययानुसार होते, त्यामुळे .corp.example संपूर्ण डोमेन व्यापते तर api.corp.example एक नाव व्यापते। रिकामे तारकेचिन्ह प्रत्येक होस्टसाठी प्रॉक्सी बंद करते आणि उत्पादन कार्य असे जवळपास कधीही इच्छित नाही। CIDR नोंद मानली जाईल का हे इमेजमधील Requests आणि urllib3 आवृत्त्यांवर अवलंबून आहे, म्हणून चालते असे गृहीत धरण्याऐवजी नेमकी नोंद तपासा। should_bypass_proxies चा निकाल खऱ्या URL साठी तपासा, स्मरणातून टाइप केलेल्या होस्टनावासाठी नाही।

दोन्ही स्तर मनात वेगळे ठेवा। HTTP प्रॉक्सी बायपास केल्याने VPN बायपास होत नाही, कारण प्रॉक्सीचा निर्णय लायब्ररीत आणि बोगद्याचा निर्णय कर्नेलच्या राउटिंग टेबलमध्ये होतो।

trust_env फक्त जाणीवपूर्वक सत्र धोरण म्हणूनच अक्षम करा

संपूर्ण कार्याने सभोवतालचे कॉन्फिगरेशन दुर्लक्षित करायचे असल्यास, सत्र स्पष्टपणे तयार करा आणि निर्णय कोडमध्ये नोंदवा। हे धोरण आहे, उपाय नाही, आणि ते पुनरावलोकनकर्त्याला दिसणाऱ्या diff मध्ये असावे। खालील उदाहरण टाइमआउट, स्पष्ट CA मार्ग आणि स्थिती तपासणी ठेवते।

import requests

with requests.Session() as session:
    session.trust_env = False
    response = session.get(
        "https://api.corp.example/status",
        timeout=(5, 20),
        verify="/etc/ssl/certs/corp-ca.pem",
    )
    response.raise_for_status()

trust_env बंद केल्याने एकाच वेळी तीन वर्तन बदलतात, आणि त्यातील फक्त एक प्रॉक्सीशी संबंधित आहे। Requests .netrc क्रेडेन्शियल्स वाचणे थांबवते, आणि REQUESTS_CA_BUNDLE व CURL_CA_BUNDLE व्हेरिएबल्स verify वर परिणाम करणे थांबवतात, जे नंतर सोबतच्या प्रमाणपत्र संग्रहाकडे परत जाते। तुमची संस्था स्वतःच्या CA ने TLS संपवत असेल, तर तो फॉलबॅक आत्ताच केलेल्या बदलाशी असंबंधित वाटणारी पडताळणी त्रुटी उठवतो। verify स्पष्टपणे पाठवणे हेच दोन परिणाम वेगळे ठेवते।

जे करू नये ते म्हणजे परिणामी त्रुटी शांत करण्यासाठी verify=False सेट करणे। यामुळे प्रॉक्सीची चुकीची संरचना न तपासलेल्या जोडणीशी बदलली जाते आणि वगळणीने उघड करायची असलेली प्रमाणपत्र समस्या लपते।

अपयशी स्तर पडताळा आणि मागे फिरण्याची क्षमता ठेवा

तीन अपयश लॉगमध्ये सारखी दिसतात आणि त्यांच्यात काहीही साम्य नाही: गंतव्य गाठू न शकणारी प्रॉक्सी ProxyError फेकते किंवा 502 परत करते, विश्वासाची समस्या SSLError फेकते, आणि अनुप्रयोगाचा नकार 401 किंवा 403 परत करतो। तुमच्याकडे कोणते आहे हे पाहण्यासाठी विनंती Requests बाहेर पुन्हा तयार करा। खालील आदेश प्रॉक्सी काढतात, प्रमाणपत्र साखळी तपासतात आणि नंतर लायब्ररीमार्फत कॉल पुन्हा करतात।

curl -sv --noproxy '*' https://api.corp.example/status -o /dev/null
openssl s_client -connect api.corp.example:443 -servername api.corp.example </dev/null
python3 -c "import requests;r=requests.get('https://api.corp.example/status',timeout=10);print(r.status_code)"

curl कॉल यशस्वी आणि Python कॉल अपयशी झाल्यास फरक अजूनही वातावरण आहे। दोन्ही TLS टप्प्यावर अपयशी झाल्यास प्रॉक्सी कधीच समस्या नव्हती आणि प्रमाणपत्र साखळी समस्या आहे। दोन्ही 401 परत केल्यास विनंती अनुप्रयोगापर्यंत पोहोचली आणि उर्वरित काम प्रमाणीकरण आहे। तीनपैकी कोणते पाहिले हे नोंदवल्यास पुढच्या व्यक्तीचा एक तास वाचतो।

मागे फिरणे कोणत्याही दिशेने एक ओळ आहे: वगळणूक काढा, किंवा trust_env परत फिरवा। जोडण्यापूर्वी मागील NO_PROXY मूल्य जतन करा, आणि फक्त तुमच्या टर्मिनल इतिहासात जगणाऱ्या निर्यातीपेक्षा रॅपर स्क्रिप्ट किंवा युनिट-स्तरीय Environment= नोंदीला प्राधान्य द्या। दोन्ही बदल प्रक्रियेच्या वातावरणात दिसतात, त्यामुळे पुन्हा सुरू केल्यास सहसा तुम्ही जुन्या वर्तनाकडे परत जाता।

चार गोष्टी निश्चित करून संपवा: खाजगी URL साठीच्या एकत्रित सेटिंग्ज कोणतीही प्रॉक्सी दाखवत नाहीत, प्रमाणपत्र इच्छित CA विरुद्ध वैध ठरते, विनंती अपेक्षित स्थिती परत करते, आणि बदल पुनरुत्पादनीय ठिकाणी कमिट केला आहे। अस्पष्ट वातावरणासह हिरवी स्क्रिप्ट ही पुढच्या मशीनवर पुन्हा तुटणारी दुरुस्ती आहे। या मार्गदर्शकातील आदेश टिकिटमध्ये पेस्ट करण्यासारखे आहेत।