In this Article
Bekerja dengan GitHub dari dalam jaringan perusahaan biasanya merupakan masalah konfigurasi yang tersebar di lima alat yang tidak berbagi pengaturan. clone berhasil dan npm install gagal; npm berhasil dan Docker tidak dapat pull; semuanya berhasil pada command line dan IDE tidak dapat menjangkau apa pun.
Panduan ini membahas tempat setiap alat membaca pengaturan proxy, alasan SSH berperilaku berbeda dari HTTPS, cara membaca empat jenis kesalahan yang benar-benar akan Anda lihat, serta dua jalan pintas yang sebaiknya ditolak.
Fakta Utama
- Setiap alat memiliki konfigurasi proxy sendiri. Git, npm, pip, Docker, dan shell Anda membaca pengaturan yang berbeda, sehingga memperbaiki satu alat membuat yang lain tetap bermasalah.
- SSH biasanya gagal ketika HTTPS berhasil, karena sebagian besar proxy perusahaan hanya meneruskan HTTP CONNECT pada port standar.
- Kesalahan sertifikat hampir selalu berarti inspeksi TLS, dan solusinya adalah memercayai CA perusahaan, bukan menonaktifkan verifikasi.
- Jangan pernah menonaktifkan verifikasi sertifikat agar clone berhasil. Tindakan itu mengubah masalah konfigurasi yang terlihat menjadi masalah keamanan yang tidak terlihat.
- Kredensial dalam URL proxy bocor ke log dan riwayat shell, jadi gunakan penyimpanan kredensial milik alat tersebut.
Di mana setiap alat membaca pengaturan proxy?
Secara terpisah, yang menjadi akar sebagian besar kebingungan. Kami menyebutnya model toolchain 4-bagian.
| Alat | Tempat pencarian | Kesenjangan umum |
|---|---|---|
| 1. Git | konfigurasi sendiri, lalu environment variables | remote HTTPS berfungsi sedangkan remote SSH tidak |
| 2. Package manager | berkas konfigurasi sendiri, lalu environment variables | Masing-masing perlu dikonfigurasi terpisah; registry dapat berbeda dari GitHub |
| 3. Docker | Konfigurasi daemon, bukan hanya shell Anda | Variabel shell tidak mencapai daemon yang melakukan pull image |
| 4. IDE dan editor | Pengaturan sendiri, terkadang penyimpanan sistem | Terminal berfungsi, fitur terintegrasi tidak |
Karena itu, penyiapan github proxy yang berfungsi berarti lima konfigurasi, bukan satu. Urutan praktisnya adalah menetapkan environment variables untuk shell, lalu mengonfigurasi git, kemudian setiap package manager, lalu daemon Docker, serta menyertakan daftar no-proxy untuk host internal sejak awal. Melewatkan langkah terakhir inilah yang membuat layanan internal tidak dapat dijangkau setelah penyiapan yang sebenarnya berhasil.
Mengapa SSH gagal ketika HTTPS berhasil?
Karena keduanya merupakan protokol yang berbeda pada port yang berbeda, dan sebagian besar proxy perusahaan hanya meneruskan HTTP CONNECT ke sejumlah kecil port.
Git melalui HTTPS adalah request web biasa yang ditangani proxy secara native. Git melalui SSH menggunakan port 22, yang biasanya sama sekali tidak diizinkan melalui proxy. Akibatnya, repository berhasil di-clone dengan remote HTTPS dan mengalami time out dengan remote SSH, sementara pesan kesalahan jarang menjelaskan alasannya.
Tiga solusi praktis, berdasarkan urutan preferensi: ganti remote ke HTTPS dengan token, gunakan SSH melalui port HTTPS jika GitHub mendukungnya, atau minta tim jaringan mengizinkan SSH ke host tertentu. Opsi pertama berfungsi di mana saja dan merupakan pilihan yang digunakan sebagian besar tim.
Bagaimana membaca kesalahan?
| Kesalahan | Gunakan solusi ini ketika | Hindari ketika |
|---|---|---|
| Verifikasi sertifikat gagal | Tambahkan CA perusahaan ke penyimpanan tepercaya alat tersebut | Jangan pernah menonaktifkan verifikasi, karena itu menyembunyikan risiko nyata |
| Koneksi mengalami time out pada remote SSH | Beralih ke HTTPS atau SSH melalui port HTTPS | Mencoba lagi; port diblokir, bukan lambat |
| Autentikasi proxy diperlukan | Konfigurasikan kredensial dalam penyimpanan alat tersebut | Menempatkannya dalam URL, yang bocor ke log |
| Berfungsi di terminal, gagal di Docker | Konfigurasikan daemon Docker, lalu mulai ulang | Menambahkan lebih banyak variabel shell, yang tidak pernah dibaca daemon |
| Host internal tidak dapat dijangkau setelah penyiapan | Tambahkan ke daftar no-proxy | Menghapus konfigurasi proxy sepenuhnya |
Baris pertama adalah hal yang perlu ditegaskan. Inspeksi TLS berarti middlebox menghentikan dan menandatangani ulang koneksi Anda, dan respons yang benar adalah memercayai CA organisasi secara sengaja. Menonaktifkan verifikasi membuat kesalahan menghilang dan menjadikan setiap intersepsi di masa mendatang tidak terlihat.
Kapan proxy eksternal merupakan alat yang tepat?
Jarang untuk masalah ini, dan hal itu perlu dijelaskan dengan tegas.
Proxy perusahaan adalah infrastruktur yang dijalankan organisasi Anda, dan solusi untuk akses GitHub di baliknya adalah konfigurasi, bukan proxy kedua. Mengarahkan lalu lintas mengelilingi kontrol jaringan yang sengaja diterapkan perusahaan Anda adalah persoalan kebijakan sebelum menjadi persoalan teknis.
Situasi penggunaan proxy komersial yang benar-benar relevan adalah pekerjaan berbeda yang kebetulan melibatkan GitHub: mengumpulkan data repository publik dalam skala besar, memeriksa bagaimana halaman publik dirender dari negara lain, atau menjalankan pemeriksaan otomatis dari beberapa wilayah. Khusus untuk mengumpulkan data repository, GitHub API dengan token adalah jawaban yang tepat terlebih dahulu, dan kapasitasnya cukup besar sehingga scraping jarang dapat dibenarkan.
Ketika pengumpulan memang memerlukan exit terdistribusi, DataImpulse residential mencakup 195 negara dengan harga $1 per GB. Terkait: proxy untuk web scraping, penjelasan 403 Forbidden.
Pertanyaan yang Sering Diajukan
Bagaimana cara mengonfigurasi git untuk menggunakan proxy?
Atur proxy dalam konfigurasi git sendiri atau dalam environment variables standar, dan tambahkan host internal ke daftar no-proxy pada saat yang sama. Git membaca konfigurasi sendiri secara terpisah dari npm, pip, dan Docker, sehingga setiap alat perlu dikonfigurasi secara individual.
Mengapa git clone melalui SSH gagal di balik proxy?
Karena SSH menggunakan port 22 dan sebagian besar proxy perusahaan hanya meneruskan HTTP CONNECT ke port web standar. Remote HTTPS berfungsi karena merupakan request web biasa. Mengganti remote ke HTTPS dengan token adalah solusi yang berfungsi di lingkungan terbanyak.
Apa yang menyebabkan kesalahan sertifikat di balik proxy perusahaan?
Inspeksi TLS: middlebox menghentikan dan menandatangani ulang koneksi Anda menggunakan certificate authority milik organisasi. Solusinya adalah menambahkan CA tersebut ke penyimpanan tepercaya setiap alat. Menonaktifkan verifikasi sertifikat menghapus kesalahan dan menghapus kemampuan Anda untuk mendeteksi intersepsi nyata.
Mengapa Docker gagal ketika terminal saya berfungsi?
Karena daemon Docker yang melakukan pull image, bukan shell Anda, dan daemon itu membaca konfigurasi sendiri alih-alih environment variables Anda. Konfigurasikan pengaturan proxy daemon lalu mulai ulang.
Haruskah saya menggunakan proxy komersial untuk mengakses GitHub di tempat kerja?
Tidak. Proxy perusahaan adalah infrastruktur yang sengaja dijalankan organisasi Anda, dan solusinya adalah konfigurasi. Proxy komersial relevan untuk pekerjaan berbeda, seperti mengumpulkan data publik dari banyak wilayah, dan bahkan dalam hal itu GitHub API dengan token biasanya merupakan jalur yang lebih baik.
Ketika pekerjaannya adalah pengumpulan, bukan konektivitas
Memeriksa bagaimana halaman publik dirender dari wilayah lain, atau mengumpulkan data publik dalam skala besar, merupakan masalah yang berbeda dari konfigurasi jaringan perusahaan. DataImpulse residential proxies mencakup 195 negara dengan harga $1 per GB. Buat akun saat itulah pekerjaannya.
Terkait: proxy untuk web scraping · 403 Forbidden saat scraping · apa itu web proxy.
Terakhir diperbarui: 17 September 2026.