Bir proxy arkasında pip check_hostname hatası: pip mi yoksa tünel mi?

İki farklı arıza aynı pip izini yazdırır ve birine uygun onarım diğerini daha da kötüleştirir. Tünellenmiş bir ana bilgisayarı adlandıramayacak kadar eski bir istemcinin yükseltmeye ihtiyacı vardır. Trafiği yeniden imzalayan bir proxynin güvenilir bir kök sertifikaya ihtiyacı vardır, sürüm düşürmeye değil. Proxy değişkenini düzenlemeden önce ikisinden hangisine sahip olduğunuzu belirleyin, çünkü yollar zıt yönlere gider.

Ayarlara dokunmadan önce son çerçeveleri okuyun

İz nerede bitiyorsa hangi katmanın pes ettiğini söyler. Kapanış çerçeveleri pip ile gelen urllib3 TLS kodunun içindeyse ve metin bir ana bilgisayar adından şikâyet ediyorsa, istemci kitaplığı bir doğrulama adımını tamamlayamamıştır ve bu, sertifika sorunundan çok daha sık bir sürüm sorunudur. Metin bunun yerine reddedilen bir bağlantı, çözülemeyen bir proxy adı veya HTTP 407 hatası bildiriyorsa, tünelin uç noktası suçludur ve hiçbir yükseltme bunu değiştirmez.

pip sürümünü ve proxy değişkenlerini başarısız olan aynı kabukta yakalayın. Tünel açılmadan önce açılan bir kabuk, sonra açılandan farklı değerler taşır ve aralarındaki fark çoğu zaman tanının tamamıdır.

python3 -m pip --version
env | grep -i -E 'proxy|no_proxy'

İstemci tünelden daha eski olduğunda

Eski pip sürümleri, soket bir tünelle sarıldığında hedef ana bilgisayar adını kaybeden bir HTTPS yığını içeriyordu. check_hostname mesajı, bu yığının karşılaştırma için bir ad olmadan doğrulamaya ulaştığında yaydığı şeydir. Yükseltme arızayı ortadan kaldırır çünkü daha yeni istemci adı el sıkışma boyunca korur ve kapanış çerçeveleri gömülü TLS kodunu gösterdiğinde bu değişikliği ilk denemeye değecek kadar ucuzdur.

Dizine başarısız makineden ulaşılamıyorsa, ulaşabilen bir ana bilgisayarda güncel bir wheel alın ve dosyadan kurun. Blog gönderisinden kopyalanmış bir sürüm yerine gerçekten indirdiğiniz dosya adını kullanın.

python3 -m pip install --upgrade pip
python3 -m pip install ./pip-24.2-py3-none-any.whl

Proxy trafiği yeniden imzaladığında

TLS'yi sonlandıran ve sertifikaları kurumsal bir kök altında yeniden veren bir proxy farklı bir hata üretir: certificate verify failed, ana bilgisayar adı şikâyeti değil. Bu fark ipucudur, çünkü istemci bir sunucuya ulaştı ve sonra kendisine gösterilen kimliği reddetti. Onarım, o köke açıkça güvenmektir; tek bir komut için ya da PIP_CERT değişkeni aracılığıyla, böylece istemci proxynin sunduğu şeye bir zincir kurabilir. Kökü sistemin güven deposuna eklemek de işe yarar, ancak makinedeki her program için güveni değiştirir ve bu, tek bir paket kurulumunu onarmaktan daha büyük bir karardır.

--trusted-host'u tanı aracı olarak tutun, asla kalıcı bir durum olarak değil. Korumaya çalıştığınız denetimi kapatır, bu yüzden gerçekten yanlış bir sertifika sonrasında sağlıklı görünür. Bir paketi kurmak için kullandıysanız kaldırın ve bir sonraki sürümden önce zinciri onarın.

Kendi Python kodunuz pip yapılandırmasını tamamen yok sayar. Bir requests çağrısı, proxy ve paketin o oturumun görebileceği yere geçirilmesini gerektirir; bu yüzden aşağıdaki blok ikisini de oturum nesnesine ayarlar.

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)

Uç nokta veya bağlantı noktası yanlış olduğunda

Bir tünel istemcisi bağlanırken sistem proxysini sık sık yeniden yazar; bu da pip'i o bağlantı noktasında hiç yanıt vermeyen bir ana bilgisayara yöneltilmiş bırakabilir. Herhangi bir pip ayarını değiştirmeden önce uç noktayı pip olmayan bir istemciyle test edin. curl aynı proxy argümanıyla başarısız olursa arıza pip'in üzerindedir ve pip içindeki hiçbir yapılandırma yardımcı olmaz.

Komut bayrağı ve ortam değişkenleri aynı şeyi farklı kapsamlara söyler: bayrak tek bir çağrı için, değişkenler sonradan başlatılan her süreç için geçerlidir. Dahili bir dizin için NO_PROXY ekleyin, böylece özel paket trafiği tünel üzerinden dolanmayı atlar.

curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/
pip install --proxy http://proxy.corp.internal:8080 requests

Ayarı kalıcı kılın ve yolun çalıştığını kanıtlayın

Proxy'yi geçerli kabuğun ötesine yaşaması gerektiğinde pip'in kendi yapılandırmasında saklayın, sonra pip'in gerçekte ne kullanacağını okuyun. debug çıktısı her değerin arkasındaki dosyayı ve değişkeni adlandırır; bu, öncelik tartışmalarını belgeleri okumaktan daha hızlı çözer.

Doğrulama kasten iki istemci kullanır. Standart kütüphaneden gelen istek rotayı ve güven zincirini kanıtlar, indirme ise pip'in kendi yapılandırmasının onlarla aynı fikirde olduğunu kanıtlar. Birincisi başarılı olup ikincisi başarısız olduğunda fark ağda değil pip'in içindedir.

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