தனியார் 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-வுக்கு எதிராகச் செல்லுபடியாகிறது, கோரிக்கை நீங்கள் எதிர்பார்க்கும் நிலையைத் திரும்பத் தருகிறது, மாற்றம் மீண்டும் உருவாக்கக்கூடிய இடத்தில் commit செய்யப்பட்டுள்ளது. விவரிக்கப்படாத சூழலுடன் பச்சை ஸ்கிரிப்ட் அடுத்த இயந்திரத்தில் மீண்டும் உடையும் திருத்தம். இந்த வழிகாட்டியின் கட்டளைகளே டிக்கெட்டில் ஒட்ட வேண்டியவை.