In this Article
Kurumsal bir ağın içinden GitHub ile çalışmak, genellikle ayarları paylaşmayan beş araca yayılmış bir yapılandırma sorunudur. Clone çalışır ama npm install başarısız olur; npm çalışır ama Docker çekemez; komut satırında her şey çalışır ama IDE hiçbir şeye erişemez.
Bu rehber, her aracın proxy ayarlarını nereden okuduğunu, SSH’nin HTTPS’den neden farklı davrandığını, gerçekten göreceğiniz dört hata türünü nasıl yorumlayacağınızı ve kaçınmaya değer iki kısayolu ele alır.
Temel Bilgiler
- Her aracın kendi proxy yapılandırması vardır. Git, npm, pip, Docker ve kabuğunuz farklı ayarları okur; bu yüzden birini düzeltmek diğerlerini bozuk bırakır.
- HTTPS çalışırken SSH genellikle başarısız olur, çünkü kurumsal proxy’lerin çoğu standart portlarda yalnızca HTTP CONNECT’i iletir.
- Sertifika hataları neredeyse her zaman TLS incelemesi anlamına gelir ve çözüm, doğrulamayı devre dışı bırakmak yerine kurumsal CA’ya güvenmektir.
- Bir clone işlemini çalıştırmak için sertifika doğrulamasını asla devre dışı bırakmayın. Bu, görünür bir yapılandırma sorununu görünmez bir güvenlik sorununa dönüştürür.
- Proxy URL’sindeki kimlik bilgileri günlük kaydı ve kabuk geçmişine sızar; bunun yerine aracın kimlik bilgisi deposunu kullanın.
Her araç proxy ayarlarını nereden okur?
Ayrı ayrı; kafa karışıklığının çoğunun kökü budur. Buna 4 parçalı araç zinciri modeli diyoruz.
| Araç | Baktığı yer | Yaygın eksik |
|---|---|---|
| 1. Git | Kendi yapılandırması, ardından ortam değişkenleri | HTTPS uzak bağlantıları çalışırken SSH uzak bağlantıları çalışmaz |
| 2. Paket yöneticileri | Kendi yapılandırma dosyaları, ardından ortam değişkenleri | Her biri ayrı yapılandırılmalıdır; kayıt depoları GitHub’dan farklı olabilir |
| 3. Docker | Yalnızca kabuğunuz değil, daemon yapılandırması | Kabuk değişkenleri imajları çeken daemon’a ulaşmaz |
| 4. IDE’ler ve düzenleyiciler | Kendi ayarları, bazen sistem deposu | Terminal çalışır, tümleşik özellikler çalışmaz |
Dolayısıyla çalışan bir github proxy kurulumu tek değil, beş yapılandırma demektir. Pratik sıra, kabuk için ortam değişkenlerini ayarlamak, sonra git’i, ardından her paket yöneticisini, sonra Docker daemon’ını yapılandırmak ve en baştan iç ana bilgisayarlar için bir no-proxy listesi eklemektir. Son adımı atlamak, bunun dışındaki başarılı bir kurulumdan sonra iç hizmetleri erişilemez yapan şeydir.
HTTPS çalışırken SSH neden başarısız olur?
Çünkü bunlar farklı portlardaki farklı protokollerdir ve kurumsal proxy’lerin çoğu yalnızca küçük bir port kümesine HTTP CONNECT iletir.
HTTPS üzerinden Git, proxy’nin yerel olarak işlediği sıradan bir web isteğidir. SSH üzerinden Git, genellikle proxy üzerinden hiç izin verilmeyen 22 numaralı portu kullanır. Sonuç olarak bir depo HTTPS uzak bağlantısıyla sorunsuz clone edilir, SSH uzak bağlantısıyla zaman aşımına uğrar ve hata mesajı bunun nedenini nadiren söyler.
Tercih sırasıyla üç pratik çözüm vardır: uzak bağlantıyı token ile HTTPS’ye geçirmek, GitHub’ın desteklediği yerde HTTPS portu üzerinden SSH kullanmak veya ağ ekibinden belirli ana bilgisayarlara SSH izni istemek. İlki her yerde çalışır ve çoğu ekibin tercih ettiği çözümdür.
Hataları nasıl yorumlarsınız?
| Hata | Bu düzeltmeyi ne zaman kullanmalısınız? | Ne zaman kaçınmalısınız? |
|---|---|---|
| Sertifika doğrulaması başarısız oldu | Kurumsal CA’yı aracın güven deposuna ekleyin | Gerçek bir riski gizleyen doğrulamayı asla devre dışı bırakmayın |
| SSH uzak bağlantısında bağlantı zaman aşımına uğradı | HTTPS’ye geçin veya HTTPS portu üzerinden SSH kullanın | Yeniden denemek; port yavaş değil, engellenmiştir |
| Proxy kimlik doğrulaması gerekli | Kimlik bilgilerini aracın deposunda yapılandırın | Bunları URL’ye koymak, günlük kaydına sızdırır |
| Terminalde çalışıyor, Docker’da başarısız oluyor | Docker daemon’ını yapılandırın, sonra yeniden başlatın | Daemon’ın hiç okumadığı daha fazla kabuk değişkeni eklemek |
| Kurulumdan sonra iç ana bilgisayarlara erişilemiyor | Bunları no-proxy listesine ekleyin | Proxy yapılandırmasını tamamen kaldırmak |
İlk satırda kararlı olmak gerekir. TLS incelemesi, bir ara cihazın bağlantılarınızı sonlandırıp yeniden imzaladığı anlamına gelir ve doğru yanıt, kuruluşun CA’sına bilinçli olarak güvenmektir. Doğrulamayı devre dışı bırakmak hatayı ortadan kaldırır ve gelecekteki her müdahaleyi görünmez kılar.
Harici bir proxy ne zaman doğru araçtır?
Bu sorun için nadiren; bunu netleştirmekte yarar var.
Kurumsal proxy, kuruluşunuzun işlettiği altyapıdır ve arkasından GitHub erişiminin çözümü ikinci bir proxy değil, yapılandırmadır. İşvereninizin bilinçli olarak uyguladığı bir ağ denetimini aşmak, teknik bir mesele olmadan önce bir politika meselesidir.
Ticari bir proxy’nin gerçekten uygun olduğu durum, GitHub ile ilişkili olsa da farklı bir iştir: herkese açık depo verilerini büyük ölçekte toplamak, herkese açık bir sayfanın başka bir ülkeden nasıl oluşturulduğunu denetlemek veya birden çok bölgeden otomatik kontroller çalıştırmak. Özellikle depo verisi toplamak için token içeren GitHub API ilk doğru yanıttır ve yeterince cömert olduğu için veri kazıma nadiren gerekçelendirilir.
Toplama işlemi dağıtık çıkışlar gerektirdiğinde DataImpulse residential 195 ülkeyi GB başına $1 karşılığında kapsar. İlgili: web scraping için proxy’ler, 403 Forbidden açıklaması.
Sık Sorulan Sorular
git’i bir proxy kullanacak şekilde nasıl yapılandırırım?
Proxy’yi git’in kendi yapılandırmasında veya standart ortam değişkenlerinde ayarlayın ve aynı anda iç ana bilgisayarları no-proxy listesine ekleyin. Git kendi yapılandırmasını npm, pip ve Docker’dan ayrı okur; bu yüzden her araç ayrı ayrı yapılandırılmalıdır.
Proxy arkasında SSH üzerinden git clone neden başarısız olur?
Çünkü SSH 22 numaralı portu kullanır ve kurumsal proxy’lerin çoğu standart web portlarına yalnızca HTTP CONNECT iletir. HTTPS uzak bağlantıları sıradan web istekleri oldukları için çalışır. Uzak bağlantıyı token ile HTTPS’ye geçirmek, en çok ortamda çalışan çözümdür.
Kurumsal proxy arkasında sertifika hatalarına ne yol açar?
TLS incelemesi: bir ara cihaz, bağlantılarınızı kuruluşun kendi sertifika yetkilisiyle sonlandırır ve yeniden imzalar. Çözüm, o CA’yı her aracın güven deposuna eklemektir. Sertifika doğrulamasını devre dışı bırakmak hatayı giderir ve gerçek bir müdahaleyi saptama yeteneğinizi ortadan kaldırır.
Terminalim çalışırken Docker neden başarısız olur?
Çünkü imajları kabuğunuz değil Docker daemon’ı çeker ve ortam değişkenleriniz yerine kendi yapılandırmasını okur. Daemon’ın proxy ayarlarını yapılandırın ve yeniden başlatın.
İş yerinde GitHub’a erişmek için ticari proxy kullanmalı mıyım?
Hayır. Kurumsal proxy, kuruluşunuzun bilinçli olarak işlettiği altyapıdır ve çözüm yapılandırmadır. Ticari proxy’ler, birçok bölgeden herkese açık veri toplamak gibi farklı işler için uygundur; orada bile token içeren GitHub API genellikle daha iyi yoldur.
İş bağlantı değil, toplama olduğunda
Herkese açık sayfaların başka bölgelerde nasıl oluşturulduğunu denetlemek veya herkese açık verileri büyük ölçekte toplamak, kurumsal ağ yapılandırmasından farklı bir sorundur. DataImpulse residential proxy’ler 195 ülkeyi GB başına $1 karşılığında kapsar. İş buysa hesap oluşturun.
İlgili: web scraping için proxy’ler · veri kazımada 403 Forbidden · web proxy nedir.
Son güncelleme: 17 Eylül 2026.