ProxyError ya Requests kwenye API ya kibinafsi? Kwanza angalia mazingira

VPN imewaka, dashibodi ya ndani inafunguka kwenye kivinjari, na hati ya Python bado inatupa hitilafu ya proksi. Katika picha hiyo hakuna kitu kibaya na handaki: mkalimani anasoma anwani ya proksi kutoka mazingira yake mwenyewe na kutuma ombi huko. Mwongozo huu unasoma mazingira ambayo mchakato unaona kweli, unatumia kutenga nyembamba zaidi na baada ya hapo tu unafikiria sera ya kikao iliyo wazi. Kila hatua inaisha kwa amri ambayo matokeo yake huamua kama unaendelea.

Soma mazingira ambayo mchakato unaona kweli

Mipangilio ya proksi ya kompyuta ya mezani, mauzo ya shell na mistari ya Environment= ya kitengo cha systemd ni vyanzo vitatu tofauti, na Requests husoma tu cha mwisho anachorithi. Endesha uchunguzi ulio chini katika shell, kontena au kitengo kile kile kinachoendesha hati inayoshindwa, sio kwenye terminal yako ya mwingiliano. Kigezo kilichouzwa kwenye shell yako ya kuingia hakionekani kwa mchakato wa kontena, na pengo hilo linaeleza ripoti nyingi za proksi inayotokea kutoka mahali pasipo na mahali. Amri mbili zote huchapisha data ile moja kwa viwango tofauti vya undani.

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()]"

Tahajia zote mbili za kila kigezo husomwa, na maingizo yanayorudiwa hutumika kwa mpangilio ambao mchakato uliyapokea, hivyo HTTP_PROXY ya zamani inaweza kuzidi thamani uliyouzwa hivi punde. Vigezo vya kifurushi cha CA pia ni muhimu hapa, kwa sababu hubadilisha verify inatatuliwa wapi bila kuonekana mahali popote kwenye msimbo. Ikiwa matokeo ni tupu, mazingira sio tatizo lako na unaweza kuacha kusoma sehemu hii. Ikiwa yanaorodhesha proksi usiyoifahamu, tafuta faili au kitengo kinachoiweka kabla ya kubadilisha chochote.

Uliza Requests jinsi itakavyoshughulikia URL mahususi. Simu hii inaonyesha thamani zilizounganishwa za proksi, verify na cert kwa ombi hilo bila kutuma kifurushi.

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

Ingizo proxies lisilo tupu kwa mwenyeji wa kibinafsi ni jibu lako, na thamani ya verify iliyochapishwa inakuambia kifurushi kipi cha CA ombi lingeamini. Ikiwa zote zinaonekana sahihi, hitilafu iko mbele zaidi kwenye rafu na unapaswa kuruka hadi sehemu ya uthibitisho. Usikisie kutoka kwenye msimbo: muunganisho hufanyika kwa kila ombi, ndiyo sababu kikao kimoja kinaweza kuwa na tabia tofauti kwa wenyeji wawili.

Tenga mwenyeji wa kibinafsi kabla ya kuzima chochote

Wakati proksi inahitajika kweli kwa maeneo mengine, suluhisho nyembamba ni kutenga mwenyeji huyu. Ongeza kwenye orodha iliyopo badala ya kuibadilisha, kwa sababu kufuta NO_PROXY huvunja kila eneo lingine la ndani lililokuwa likitegemea. Amri zilizo chini zinaongeza ingizo kisha zinauliza Requests kama upitaji unatumika.

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))"

Ulinganisho hufanyika kwa kiambishi cha mwenyeji, hivyo .corp.example inashughulikia kikoa kizima wakati api.corp.example inashughulikia jina moja. Nyota tupu huzima proksi kwa kila mwenyeji na mara nyingi si kile kazi ya uzalishaji inachotaka. Ikiwa ingizo la CIDR litaheshimiwa hutegemea matoleo ya Requests na urllib3 kwenye taswira, hivyo jaribu ingizo mahususi badala ya kudhani linafanya kazi. Angalia matokeo ya should_bypass_proxies kwa URL halisi, sio kwa jina la mwenyeji uliloandika kutoka kumbukumbu.

