Proksi orqasida pip check_hostname xatosi: pip yoki tunnel?
Proksi orqasida ikki xil nosozlik bir xil pip xost nomi xatosini chiqaradi. Eskirgan mijozi qayta imzo qo'yuvchi proksidan ajratib oling va to'g'ri qatlamni tuzating.
Ikki xil nosozlik bir xil pip izini chiqaradi va biriga mos tuzatish ikkinchisini yomonlashtiradi. Tunnel qilingan xostni nomlash uchun juda eski mijoz yangilanishga muhtoj. Trafikni qayta imzolovchi proksi ishonchli ildiz sertifikatiga muhtoj, versiyani pasaytirishga emas. Proksi o'zgaruvchisini tahrirlashdan oldin bu ikkisidan qaysi biri sizda borligini aniqlang, chunki yo'llar qarama-qarshi tomonga olib boradi.
Sozlamalarga tegishdan oldin oxirgi freymlarni o'qing
Iz qayerda tugashi qaysi qatlam taslim bo'lganini aytadi. Agar yakuniy freymlar pip bilan keladigan urllib3 TLS kodining ichida bo'lsa va matn xost nomidan shikoyat qilsa, mijoz kutubxonasi tekshiruv qadamini tugata olmagan, va bu sertifikat muammosidan ko'ra ko'proq versiya muammosi. Agar matn buning o'rniga rad etilgan ulanish, hal qilinmagan proksi nomi yoki HTTP 407 xatosi haqida xabar bersa, tunnelning oxirgi nuqtasi aybdor va hech qanday yangilanish buni o'zgartirmaydi.
pip versiyasi va proksi o'zgaruvchilarini muvaffaqiyatsiz bo'lgan o'sha shellda yozib oling. Tunnel ko'tarilishidan oldin ochilgan shell keyin ochilganidan boshqa qiymatlarni olib yuradi, va ular orasidagi farq ko'pincha butun diagnostika.
python3 -m pip --version
env | grep -i -E 'proxy|no_proxy'
Mijoz tunneldan eskiroq bo'lganda
Eski pip versiyalari soket tunnel bilan o'ralgach manzil xost nomini yo'qotadigan HTTPS stekni olib kelgan. check_hostname xabari o'sha stek taqqoslash uchun nom bo'lmaganda tekshiruvga yetganda chiqaradigan xabar. Yangilanish nosozlikni yo'q qiladi, chunki yangi mijoz qo'l berib ko'rishish davomida nomni saqlaydi, va yakuniy freymlar birga keladigan TLS kodini ko'rsatganda bu o'zgarishni birinchi sinab ko'rishga arziydigan darajada arzon.
Agar indeksga muvaffaqiyatsiz mashinadan kirish imkoni bo'lmasa, imkoni bor xostda joriy wheel yuklab oling va fayldan o'rnating. Blog postidan ko'chirilgan versiya o'rniga haqiqatan yuklab olgan fayl nomidan foydalaning.
python3 -m pip install --upgrade pip
python3 -m pip install ./pip-24.2-py3-none-any.whl
Proksi trafikni qayta imzolaganda
TLSni tugatadigan va sertifikatlarni korporativ ildiz ostida qayta chiqaradigan proksi boshqa xato hosil qiladi: certificate verify failed, xost nomi shikoyati emas. Aynan shu farq ishora, chunki mijoz serverga yetib bordi va keyin unga ko'rsatilgan shaxsni rad etdi. Tuzatish o'sha ildizga ochiq ishonishdir, yo bir buyruq uchun, yo PIP_CERT o'zgaruvchisi orqali, shunda mijoz proksi taqdim etgan narsaga zanjir qura oladi. Ildizni tizimning ishonch omboriga qo'shish ham ishlaydi, lekin bu mashinadagi har bir dasturning ishonchini o'zgartiradi, va bu bitta paket o'rnatishini tuzatishdan kattaroq qaror.
--trusted-hostni diagnostika sifatida saqlang, hech qachon doimiy holat sifatida emas. U siz saqlamoqchi bo'lgan tekshiruvni o'chiradi, shuning uchun haqiqatan noto'g'ri sertifikat keyin sog'lom ko'rinadi. Agar uni bitta paketni o'rnatish uchun ishlatgan bo'lsangiz, olib tashlang va keyingi versiyadan oldin zanjirni tuzating.
Sizning shaxsiy Python kodingiz pip konfiguratsiyasini butunlay e'tiborsiz qoldiradi. requests chaqiruvi proksi va to'plamni o'sha sessiya ularni ko'radigan joyga uzatishni talab qiladi, shuning uchun quyidagi blok ikkalasini ham sessiya obyektiga o'rnatadi.
pip install --cert /usr/local/share/ca-certificates/corp-root.crt requests
export PIP_CERT=/usr/local/share/ca-certificates/corp-root.crt
s = requests.Session()
s.proxies = {"https": "http://10.20.30.40:8080"}
s.verify = "/usr/local/share/ca-certificates/corp-root.crt"
s.get("https://pypi.org/simple/", timeout=15)
Oxirgi nuqta yoki port noto'g'ri bo'lganda
Tunnel mijozi ulanayotganda tizim proksisini tez-tez qayta yozadi, bu pipni o'sha portda hech qachon javob bermaydigan xostga qaratib qo'yishi mumkin. Har qanday pip sozlamasini o'zgartirishdan oldin oxirgi nuqtani pip bo'lmagan mijoz bilan sinab ko'ring. Agar curl o'sha proksi argumenti bilan muvaffaqiyatsiz bo'lsa, nosozlik pipdan yuqorida va pip ichidagi hech qanday konfiguratsiya yordam bermaydi.
Buyruq bayrog'i va muhit o'zgaruvchilari turli doiralarga bir xil narsani aytadi: bayroq bitta chaqiruvga, o'zgaruvchilar keyin ishga tushirilgan har bir jarayonga tegishli. Ichki indeks uchun NO_PROXY qo'shing, shaxsiy paket trafigi tunnel orqali aylanib o'tishni tashlab ketsin.
curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/
pip install --proxy http://proxy.corp.internal:8080 requests
Sozlamani saqlab qoling va yo'l ishlashini isbotlang
Proksi joriy shelldan uzoqroq yashashi kerak bo'lsa, uni pipning o'z konfiguratsiyasida saqlang, so'ng pip haqiqatan nimani ishlatishini o'qing. debug chiqishi har bir qiymat ortidagi fayl va o'zgaruvchini nomlaydi, bu ustuvorlik haqidagi bahslarni hujjatlarni o'qishdan tezroq hal qiladi.
Tekshiruv ataylab ikkita mijozdan foydalanadi. Standart kutubxona so'rovi marshrut va ishonch zanjirini isbotlaydi, yuklab olish esa pipning o'z konfiguratsiyasi ular bilan kelishishini isbotlaydi. Birinchisi muvaffaqiyatli bo'lib, ikkinchisi muvaffaqiyatsiz bo'lsa, farq tarmoqda emas, pip ichida.
pip config set global.proxy http://proxy.corp.internal:8080
pip config debug
python3 -c "import urllib.request as r; print(r.urlopen('https://pypi.org/simple/').status)"
pip download --no-deps -d /tmp/wheelcheck requests
| What you see | First command | Repair |
|---|---|---|
| hostname message inside vendored TLS frames | python3 -m pip --version | upgrade the client |
| certificate verify failed after the tunnel | curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/ | trust the corporate root |
| connection refused or HTTP 407 | env | grep -i -E 'proxy|no_proxy' | correct host, port or credentials |