Proxy bağlantısının kurulması tek başına kullanılabilir olduğu anlamına gelmez. Bu rehber beş tekrarlanabilir kontrol sunar: konum ve operatör, konut veya veri merkezi IP’si, bağlantı ve paket kaybı, DNS/WebRTC sızıntıları ve zaman içinde işaretlenme belirtileri.
Proxy yapılandırıldıktan sonra bir sayfada bağlantının kurulduğunu görmek yalnızca ilk adımdır. Ortamın gerçekten kullanılabilir olup olmadığını belirleyen şey, çoğu zaman gözden kaçan ayrıntılardır: çıkış adresi kime ait, adres aralığı konut mu yoksa veri merkezi mi, DNS istekleri nereden gönderiliyor ve WebRTC gerçek adresi açığa çıkarıyor mu?
Aşağıdaki beş kontrolü, somut yöntemlerle birlikte, yaklaşık on dakikada tek tek tamamlayabilirsiniz.
1. Konum ve operatör doğru mu?
Geçerli IP’yi gösteren herhangi bir sayfa açın ve üç şeyi kontrol edin: gösterilen ülke ve şehir istediğiniz bölgeyle eşleşiyor mu, operatör adı satın aldığınız sağlayıcıyla aynı mı ve ASN ilan edilen değerle uyuşuyor mu?
Bu adım yaygın bir sorunu ortaya çıkarabilir: sağlayıcı düğümün Almanya’da olduğunu söyler, ancak gerçek çıkış ABD’dedir. IP veritabanları arasında da farklılıklar olabilir; bu nedenle farklı sorgu siteleri farklı sonuçlar gösterebilir. İki veya üç kaynağı çapraz kontrol edin ve whois kaydındaki kayıtlı kuruluşu esas alın.
IPv6’yı da kontrol edin. Bazı ortamlarda tarayıcı trafiği proxy üzerinden giderken IPv6 hâlâ yerel ağdan çıkabilir. Yalnızca IPv6 test eden bir sayfada sonucun proxy çıkışını gösterdiğini doğrulayın. Hâlâ gerçek adresinizi gösteriyorsa ortam yalnızca kısmen korunuyordur.
2. Konut aralığı mı, veri merkezi aralığı mı?
IP türü, konumdan bile daha kolay gözden kaçar ancak etkisi daha doğrudan olabilir. Konut IP’leri geniş bant operatörlerine kayıtlıdır; veri merkezi IP’leri ise bulut sağlayıcılarının veya IDC’lerin adres aralıklarına aittir. Bu ayrım IP türü veritabanlarında herkese açık şekilde görülebilir.
En basit yöntem ASN için kayıtlı kuruluşu kontrol etmektir. Adında Cloud, Hosting, Data Center veya VPS geçenler genellikle veri merkezi aralıklarıdır; Telecom, Broadband, Cable veya Communications geçenler ise çoğunlukla konut veya ISP aralıklarıdır. Reverse DNS kaydını da inceleyin: konut IP’lerinde genellikle operatörün atadığı ters kayıt bulunur, veri merkezi IP’lerinin PTR kayıtları ise çoğu zaman bulut sağlayıcısının alan adı biçimini izler.
Kendi bulut sunucunuzu proxy olarak kullanıyorsanız çıkış zorunlu olarak veri merkezi IP’si olacaktır. Bu, altyapının doğal sonucudur ve ayarlarla değiştirilemez. Avantajları kararlılık, kontrol ve IP’nin yalnızca size ait olmasıdır; dezavantajı ise IP türüdür. Hangisinin daha önemli olduğu hedef platformun risk kontrollerinin ne kadar sıkı olduğuna bağlıdır: daha gevşek senaryolarda veri merkezi aralığı yeterli olabilir, daha sıkı ortamlarda konut veya ISP proxy’si gerekebilir.
3. Bağlantı ve paket kaybı
Bağlantının olması kararlı olduğu anlamına gelmez. Kısa bir ping testi sorunu göstermeyebilir; bir süre boyunca kesintisiz gözlem gerekir.
Sabit bir hedefe yüzlerce kez sürekli ping veya tekrarlı istek gönderin ve paket kaybı oranı ile gecikme değişimini inceleyin. İdeal sonuç sıfır paket kaybı ve aynı büyüklük düzeyinde kalan gecikmedir. Aralıklı paket kaybı veya büyük gecikme sıçramaları genellikle hat yoğunluğu ya da yetersiz bant genişliğine işaret eder. Sorunlu bölümü bulmak için aşamalı test yapın: önce yerel cihazdan proxy sunucusuna, ardından sunucudan hedef siteye gecikmeyi ölçün. Belirgin biçimde kötü olan bölüm darboğazın bulunduğu yerdir.
Proxy türü de eşleşmelidir. SSH, SOCKS5 ve HTTP rastgele karıştırılamaz; istemcide seçilen protokol, sunucunun gerçekten açtığı protokolle aynı olmalıdır. Aksi halde bağlantı kurulmuş görünse bile trafik geçmeyebilir. Portlar için de aynı kural geçerlidir. SSH’nin 22 numaralı portu gibi varsayılan bir port sağlayıcı tarafından kapalıysa, paroladan şüphelenmeden önce güvenlik duvarı kurallarını düzeltin.
4. DNS veya WebRTC sızıntısı var mı?
Bu iki kontrol, gerçek konumunuzun başka bir kanaldan sızıp sızamayacağını belirler.
DNS sızıntısını kontrol etmek için DNS leak testi destekleyen bir sayfaya gidin ve çözümleme isteklerinin hangi düğümden gönderildiğine bakın. Son resolver hâlâ yerel ağınızdaysa trafiğin proxy’den geçmesi tek başına yeterli değildir: platform DNS çözümleme konumundan gerçek bölgenizi çıkarabilir ve bunu IP konumuyla karşılaştırabilir. Çözüm, ortamda uzak DNS çözümlemesini etkinleştirmek veya DNS’i proxy üzerinden çözebilen bir proxy türü seçmektir.
WebRTC sızıntıları daha gizlidir. Tarayıcılar eşler arası iletişim için yerel ağ arayüzü bilgilerini toplar ve bazı ayarlarda bu işlem proxy’yi atlayarak özel, hatta genel adresi açığa çıkarabilir. Bir WebRTC test sayfası açın ve aday adresler arasında gerçek IP’nizin bulunup bulunmadığını kontrol edin. Varsa tarayıcıda veya ortam ayarlarında WebRTC’yi kapatın ya da yalnızca proxy üzerinden çalışacak şekilde sınırlandırın.
5. Saat dilimi ve dil tutarlı mı?
Çıkış ABD’de görünürken tarayıcı Pekin saatini, Çince dili ve Çinceye göre yazı tipi oluşturmayı kullanıyorsa belirgin bir tutarsızlık oluşur. Saat dilimini, dili ve arayüz bölgesini IP konumuyla uyumlu ayarlayın. Belirli bir şehri özellikle taklit etmeniz gerekmez.
IP’nin zaman içinde işaretlenip işaretlenmediği nasıl anlaşılır?
Önceki kontroller aynı gün tamamlanabilir, ancak IP itibarı yalnızca zaman içinde gözlemlenebilir. Hedef sitede CAPTCHA sıklığının artması, oturum açarken ikinci doğrulamanın daha sık istenmesi, daha önce normal olan işlevlerin kısıtlanması veya ağı değiştirince aynı sitenin hemen normale dönmesi gibi sinyalleri izleyin.
Yalnızca birkaç işlemden sonra doğrulama sık sık tetikleniyorsa genellikle iki neden vardır: IP türü uygun değildir veya adres aralığı daha önce çok sayıda kullanıcı tarafından kullanılmış ve geçmiş biriktirmiştir. Anti-abuse veritabanları aralığın daha önce işaretlenip işaretlenmediğini gösterebilir. Kendi sunucunuzu kullanmanın avantajı burada ortaya çıkar: satın aldığınız günden itibaren IP yalnızca sizin tarafınızdan kullanılır ve temiz bir geçmişle başlar.
Pratikte iki yön vardır: konut proxy’sine geçmek veya daha az kullanıcısı olan bölgesel bir düğüm seçmek.
Yapılandırma gününde izlenecek sıra
- Bir IP sorgu sayfasında konum, operatör ve ASN’yi doğrulayın; ardından IPv6 sızıntısı olup olmadığını kontrol edin
- ASN’nin kayıtlı kuruluşu ve reverse DNS ile aralığın konut mu veri merkezi mi olduğunu belirleyin
- Yüzlerce sürekli istek göndererek paket kaybı ve gecikme değişimini inceleyin; gerekirse bölümler halinde test edin
- DNS leak testi ve WebRTC testiyle gerçek çıkışın açığa çıkmadığını doğrulayın
- Saat dilimi, dil ve arayüz bölgesini IP konumuyla eşleştirin
Sonrasında her bir veya iki haftada bir CAPTCHA ve ikinci doğrulama sıklığını yeniden kontrol edip kaydedin. Bir ekip birden fazla ortamı yönetiyorsa her ortamın çıkışı ve parametreleriyle eşleşmesini sabitlemek önemli ölçüde iş azaltır. PurpleMark gibi araçların çoklu ortam yönetimi bu aşamada kullanılabilir.
Bir proxy’nin çalışması ile uygun olması aynı şey değildir. İlki için doğru yapılandırma yeterlidir; ikincisi için her maddeyi tek tek doğrulamak gerekir. Kontrol edilmeyen noktalar — DNS sızıntıları, WebRTC ve IP türü — fark edilmeden tüm ortamın güvenilirliğini en kolay düşüren unsurlardır.
