निजी 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 केमा समाधान हुन्छ परिवर्तन गर्छन्। आउटपुट खाली भए वातावरण तपाईंको समस्या होइन र यो खण्ड पढ्न छोड्न सक्नुहुन्छ। यदि यसले नचिनेको प्रॉक्सी सूचीबद्ध गर्छ भने केही परिवर्तन गर्नुअघि त्यो सेट गर्ने फाइल वा युनिट खोज्नुहोस्।

Requests लाई कुनै विशेष URL सँग के गर्ने भनी सोध्नुहोस्। यो कलले कुनै प्याकेट नपठाई त्यो अनुरोधका लागि मिलाइएका प्रॉक्सी, 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 विरुद्ध मान्य हुन्छ, अनुरोधले तपाईंले अपेक्षा गरेको स्थिति फर्काउँछ, र परिवर्तन पुनःउत्पादनयोग्य ठाउँमा कमिट भएको छ। अव्याख्यायित वातावरणसहितको हरियो स्क्रिप्ट अर्को मेसिनमा फेरि भाँचिने सुधार हो। यो मार्गदर्शिकाका आदेशहरू टिकटमा टाँस्नुपर्ने हुन्।