Ücretli bir proxy hizmetine erişim iki yoldan biriyle açılır: ya her istekte kullanıcı adı ve şifre gönderirsiniz, ya da sağlayıcının paneline genel IP adresinizi tanıtıp whitelist (izinli liste) oluşturursunuz. İkisi aynı sorunu çözer — "bu bağlantı gerçekten abonenin mi?" — ama günlük kullanımda çok farklı sonuçlar doğurur.
Bu yazıda iki yöntemin protokol düzeyinde nasıl çalıştığını, hangi senaryoda hangisinin doğru olduğunu ve karşılaşacağınız hata kodlarını ele alıyoruz.
Yöntem 1: Kullanıcı Adı ve Şifre
Bu yöntemde kimlik bilgisi her bağlantıda proxy'ye gönderilir. Protokole göre biçim değişir:
- HTTP proxy:
Proxy-Authorization: Basic <base64(kullanici:sifre)>başlığı eklenir. - SOCKS5: RFC 1929'da tanımlı username/password alt görüşmesi yapılır; kullanıcı adı ve şifre ikili biçimde gönderilir.
HTTP tarafında akış şöyledir: istemci kimlik bilgisi olmadan istek gönderir, proxy 407 Proxy Authentication Required ile yanıt verir, istemci kimlik bilgisini ekleyip isteği tekrarlar.
Çoğu istemci bu iki turu otomatik yapar. curl ve tarayıcılar 407 gördüğünde kimliği ekleyip isteği tekrarlar; basit HTTP kütüphaneleri ise bazen tekrar denemez ve doğrudan hata verir.
Basic yöntemi kimlik bilgisini şifrelemez, yalnızca Base64 ile kodlar. Base64 geri çevrilebilir bir kodlamadır. Bu yüzden kimlik bilgisinin gizliliği, proxy'ye giden bağlantının kendisinin güvenli olmasına bağlıdır.
Yöntem 2: IP Whitelist
Whitelist modelinde şifre yoktur. Sağlayıcının paneline kendi genel IP adresinizi eklersiniz; proxy yalnızca o adresten gelen bağlantıları kabul eder. Kimlik bilgisi taşınmadığı için istemci tarafı çok basitleşir: curl -x http://proxy.example.com:8080 https://example.com yeterlidir.
Bu modelin can alıcı sorusu şudur: sizin genel IP adresiniz sabit mi? Ev internetlerinin çoğunda IP dinamiktir ve modem yeniden başladığında değişir. Değiştiğinde whitelist geçersiz kalır ve tüm bağlantılar reddedilir.
Seçim büyük ölçüde "sabit IP'niz var mı" sorusuna iner. Sunucuda çalışan otomasyonlar için whitelist, gezici kullanım için kullanıcı/şifre daha uygundur.
Hangi Senaryoda Hangisi?
Sunucuda çalışan scraper veya bot
VPS'inizin IP'si sabittir; whitelist seçin. Kimlik bilgisi koda veya ortam değişkenine gömülmez, sızıntı yüzeyi küçülür. Otomasyon senaryoları için önerdiğimiz varsayılan budur.
Dizüstü bilgisayardan manuel kullanım
Ofis, ev ve kafe arasında geçiş yapıyorsanız IP sürekli değişir. Kullanıcı/şifre kullanın; her ağdan sorunsuz çalışır.
Ekip içinde paylaşımlı kullanım
Kim ne kadar trafik harcadı sorusunun yanıtı gerekiyorsa kişi başına ayrı kullanıcı açın. Whitelist'te tüm ekip tek kimlik altında görünür.
Antidetect tarayıcı ile çoklu profil
Her profile farklı çıkış IP'si atanacaksa kullanıcı/şifre zorunludur; çünkü oturum seçimi çoğu zaman kullanıcı adının içine kodlanır (örneğin user-session-a1).
Oturum Bilgisinin Kullanıcı Adına Gömülmesi
Residential havuzlarda yaygın bir desen vardır: kullanıcı adı yalnızca kimlik değil, aynı zamanda bir komut taşır. Örneğin:
Ayraç karakteri ve parametre adları sağlayıcıdan sağlayıcıya değişir. Panelinizdeki belgeyi esas alın; buradaki biçim yalnızca yapıyı göstermek içindir.
Bu tasarımın avantajı, istemci tarafında hiçbir API çağrısı gerekmemesidir: kullanıcı adını değiştirerek ülke veya oturum değiştirirsiniz. Dezavantajı ise kimlik bilgisinin uzaması ve yazım hatalarının sessiz davranış değişikliklerine yol açmasıdır. Rotating proxy mantığını anlatan yazımızda bu modelin oturum yönetimine etkisini ayrıntılı ele alıyoruz.
Sık Karşılaşılan Hatalar
407 ile 403 arasındaki fark kritik: 407 "kimliğini göster" der, 403 ise "kimliğini gördüm, yetkin yok" anlamına gelir.
Özel Karakter Tuzağı
Kimlik bilgisini URL biçiminde yazarken şifredeki bazı karakterler ayraçla karışır. http://user:p@ss@ip:8080 ifadesinde ikinci @ ayraç sanılır ve bağlantı kurulamaz. Çözüm yüzde kodlamasıdır:
| Karakter | Kodlanmış hâli | Karakter | Kodlanmış hâli |
|---|---|---|---|
@ | %40 | / | %2F |
: | %3A | # | %23 |
? | %3F | % | %25 |
Daha sağlam bir yaklaşım, kimlik bilgisini URL'ye gömmek yerine istemcinin ayrı alanlarına vermektir. Python requests, Node undici ve curl'ün --proxy-user seçeneği bunu destekler.
Kimlik bilgisini koda gömmek yerine ortam değişkeninden okumak, hem sürüm kontrolüne sızmasını önler hem de rotasyonu kolaylaştırır.
Güvenlik Açısından Ne Değişir?
İki yöntem farklı riskler taşır. Kullanıcı/şifre modelinde sır çalınabilir: log dosyasına düşen bir komut satırı, sürüm kontrolüne kaçan bir yapılandırma dosyası veya ekran görüntüsü yeterlidir. Whitelist modelinde sır yoktur ama IP paylaşımı riski vardır: aynı ofis ağındaki herkes, farkında olmadan proxy'nizi kullanabilir.
En sağlam yapılandırma ikisini birleştirmektir: whitelist ile kaynağı daraltın, üstüne kullanıcı/şifre ekleyin. Çoğu kurumsal sağlayıcı bu hibrit modeli destekler. Gizlilik tarafında proxy'nin ne gördüğünü merak ediyorsanız proxy güvenli mi yazımız kapsamlı bir çerçeve sunuyor; sızıntı testleri için DNS leak ve WebRTC leak araçlarımızı kullanabilirsiniz.
Kimlik Bilgisi Yönetimi İçin Pratik Kurallar
- Ortam değişkeni kullanın, kodun içine yazmayın.
- Her ortam için ayrı kimlik açın: geliştirme, test ve üretim aynı şifreyi paylaşmasın.
- Kota ve limit tanımlayın; sızan bir kimlik sınırsız trafik harcamasın.
- Düzenli döndürün; ekipten ayrılan biri sonrası mutlaka değiştirin.
- Log'larda maskeleyin; hata ayıklama çıktısı şifreyi düz metin yazmasın.
Özet
IP whitelist, sabit IP'li sunucularda en temiz ve en az sızıntı riskli çözümdür. Kullanıcı adı ve şifre ise gezici kullanımda ve çoklu oturum gerektiren senaryolarda vazgeçilmezdir. Karar verirken "IP'm sabit mi", "kaç kişi kullanacak" ve "oturum parametresi göndermem gerekiyor mu" sorularını yanıtlamak yeterlidir. Yapılandırmanızı test etmek için proxy kontrol aracını kullanabilir, çıkış IP'nizi IP Adresim ile doğrulayabilirsiniz.