Xususiy API'da Requests ProxyError? Avval muhitni tekshiring

VPN yoniq, ichki panel brauzerda ochiladi, lekin Python skripti hali ham proksi xatosini beradi. Bu rasmda tunnelda hech narsa noto'g'ri emas: interpretator proksi manzilini o'z muhitidan o'qiydi va so'rovni o'sha yerga yuboradi. Ushbu qo'llanma jarayon haqiqatan ko'radigan muhitni o'qiydi, eng tor istisnoni qo'llaydi va shundan keyingina aniq sessiya siyosatini ko'rib chiqadi. Har bir qadam chiqishi davom etishni hal qiladigan buyruq bilan tugaydi.

Jarayon haqiqatan ko'radigan muhitni o'qing

Ish stolidagi proksi sozlamalari, shell eksportlari va systemd birligining Environment= satrlari uch xil manba, Requests esa faqat meros olgan oxirgisini o'qiydi. Quyidagi diagnostikani muvaffaqiyatsiz skriptni ishga tushiruvchi o'sha shell, konteyner yoki birlikda ishga tushiring, interaktiv terminalingizda emas. Kirish shellingizda eksport qilingan o'zgaruvchi konteyner jarayoniga ko'rinmaydi va bu bo'shliq hech yerdan paydo bo'lgan proksi haqidagi ko'plab xabarlarni tushuntiradi. Ikkala buyruq bir xil ma'lumotni turli tafsilot darajasida chiqaradi.

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

Har bir o'zgaruvchining ikkala yozilishi ham o'qiladi va takroriy yozuvlar jarayon ularni olgan tartibda qo'llaniladi, shuning uchun eski HTTP_PROXY hozir eksport qilgan qiymatni bosib ketishi mumkin. CA to'plami o'zgaruvchilari bu yerda ham muhim, chunki ular kodda hech qayerda ko'rinmasdan verify nimaga hal bo'lishini o'zgartiradi. Agar chiqish bo'sh bo'lsa, muhit sizning muammoingiz emas va bu bo'limni o'qishni to'xtatishingiz mumkin. Agar u siz bilmagan proksini ro'yxatga olsa, biror narsani o'zgartirishdan oldin uni sozlovchi fayl yoki birlikni toping.

Requestsdan ma'lum bir URL bilan nima qilishini so'rang. Bu chaqiruv paket yubormasdan o'sha so'rov uchun birlashtirilgan proksi, verify va cert qiymatlarini ko'rsatadi.

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

Xususiy host uchun bo'sh bo'lmagan proxies yozuvi sizning javobingiz, chop etilgan verify qiymati esa so'rov qaysi CA to'plamiga ishonishini aytadi. Agar ikkalasi ham to'g'ri ko'rinsa, nosozlik stekda keyinroq va siz tekshirish bo'limiga o'tishingiz kerak. Koddan taxmin qilmang: birlashtirish har bir so'rov uchun sodir bo'ladi, shuning uchun bitta sessiya ikki host uchun boshqacha ishlashi mumkin.

Biror narsani o'chirishdan oldin xususiy hostni chiqarib tashlang

Proksi boshqa manzillar uchun haqiqatan kerak bo'lsa, tor yechim bu host uchun istisno. Mavjud ro'yxatga qo'shing, uni almashtirmang, chunki NO_PROXY ni o'chirish unga tayangan boshqa barcha ichki manzillarni buzadi. Quyidagi buyruqlar yozuvni qo'shadi va keyin Requestsdan chetlashuv amal qiladimi deb so'raydi.

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

Moslik host qo'shimchasiga ko'ra, shuning uchun .corp.example butun domenni qamrab oladi, api.corp.example esa bitta nomni. Yalang'och yulduzcha har bir host uchun proksini o'chiradi va ishlab chiqarish ishi buni deyarli hech qachon xohlamaydi. CIDR yozuvi hisobga olinadimi, bu tasvirdagi Requests va urllib3 versiyalariga bog'liq, shuning uchun ishlaydi deb taxmin qilish o'rniga aniq yozuvni sinab ko'ring. should_bypass_proxies natijasini haqiqiy URL uchun tekshiring, xotiradan yozgan host nomi uchun emas.

