Kesalahan check_hostname pip di balik proxy: pip atau terowongan?

Dua kegagalan berbeda mencetak jejak pip yang sama, dan perbaikan yang cocok untuk satu justru memperburuk yang lain. Klien yang terlalu tua untuk menyebut host yang diterowongkan perlu pemutakhiran. Proxy yang menandatangani ulang lalu lintas perlu sertifikat akar tepercaya, bukan penurunan versi. Tentukan mana dari keduanya yang Anda miliki sebelum menyunting variabel proxy, karena jalurnya menuju arah yang berlawanan.

Baca bingkai terakhir sebelum menyentuh pengaturan

Di mana jejak berakhir memberi tahu Anda lapisan mana yang menyerah. Jika bingkai penutup berada di dalam kode TLS urllib3 bawaan pip dan teksnya mengeluh soal nama host, pustaka klien tidak dapat menyelesaikan langkah verifikasi, dan itu masalah versi jauh lebih sering daripada masalah sertifikat. Jika teksnya justru melaporkan koneksi yang ditolak, nama proxy yang tidak terurai, atau HTTP 407, titik akhir terowonganlah yang bersalah dan tidak ada pemutakhiran yang akan mengubahnya.

Tangkap versi pip dan variabel proxy di shell yang sama yang gagal. Shell yang dibuka sebelum terowongan aktif membawa nilai berbeda dari yang dibuka sesudahnya, dan selisih di antara keduanya sering kali merupakan seluruh diagnosis.

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

Ketika klien lebih tua daripada terowongan

Rilis pip yang lebih lama menyertakan tumpukan HTTPS yang kehilangan nama host tujuan setelah soket dibungkus terowongan. Pesan check_hostname adalah yang dikeluarkan tumpukan itu ketika mencapai verifikasi tanpa nama untuk dibandingkan. Pemutakhiran menghapus kesalahan itu karena klien yang lebih baru mempertahankan nama sepanjang jabat tangan, dan perubahannya cukup murah untuk dicoba lebih dulu setiap kali bingkai penutup menunjuk ke kode TLS bawaan.

Jika indeks tidak dapat dijangkau dari mesin yang gagal, ambil wheel terkini di host yang bisa dan pasang dari berkas itu. Gunakan nama berkas yang benar-benar Anda unduh, bukan versi yang disalin dari pos blog.

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

Ketika proxy menandatangani ulang lalu lintas

Proxy yang mengakhiri TLS dan menerbitkan ulang sertifikat di bawah akar korporat menghasilkan kesalahan berbeda: certificate verify failed, bukan keluhan nama host. Perbedaan itulah petunjuknya, karena klien mencapai server lalu menolak identitas yang ditunjukkan kepadanya. Perbaikannya adalah memercayai akar itu secara eksplisit, entah untuk satu perintah atau melalui variabel PIP_CERT, agar klien dapat membangun rantai ke apa yang disajikan proxy. Menambahkan akar ke penyimpanan kepercayaan sistem juga berfungsi, tetapi itu mengubah kepercayaan bagi setiap program di mesin, dan itu keputusan yang lebih besar daripada memperbaiki satu pemasangan paket.

Pertahankan --trusted-host sebagai diagnostik, jangan pernah sebagai keadaan tetap. Itu mematikan pemeriksaan yang ingin Anda pertahankan, sehingga sertifikat yang benar-benar salah tampak sehat sesudahnya. Jika Anda memakainya untuk memasang satu paket, hapus dan perbaiki rantainya sebelum rilis berikutnya.

Kode Python Anda sendiri mengabaikan konfigurasi pip sepenuhnya. Panggilan requests perlu meneruskan proxy dan bundel ke tempat sesi itu dapat melihatnya, karena itulah blok di bawah menetapkan keduanya pada objek sesi.

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)

Ketika titik akhir atau port salah

Klien terowongan sering menulis ulang proxy sistem saat terhubung, yang bisa membuat pip menunjuk ke host yang tidak pernah menjawab pada port itu. Uji titik akhir dengan klien yang bukan pip sebelum mengubah pengaturan pip apa pun. Jika curl gagal dengan argumen proxy yang sama, kesalahannya ada di atas pip dan tidak ada konfigurasi di dalam pip yang akan menolong.

Bendera perintah dan variabel lingkungan mengatakan hal yang sama untuk cakupan berbeda: bendera berlaku untuk satu pemanggilan, variabel untuk setiap proses yang dimulai sesudahnya. Tambahkan NO_PROXY untuk indeks internal agar lalu lintas paket privat melewati jalan memutar melalui terowongan.

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

Simpan pengaturan dan buktikan jalurnya bekerja

Simpan proxy di konfigurasi pip sendiri ketika harus bertahan melewati shell saat ini, lalu baca kembali apa yang benar-benar akan dipakai pip. Keluaran debug menyebut berkas dan variabel di balik setiap nilai, yang menyelesaikan perdebatan soal prioritas lebih cepat daripada membaca dokumentasi.

Verifikasi sengaja memakai dua klien. Permintaan dari pustaka standar membuktikan rute dan rantai kepercayaan, sedangkan unduhan membuktikan bahwa konfigurasi pip sendiri setuju dengan keduanya. Ketika yang pertama berhasil dan yang kedua gagal, selisihnya ada di dalam pip, bukan di jaringan.

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