Жеке API-де Requests ProxyError? Алдымен ортаны тексеріңіз

Requests прокси, аутентификация және 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 бумасының айнымалылары бұл жерде де маңызды, өйткені олар кодта еш жерде көрінбей-ақ 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-ге әсер етуді тоқтатады, ол содан кейін жинақталған сертификат қоймасына қайтады. Егер ұйымыңыз TLS-ті өз CA-сымен аяқтаса, бұл қайта оралу жаңа ғана жасалған өзгеріске қатысы жоқ сияқты көрінетін тексеру қатесін тудырады. 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 жасалған. Түсіндірілмеген ортамен жасыл скрипт — келесі машинада қайта бұзылатын түзету. Осы нұсқаулықтағы командалар — билетке қою керек командалар.

Қатысты мақалалар