Ikki qatlamni xayolan alohida saqlang. HTTP proksidan o'tish VPNdan o'tish emas, chunki proksi qarori kutubxonada, tunnel qarori yadro yo'naltirish jadvalida qabul qilinadi.

trust_env ni faqat qasddan olingan sessiya siyosati sifatida o'chiring

Agar butun ish atrofdagi konfiguratsiyani e'tiborsiz qoldirishi kerak bo'lsa, sessiyani aniq quring va qarorni kodda qayd eting. Bu siyosat, aylanma yo'l emas va taqrizchi ko'radigan diffga tegishli. Quyidagi misol taymaut, aniq CA yo'li va holat tekshiruvini saqlaydi.

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 ni o'chirish bir vaqtning o'zida uch xulq-atvorni o'zgartiradi va ulardan faqat bittasi proksiga tegishli. Requests .netrc hisob ma'lumotlarini o'qishni to'xtatadi, REQUESTS_CA_BUNDLE va CURL_CA_BUNDLE o'zgaruvchilari verify ga ta'sir qilishni to'xtatadi, u esa keyin birga kelgan sertifikat omboriga qaytadi. Agar tashkilotingiz TLSni o'z CAsi bilan tugatsa, bu qaytish hozir qilingan o'zgarishga aloqasiz ko'rinadigan tekshirish xatosini keltirib chiqaradi. verify ni aniq uzatish ikki ta'sirni alohida ushlab turadi.

Qilmasligingiz kerak bo'lgan narsa — yuzaga kelgan xatoni jim qilish uchun verify=False ni sozlash. Bu noto'g'ri proksi konfiguratsiyasini tekshirilmagan ulanish bilan almashtiradi va istisno oshkor qilishi kerak bo'lgan sertifikat muammosini yashiradi.

Muvaffaqiyatsiz qatlamni tekshiring va qaytarish imkoniyatini saqlang

Uch nosozlik jurnalda bir xil ko'rinadi va ularda umumiy narsa yo'q: manzilga yeta olmaydigan proksi ProxyError tashlaydi yoki 502 qaytaradi, ishonch muammosi SSLError tashlaydi, ilova rad etishi esa 401 yoki 403 qaytaradi. Qaysi biri sizda ekanini ko'rish uchun so'rovni Requests tashqarisida takrorlang. Quyidagi buyruqlar proksini olib tashlaydi, sertifikat zanjirini sinaydi va keyin chaqiruvni kutubxona orqali takrorlaydi.

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

Agar curl chaqiruvi muvaffaqiyatli bo'lib, Python chaqiruvi muvaffaqiyatsiz bo'lsa, farq hali ham muhitda. Agar ikkalasi TLS bosqichida muvaffaqiyatsiz bo'lsa, proksi hech qachon muammo bo'lmagan va muammo sertifikat zanjirida. Agar ikkalasi 401 qaytarsa, so'rov ilovaga yetib bordi va qolgan ish autentifikatsiya. Uchtasidan qaysi birini kuzatganingizni yozib qo'yish keyingi odamga bir soat tejaydi.

Qaytarish har ikki yo'nalishda ham bir satr: istisnoni olib tashlang yoki trust_env ni orqaga qaytaring. Biror narsa qo'shishdan oldin avvalgi NO_PROXY qiymatini saqlang va faqat terminal tarixingizda yashaydigan eksport o'rniga o'rovchi skript yoki birlik darajasidagi Environment= yozuvini afzal ko'ring. Ikkala o'zgarish ham jarayon muhitida ko'rinadi, shuning uchun qayta ishga tushirish odatda sizni eski xulq-atvorga qaytaradi.

To'rt narsani tasdiqlab tugating: xususiy URL uchun birlashtirilgan sozlamalar hech qanday proksi ko'rsatmaydi, sertifikat mo'ljallangan CAga nisbatan tekshiriladi, so'rov siz kutgan holatni qaytaradi va o'zgarish takrorlash mumkin bo'lgan joyda commit qilingan. Tushuntirilmagan muhit bilan yashil skript keyingi mashinada yana buziladigan tuzatishdir. Ushbu qo'llanmadagi buyruqlar chiptaga qo'yilishi kerak bo'lganlardir.