Bir proxy satın aldığınızda elinize bir adres ve port geçer. Ama bu adrese bağlanan herkesin trafiğini iletmesi, proxy'nin başkaları tarafından kullanılması demek olur. Bu yüzden her ücretli proxy bağlantıyı kabul etmeden önce kimin bağlandığını kontrol eder. Bunun için iki yaygın yöntem vardır: kullanıcı adı ve şifre (user:pass) ya da izinli IP listesi (IP whitelist).
Bu yazıda iki yöntemin arka planda nasıl çalıştığını, hangisinin hangi durumda daha güvenli ve pratik olduğunu, cURL, Python ve tarayıcıda her iki yöntemle nasıl bağlanıldığını anlatıyoruz. Destek taleplerinin önemli kısmını oluşturan 407 Proxy Authentication Required hatasının nedenlerine ve dinamik IP adresinin whitelist ile yarattığı soruna da ayrı başlıklarda bakıyoruz.
Proxy kimlik doğrulama nedir?
Proxy kimlik doğrulama, proxy sunucunun bir bağlantıyı iletmeden önce o bağlantının yetkili bir kullanıcıya ait olup olmadığını kontrol etmesidir. Doğrulama başarısız olursa proxy isteği hedefe iletmez.
İki yöntem farklı bir soruya cevap arar:
- Kullanıcı adı ve şifre: "Bu isteği gönderen, doğru bilgileri biliyor mu?"
- IP whitelist: "Bu bağlantı, izin verilmiş bir IP adresinden mi geliyor?"
İlk yöntemde kimlik bilgisi isteğin içindedir; ikincisinde ise bağlantının kaynağı kimlik yerine geçer. Bu fark, iki yöntemin taşınabilirliğini, güvenliğini ve hata biçimlerini belirler. Proxy'nin genel çalışma mantığını Proxy Sunucu Nedir ve Nasıl Çalışır? yazımızda anlattık.
Kullanıcı adı ve şifreyle bağlantı nasıl çalışır?
HTTP proxy'lerde kullanıcı adı ve şifre doğrulaması HTTP standardının bir parçasıdır. RFC 9110, proxy'nin kimlik istemek için Proxy-Authenticate, istemcinin kimlik göndermek için Proxy-Authorization başlığını kullanmasını tanımlar. En yaygın şema Basic'tir ve RFC 7617 ile tanımlanır.
Bir HTTPS isteğinde süreç şöyle işler:
- İstemci proxy'ye bağlanır ve
CONNECT hedef.com:443isteği gönderir. - İstek kimlik bilgisi taşımıyorsa proxy
407 Proxy Authentication Requiredyanıtı veProxy-Authenticate: Basic realm="proxy"başlığı döner. - İstemci kullanıcı adı ile şifreyi
kullanici:parolabiçiminde birleştirir, Base64 ile kodlar ve isteğiProxy-Authorization: Basic a3VsbGFuaWNpOnBhcm9sYQ==başlığıyla tekrar gönderir. - Proxy bilgileri kontrol eder. Doğruysa hedefe bağlanıp
200 Connection Establisheddöner, yanlışsa yine 407 döner.
Çoğu istemci ilk denemede başlığı doğrudan ekler, yani 2. adım pratikte atlanır. Tarayıcılar ise önce başlıksız dener, 407 alınca kullanıcıya bir giriş penceresi gösterir.
Burada önemli bir ayrıntı var: Base64 bir şifreleme değil, kodlamadır. Başlığı gören herkes onu saniyeler içinde çözüp kullanıcı adı ve şifreyi okuyabilir. İstemci ile proxy arasındaki bağlantı çoğu kurulumda şifresiz HTTP'dir; bu da kimlik bilgilerinin bu kısa yol boyunca açık metin gibi taşındığı anlamına gelir. Hedef siteyle kurulan HTTPS tüneli bu başlığı korumaz, çünkü başlık tünel kurulmadan önce gönderilir.
SOCKS5 proxy'lerde de RFC 1929 ile tanımlanan benzer bir kullanıcı adı ve şifre alt yöntemi vardır; orada da bilgiler şifresiz gönderilir.
IP whitelist (izinli IP listesi) nasıl çalışır?
IP whitelist yönteminde isteğin içinde hiçbir kimlik bilgisi yoktur. Siz müşteri panelinde bir veya birden fazla IP adresini yetkili olarak kaydedersiniz; proxy sunucusu gelen her bağlantının kaynak IP adresini bu listeyle karşılaştırır.
- Panelde, proxy'yi kullanacak makinenin genel (public) IP adresini listeye eklersiniz.
- İstemci proxy'ye kullanıcı adı ve şifre olmadan bağlanır.
- Proxy bağlantının kaynak adresine bakar. Adres listedeyse isteği iletir.
- Adres listede değilse bağlantıyı reddeder ya da 407 döner.
Buradaki "genel IP adresi", bilgisayarınızın ağ ayarlarında gördüğünüz 192.168.x.x gibi yerel adres değildir. Proxy'nin gördüğü adres, modeminizin ya da sunucunuzun internete çıktığı adrestir. Bu adresi öğrenmek için proxy kapalıyken şu komutu çalıştırabilirsiniz:
curl https://api.ipify.orgWhitelist'in en büyük avantajı, kimlik bilgisi desteklemeyen yazılımlarla çalışabilmesidir. Bazı eski masaüstü uygulamaları, oyun istemcileri ve otomasyon araçları proxy ayarında yalnızca adres ve port alanı sunar; bu durumda whitelist tek seçenektir.
İki yöntemin karşılaştırması
| Ölçüt | Kullanıcı adı ve şifre | IP whitelist |
|---|---|---|
| Kimlik neyle kanıtlanır? | İstekteki Proxy-Authorization başlığı | Bağlantının kaynak IP adresi |
| Farklı ağlardan bağlanma | Sorunsuz | Her ağın IP'si listeye eklenmeli |
| Dinamik IP'li ev bağlantısı | Sorunsuz | IP değiştiğinde bağlantı kesilir |
| Birden fazla cihaz | Aynı bilgilerle hepsi bağlanır | Her cihazın çıkış IP'si eklenmeli |
| Yetkisiz kullanım riski | Bilgiler sızarsa her yerden kullanılabilir | Aynı IP'yi paylaşan başka kullanıcılar |
| Kimlik bilgisi desteği olmayan yazılım | Çalışmaz | Çalışır |
| Kod ve yapılandırmada gizli bilgi | Var, saklanması gerekir | Yok |
| Chrome ile SOCKS5 | Desteklenmez | Çalışır |
| Tipik kullanım | Dizüstü, farklı ağlar, bulut fonksiyonları | Sabit IP'li sunucular, eski yazılımlar |
Hangisi daha güvenli?
Kesin bir cevap yoktur; iki yöntem farklı risklere açıktır.
Kullanıcı adı ve şifrenin riski, bilginin sızmasıdır. Bir kod deposuna yanlışlıkla gönderilen yapılandırma dosyası, ekran paylaşımında görünen bir komut ya da ortak kullanılan bir bilgisayardaki tarayıcı kaydı yeterlidir. Sızan bilgiyle proxy dünyanın herhangi bir yerinden kullanılabilir ve bu kullanım sizin hesabınızdan düşer.
IP whitelist'in riski, IP adresinin paylaşılmasıdır. Mobil operatörler ve bazı ev internet sağlayıcıları, CGNAT adı verilen bir yöntemle çok sayıda aboneyi aynı genel IP adresinden internete çıkarır. Böyle bir adresi listeye eklediğinizde, aynı adresi paylaşan tanımadığınız kullanıcılar da proxy'nize bağlanabilir hâle gelir. Kafe, otel ve ortak ofis ağları için de aynı durum geçerlidir.
Pratik kurallar:
- Sabit IP'li bir sunucudan çalışıyorsanız whitelist daha güvenlidir; kodda gizli bilgi taşımazsınız.
- Mobil hattan veya CGNAT arkasındaki bir ev bağlantısından whitelist kullanmayın.
- Kullanıcı adı ve şifre kullanıyorsanız bilgileri kodun içine yazmayın; ortam değişkeninde veya gizli bilgi yöneticisinde tutun.
- Paneliniz farklı işler için ayrı alt kullanıcılar oluşturmaya izin veriyorsa bunu kullanın; sızan bir bilginin etkisi tek işle sınırlı kalır.
Örneklerle iki yöntem
Aşağıdaki örneklerde adres ve port temsilidir; kendi değerlerinizi müşteri panelinizden alın.
cURL
# Kullanıcı adı ve şifre, adresin içinde
curl -x "http://kullanici:parola@pr.proxynet.io:8000" https://httpbin.org/ip
# Kullanıcı adı ve şifre, ayrı seçenekle
curl -x "http://pr.proxynet.io:8000" -U "kullanici:parola" https://httpbin.org/ip
# IP whitelist: kimlik bilgisi yok
curl -x "http://pr.proxynet.io:8000" https://httpbin.org/ip-U (uzun hâli --proxy-user) seçeneği, şifreyi adresin içine yazmadığınız için özel karakter sorununu da azaltır. cURL'deki diğer seçenekler için cURL ile Proxy Nasıl Kullanılır? yazımıza bakabilirsiniz.
Python Requests
import os
from urllib.parse import quote
import requests
user = os.environ["PROXY_USER"]
password = quote(os.environ["PROXY_PASS"], safe="") # @, :, / gibi karakterleri kodlar
# Kullanıcı adı ve şifre
proxy = f"http://{user}:{password}@pr.proxynet.io:8000"
r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20)
print(r.json())
# IP whitelist
proxy = "http://pr.proxynet.io:8000"
r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20)
print(r.json())Bilgiler ortam değişkeninden okunduğu için kod dosyası paylaşılsa bile şifre görünmez. Rotasyonlu bir Python kurulumunu Python ile Rotating Proxy yazımızda adım adım anlattık. Node.js karşılığı için Node.js'te Proxy Kullanımı yazımıza bakabilirsiniz.
Tarayıcı
Tarayıcılar proxy adresini ayar ekranından ya da işletim sisteminden alır, ancak kullanıcı adı ve şifreyi ayar ekranında sormaz. İlk istekte proxy 407 döndüğünde bir giriş penceresi açılır ve bilgileri oraya girersiniz. Chrome, SOCKS5 proxy'lerde kullanıcı adı ve şifre doğrulamasını desteklemez; SOCKS5'i Chrome ile kullanacaksanız IP whitelist gerekir.
Windows ve Chrome'da adımlar Windows ve Chrome Proxy Ayarları, Firefox'ta ise Firefox Proxy Ayarları yazımızda. API test aracında kurulum için Postman Proxy Ayarları yazımıza bakabilirsiniz. Proxy ayarı sunmayan masaüstü uygulamalarını yönlendirme seçeneği Proxifier yazımızda anlatılıyor.
407 Proxy Authentication Required hatası neden çıkar?
RFC 9110'un 15.5.8. bölümü, 407'yi "istemcinin proxy'ye kimliğini kanıtlaması gerekiyor" anlamında tanımlar. Yani sorun hedef sitede değil, sizinle proxy arasındadır. En sık nedenler şunlardır:
- Kullanıcı adı veya şifre yanlış. Kopyalarken sona eklenen boşluk ya da büyük-küçük harf farkı yeterlidir.
- Şifrede kodlanmamış özel karakter var.
http://kullanici:p@ss@pr.proxynet.io:8000adresinde istemci ilk@işaretinden sonrasını sunucu adı sanar.@karakteri%40,:karakteri%3A,/karakteri%2Folarak yazılmalıdır. - Whitelist'e eklenen IP ile bağlantının çıktığı IP farklı. Modem yeniden başladı, VPN açık kaldı ya da iş yerinden farklı bir ağdan bağlandınız.
- Yazılım kimlik bilgisini göndermiyor. Bazı araçlar proxy adresindeki
kullanici:parola@kısmını yok sayar; ayrı bir kimlik alanı veya seçenek gerekir. - Yanlış protokol veya port. Kimlik bilgisi doğru olsa da HTTP portuna SOCKS5 ile bağlanmak ya da tersi anlamsız bir hata üretir.
- Hesap veya alt kullanıcı durdurulmuş. Bakiye bitmiş, alt kullanıcı silinmiş ya da trafik sınırı dolmuş olabilir.
Hatayı teşhis etmek için cURL'ün ayrıntılı çıktısı işe yarar:
curl -v -x "http://kullanici:parola@pr.proxynet.io:8000" https://httpbin.org/ip 2>&1 | grep -iE "proxy-authorization|< HTTP"Çıktıda Proxy-Authorization satırı hiç yoksa istemci bilgileri göndermiyordur. Satır var ama yanıt 407 ise bilgiler yanlıştır ya da hesapta bir sorun vardır. HTTP hata kodlarının scraping'deki anlamını Scraping'de HTTP Hata Kodları yazımızda topladık.
Dinamik IP'de whitelist ne olur?
Ev internet bağlantılarının çoğunda genel IP adresi sabit değildir. Modem yeniden başladığında, hat koptuğunda ya da servis sağlayıcı belirli aralıklarla adres değiştirdiğinde yeni bir IP alırsınız. Whitelist'teki eski adres geçersiz kalır ve proxy bağlantıyı reddeder.
Bu durumda seçenekler şunlardır:
- Kullanıcı adı ve şifreye geçmek. Dinamik IP'li bağlantılar için en az uğraştıran çözümdür.
- Servis sağlayıcıdan sabit IP almak. İşiniz sürekli aynı ağdan yürüyorsa kalıcı çözümdür.
- İşi sabit IP'li bir sunucuya taşımak. Kazıma betikleri ve zamanlanmış görevler için bulut sunucusu genellikle sabit bir çıkış adresi verir.
- Panel API'si varsa listeyi otomatik güncellemek. Bu, sağlayıcının böyle bir API sunmasına bağlıdır.
Bulut fonksiyonları ve otomatik ölçeklenen konteynerler her çalıştığında farklı bir çıkış adresi alabilir; bu ortamlarda whitelist genellikle uygulanamaz.
Kullanım senaryoları
- Sabit IP'li sunucuda veri toplama betiği: Whitelist; kodda şifre taşımaya gerek kalmaz. Tek adres üzerinden farklı çıkış IP'leri için Rotating Proxy kullanılır.
- Farklı ağlardan çalışan ekip: Kullanıcı adı ve şifre; her üyeye ayrı alt kullanıcı açılabiliyorsa daha da iyi.
- Oturum gerektiren hesap işleri: Genellikle kullanıcı adı ve şifre; oturum boyunca aynı IP için Sticky Proxy, uzun süreli sabit adres için ISP Proxy.
- Kimlik alanı olmayan eski masaüstü yazılımı: Whitelist tek seçenektir.
- Chrome ile SOCKS5: Whitelist, çünkü Chrome SOCKS5'te şifre doğrulamayı desteklemez.
Karar rehberi
| Durumunuz | Öneri |
|---|---|
| Sabit IP'li sunucu veya VPS | IP whitelist |
| Dizüstü bilgisayar, farklı ağlar | Kullanıcı adı ve şifre |
| Dinamik IP'li ev bağlantısı | Kullanıcı adı ve şifre |
| Mobil hat veya CGNAT arkası | Kullanıcı adı ve şifre |
| Bulut fonksiyonu, otomatik ölçeklenen konteyner | Kullanıcı adı ve şifre |
| Kimlik alanı olmayan yazılım | IP whitelist |
| Chrome ile SOCKS5 | IP whitelist |
| Kodda gizli bilgi taşımak istemiyorsunuz | IP whitelist (sabit IP varsa) |
Sık sorulan sorular
İki yöntemi aynı anda kullanabilir miyim?
Sağlayıcıya bağlıdır. Birçok sağlayıcı aynı hesapta hem whitelist'e eklenmiş IP'lerden şifresiz bağlantıyı hem de başka yerlerden kullanıcı adı ve şifreli bağlantıyı kabul eder. Paneldeki ayarlar bu davranışı belirler.
Kullanıcı adı ve şifre trafiğimle birlikte hedef siteye gider mi?
Hayır. Proxy-Authorization başlığı yalnızca proxy'ye yöneliktir; proxy bu başlığı hedefe iletmez. Hedef site kimlik bilgilerinizi görmez.
Proxy şifremi nasıl daha güvenli saklarım?
Şifreyi kaynak koduna yazmayın. Ortam değişkeni, .env dosyası (sürüm kontrolüne eklenmeden) ya da kullandığınız platformun gizli bilgi yöneticisi tercih edin. Şifrenin sızdığından şüphelenirseniz panelden hemen değiştirin.
Whitelist'e kaç IP ekleyebilirim?
Bu sınır sağlayıcıdan sağlayıcıya ve paketten pakete değişir. Güncel sınırı müşteri panelinizde veya destek ekibinden öğrenebilirsiniz.
Şifre doğru olduğu hâlde neden 407 alıyorum?
En sık neden şifredeki özel karakterlerin kodlanmamasıdır. İkinci sık neden kullandığınız yazılımın adresteki kimlik bilgisini göndermemesidir. Yukarıdaki curl -v komutuyla başlığın gidip gitmediğini kontrol edin.
VPN açıkken whitelist çalışır mı?
VPN açıkken internete VPN sunucusunun IP adresiyle çıkarsınız. Whitelist'te kendi ev veya ofis IP adresiniz kayıtlıysa proxy bağlantıyı reddeder. Ya VPN'i kapatın ya da VPN'in çıkış adresini listeye ekleyin; ikincisi, aynı VPN adresini paylaşan başka kullanıcılar olabileceği için önerilmez.
Özetle
Proxy kimlik doğrulamanın iki yolu vardır: her istekte Proxy-Authorization başlığıyla gönderilen kullanıcı adı ve şifre, ya da bağlantının kaynak adresine bakan IP whitelist. Kullanıcı adı ve şifre her ağda çalışır ama bilgilerin saklanması gerekir; whitelist kodda gizli bilgi bırakmaz ama sabit ve paylaşılmayan bir IP adresi ister. 407 hatası neredeyse her zaman yanlış bilgi, kodlanmamış özel karakter ya da whitelist'teki eski IP adresinden kaynaklanır. İki yöntemi de destekleyen paketler için proxy hizmetlerimize göz atabilirsiniz.




