ખાનગી API પર Requests ProxyError? પહેલા પર્યાવરણ તપાસો

Requests પર્યાવરણમાંથી પ્રોક્સી, auth અને CA સેટિંગ્સને એકત્ર કરે છે. પ્રોસેસ શું જુએ છે તે વાંચો, ખાનગી હોસ્ટને બાકાત કરો અને TLS ચકાસણી ચાલુ રાખો.

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-bundle ચલો અહીં પણ મહત્ત્વના છે, કારણ કે તેઓ કોડમાં ક્યાંય દેખાયા વિના બદલે છે કે 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 bundle પર ભરોસો કરશે. જો બંને સાચા લાગે, તો નિષ્ફળતા સ્ટેકમાં પછીથી છે અને તમારે ચકાસણી વિભાગમાં જવું જોઈએ. કોડ પરથી અનુમાન ન કરો: એકત્રીકરણ દરેક વિનંતી માટે થાય છે, તેથી એક સત્ર બે હોસ્ટ માટે અલગ રીતે વર્તી શકે છે.

કંઈપણ નિષ્ક્રિય કરતા પહેલા ખાનગી હોસ્ટને બાકાત કરો

જ્યારે પ્રોક્સી અન્ય ગંતવ્યો માટે ખરેખર જરૂરી હોય, ત્યારે સાંકડો ઉપાય આ હોસ્ટ માટે બાકાત છે. હાલની યાદીમાં ઉમેરો, તેને બદલો નહીં, કારણ કે 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 સામે માન્ય થાય છે, વિનંતી તમે અપેક્ષા રાખો તે સ્થિતિ પરત કરે છે, અને ફેરફાર પુનરાવર્તનયોગ્ય જગ્યાએ કમિટ થયો છે. અસ્પષ્ટ પર્યાવરણ સાથેની લીલી સ્ક્રિપ્ટ એ સુધારો છે જે આગલી મશીન પર ફરી તૂટે છે. આ માર્ગદર્શિકાના આદેશો ટિકિટમાં પેસ્ટ કરવાના છે.

સંબંધિત લેખો