Weka tabaka mbili tofauti kichwani. Kupita proksi ya HTTP hakupiti VPN, kwa sababu uamuzi wa proksi hufanyika kwenye maktaba na uamuzi wa handaki kwenye jedwali la uelekezaji la kernel.

Zima trust_env tu kama sera ya kikao iliyokusudiwa

Ikiwa kazi nzima inapaswa kupuuza usanidi wa mazingira, jenga kikao kwa uwazi na urekodi uamuzi kwenye msimbo. Hiyo ni sera, sio njia ya kukwepa, na ni ya diff ambayo mkaguzi anaweza kuona. Mfano ulio chini unahifadhi muda wa kusubiri, njia ya CA iliyo wazi na ukaguzi wa hali.

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()

Kuzima trust_env hubadilisha tabia tatu kwa wakati mmoja, na moja tu kati yao inahusu proksi. Requests huacha kusoma vitambulisho vya .netrc, na vigezo REQUESTS_CA_BUNDLE na CURL_CA_BUNDLE huacha kuathiri verify, ambayo kisha hurudi kwenye ghala la vyeti lililojumuishwa. Ikiwa shirika lako linamaliza TLS kwa CA yake mwenyewe, kurudi nyuma huko kunazua hitilafu ya uthibitisho inayoonekana isiyohusiana na mabadiliko uliyofanya hivi punde. Kupitisha verify kwa uwazi ndiko kunakoweka athari mbili tofauti.

Usichopaswa kufanya ni kuweka verify=False ili kunyamazisha hitilafu inayotokea. Hiyo hubadilisha usanidi mbaya wa proksi kwa muunganisho usiothibitishwa, na huficha tatizo la cheti ambalo kutenga kulipaswa kulifichua.

Thibitisha tabaka linaloshindwa na uweke nafasi ya kurudi nyuma

Hitilafu tatu zinaonekana sawa kwenye kumbukumbu na hazina kitu chochote cha pamoja: proksi isiyoweza kufikia lengwa inatupa ProxyError au inarudisha 502, tatizo la uaminifu linatupa SSLError, na kukataliwa kwa programu kunarudisha 401 au 403. Zalisha tena ombi nje ya Requests ili kuona lipi unalo. Amri zilizo chini huondoa proksi, hujaribu mnyororo wa vyeti kisha kurudia simu kupitia maktaba.

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)"

Ikiwa simu ya curl inafanikiwa na simu ya Python inashindwa, mazingira bado ni tofauti. Ikiwa zote mbili zinashindwa katika hatua ya TLS, proksi haikuwa tatizo kamwe na mnyororo wa vyeti ndio tatizo. Ikiwa zote mbili zinarudisha 401, ombi lilifika kwenye programu na kazi iliyobaki ni uthibitishaji. Kurekodi lipi kati ya matatu uliyoona huokoa saa moja kwa mtu anayefuata.

Kurudi nyuma ni mstari mmoja kwa pande zote mbili: ondoa kutenga, au geuza trust_env nyuma. Hifadhi thamani ya awali ya NO_PROXY kabla ya kuongeza chochote, na pendelea hati ya kufunika au ingizo la Environment= la kiwango cha kitengo badala ya mauzo yanayoishi tu kwenye historia ya terminal yako. Mabadiliko yote mawili yanaonekana kwenye mazingira ya mchakato, hivyo kuwasha upya kwa kawaida hukurejesha kwenye tabia ya zamani.

Maliza kwa kuthibitisha mambo manne: mipangilio iliyounganishwa ya URL ya kibinafsi haionyeshi proksi, cheti kinathibitishwa dhidi ya CA iliyokusudiwa, ombi linarudisha hali unayotarajia, na mabadiliko yamefanywa mahali panapoweza kuzalishwa tena. Hati ya kijani yenye mazingira yasiyoelezwa ni marekebisho yanayovunjika tena kwenye mashine inayofuata. Amri za mwongozo huu ndizo unazopaswa kubandika kwenye tiketi.