Muat turun di terminal berfungsi, tetapi sambungan VS Code gagal pada VPN

Muat turun yang berjaya dalam terminal bekas ialah bukti sebenar tentang persekitaran terminal itu. Ia tidak berkata apa-apa tentang proses editor, pemasang sambungan atau binari yang diambil oleh sambungan selepas itu. Menyalin pemboleh ubah proksi antara ketiga-tiga ini menukar satu permintaan yang gagal menjadi sepanjang petang suntingan yang tidak berkaitan.

Dua persekitaran biasanya berbeza tepat pada satu perkara. Menemui perkara itu lebih pantas daripada membaca dokumentasi proksi dua kali.

Proses mana yang membuat permintaan yang gagal

Tiga permintaan boleh gagal dalam satu pemasangan, dan setiap satu mempunyai identiti rangkaiannya sendiri. Editor meminta metadata dan URL pakej daripada Marketplace, kemudian memuat turun pakej itu. Hanya selepas itu hos sambungan menjalankan kod yang mungkin mengambil pelayan bahasa atau binari sendiri. Peringkat mana yang rosak menentukan proses mana yang memerlukan proksi, dan permukaan ralat jarang menamakan peringkat itu.

Terminal yang berfungsi membuktikan bekas boleh mencapai internet, bukan editor boleh. Baca log sambungan untuk URL terakhir yang dicubanya. Hos yang dinamakan di sana mengenal pasti proses dan dasar yang terpakai kepadanya.

Editor setempat dan bekas jauh ialah dua persekitaran

Dalam ruang kerja jauh, sambungan berjalan pada sisi yang diisytiharkan oleh jenisnya. Sambungan antara muka kekal dengan editor setempat, dan sambungan ruang kerja berjalan dalam bekas. Proksi yang ditetapkan dalam satu tidak kelihatan kepada yang lain, dan pembinaan semula mencipta persekitaran bekas daripada fail konfigurasinya, bukan daripada apa yang anda eksport dalam shell. Pemisahan itu menjelaskan mengapa sambungan yang sama dipasang pada komputer riba dan gagal dalam projek yang sama melalui SSH.

Baca lokasi pemasangan sebelum menyunting apa-apa. Apabila log melaporkan pemasangan jauh, persekitaran bekaslah yang penting.

Letakkan proksi di tempat permintaan bermula

Untuk Dev Container yang benar-benar memerlukan proksi HTTP, pemboleh ubah itu tergolong dalam konfigurasi bekas supaya pembinaan semula menghasilkannya semula. Serpihan di bawah menetapkannya untuk persekitaran itu. Alamat pemegang tempat mewakili gerbang anda sendiri, dan pengecualian bukan pengisi pilihan.

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

Nama pemboleh ubah menerangkan protokol destinasi, jadi nilai HTTPS_PROXY boleh bermula dengan http secara sah. Gunakan perubahan melalui laluan pembinaan semula yang disokong, dan kekalkan pengecualian, kerana proksi yang memintas hos dalaman merosakkan perkhidmatan yang diperlukan oleh bekas.

Asingkan kegagalan kepercayaan daripada kebolehcapaian

Proksi yang bersambung dan kemudian mengembalikan ralat pengesahan sijil telah mencapai peringkat yang lebih lewat daripada proksi yang menolak sambungan. Kegagalan pertama mahukan bahan kepercayaan yang diluluskan organisasi dipasang dalam persekitaran yang membuat permintaan. Yang kedua mahukan alamat dan port yang boleh dicapai. Menganggap kedua-duanya sebagai satu masalah menghasilkan pembetulan yang tidak berfungsi bagi kedua-duanya.

Melumpuhkan pengesahan, atau menjalankan editor dengan hak yang dinaikkan, bukan pembaikan untuk proksi yang hilang atau rantaian kepercayaan yang tiada. Kedua-duanya menukar ralat yang kelihatan dengan yang senyap. Cuba semula sambungan yang sama selepas itu dan catat URL seterusnya yang gagal.

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

Catat sisi ruang kerja mana yang menghasilkan URL itu. Nota pendek yang menamakan peringkat, hos dan sisi lebih bernilai daripada senarai tetapan yang diubah oleh seseorang, kerana nota itulah yang boleh dihasilkan semula oleh orang seterusnya.