Gelişmiş IP & DNS Sızıntı Testi: Ağ Güvenliğinizi Kontrol Edin

Ağ anonimliğiniz analiz ediliyor... Tamamlandığında otomatik olarak yönlendirileceksiniz.
Ağ Yığını Durumu ?
IPv4 ?
Bekleniyor...
IPv4 DNS ?
Bekleniyor...
IPv6 ?
Bekleniyor...
IPv6 DNS ?
Bekleniyor...
Öncelik ?
Bekleniyor...
NAT Türü ?
Bekleniyor...
Vekil Sunucu Gecikmesi
Bekleniyor...
Ağ Jitter Değeri
Bekleniyor...
WebRTC Sızıntısı
Bekleniyor...
DNS Sızıntısı ?
Bekleniyor...
Proxy Durumu
Bekleniyor...
Bölünmüş Tünel
Bekleniyor...
Anonimlik Düzeyi
Bekleniyor...
Tespit Edilen Çıkış IP'leri Sunucular tarafından görülen genel IP adresi
Taranıyor...
Tespit Edilen DNS Sunucuları Alan adı çözümleyicilerinin konumu
View Full DNS Health Check →
Taranıyor...
Ağ Gecikmesi & Hız Testi Tahmini Trafik:10 MB
Bekleniyor...
İndirme
--
Mbps
Yükleme
--
Mbps
Ping
--
ms
Testi başlatmak için trafik katmanına tıklayın:
Bağlantı ve Gecikme Testleri Çalıştırılıyor...

IP ve Ağ Tespiti Hakkında Sıkça Sorulan Sorular

Veri merkezi ve bireysel IP'ler arasındaki farkı, risk puanlama mekanizmalarını ve DNS/WebRTC sızıntı nedenlerini öğrenin.

Birçok kullanıcı, "bireysel proxy" satın almanın kendilerini tipik bir ev kullanıcısı gibi tamamen gizleyeceğine inanır. Ancak modern risk puanlama motorları, GeoIP veritabanlarındaki (IP2Location veya MaxMind gibi) statik sınıflandırma etiketlerinin çok ötesine bakar. Bir çıkış IP'si bir ISP/bireysel adres olarak listelendiğinde bile, iletici proxy ağ geçidi neredeyse her zaman bulutta barındırılan bir Linux sunucusunda çalışır ve katmanlar arası bariz çelişkiler ortaya çıkarır: İlk olarak aktarım protokolü yığın imzaları: çıkış sunucusu ilk SYN el sıkışması sırasında Windows veya Apple seçenekleri yerine Linux standart TCP seçenek sıralamasını (MSS, SACK_PERM, TS, NOP, WS) iletir. İkincisi yol MTU tutarsızlığı: bireysel PPPoE bağlantıları genellikle 1492 MTU (veya hücreselde 1400–1430) sergilerken, yalın veri merkezi Ethernet'i standart 1500'dür (MSS=1460). Dolandırıcılık önleme sistemi bir veri merkezi MTU'su ve Linux TCP yığını eşliğinde bir bireysel IP tespit ettiğinde, bağlantıyı otomatik bir proxy olarak sınıflandırır.

💡 TCP'nizin nerede sonlandığını görmek için bağlantınızı Proxy Anonimlik Testimiz ile test edin.

Bir IP adresi ile fiziksel bir coğrafi konum arasında sabit bir fiziksel bağ yoktur. Konum sonuçları her sitenin kullandığı ticari GeoIP veritabanına ve bunun güncelleme döngüsüne bağlıdır: İlk olarak veritabanı kaynakları ve telemetri modelleri farklılık gösterir — sağlayıcılar (MaxMind, IP2Location, DB-IP gibi) BGP duyurularını, whois kayıt girdilerini ve ağ gecikme problarını farklı ağırlıklandırır ve yenileme aralıkları günlerden aylara kadar değişir. İkincisi Anycast yönlendirme ve CDN uç dağıtımı: Cloudflare gibi sağlayıcılar yüzlerce küresel veri merkezinden aynı IP bloğunu duyurur ve paketinizi en yakın uç noktaya yönlendirir. Üçüncüsü sınır ötesi IP yeniden atamaları: bir barındırma sağlayıcısı bir ülkede kayıtlı bir IP bloğunu başka bir ülkedeki sunuculara yeniden tahsis ettiğinde, güncel olmayan veritabanları geçmiş menşei bildirir. Aracımız gerçek fiziksel bölgeleri doğrulamak için çoklu veritabanı çapraz kontrollerini fiziksel RTT ışık hızı gecikmesi çoklu nirengi yöntemiyle birleştirir.

Bir IP Dolandırıcılık Puanı (veya Risk Puanı), risk motorları tarafından bir bağlantının kötüye kullanım, bot veya maskeleme etkinliğinden kaynaklanma olasılığını ölçmek için kullanılan sayısal bir indekstir (genellikle 0 ila 100). Temel değerlendirme faktörleri şunları içerir: İlk olarak geçmiş itibar ve kötüye kullanım listeleri: IP'nin son 24–72 saatlik pencerelerde kimlik bilgisi doldurma, kazıma, spam gönderme veya tarama yapıp yapmadığı. İkincisi ASN türü ve altyapısı: veri merkezi (barındırma) ve genel proxy/VPN aralıkları bireysel geniş bant veya mobil operatörlere göre daha yüksek taban çizgisi riski taşır. Üçüncüsü çoklu uç nokta ve protokol tutarlılığı: bir oturumun bölünmüş çift yığınlı çıkışlar (IPv4 ve IPv6'nın ayrışması), DNS çözümleyici konumu ayrışması veya WebRTC yerel IP ifşası sergileyip sergilemediği.

💡 Risk puanınızı şişirebilecek yönlendirme sızıntılarını belirlemek için Bölünmüş Tünelleme Testimizi kullanın.

Aktif bir VPN veya proxy olsa bile gerçek kimliğiniz yan bant kanallarından sızabilir: İlk olarak DNS Sızıntıları: tarayıcınız ana bilgisayar adlarını çözümlerken proxy yazılımı işletim sistemi düzeyindeki DNS isteklerini yakalayamazsa, sorgular doğrudan şifresiz olarak yerel ISP DNS sunucunuza gider ve ziyaret edilen alan adlarını ile gerçek konumunuzu ortaya çıkarır. İkincisi WebRTC Sızıntıları: WebRTC gerçek zamanlı eşler arası medya için bir tarayıcı teknolojisidir. Bağlantıları başlatırken HTTP/SOCKS proxy katmanlarını atlar ve doğrudan UDP STUN paketleri göndererek gerçek yerel ve genel IP adreslerinizi ifşa eder. Ana sayfamız DNS çıkışınızı ve WebRTC durumunuzu gerçek zamanlı olarak test eder.

💡 Donanım düzeyinde canvas, ses ve WebRTC sızıntılarını kontrol etmek için Tarayıcı Parmak İzi Testini ziyaret edin.

Ana sayfa ağ yığını paneli paralel olarak üç ilgili prob çalıştırır: biri yalnızca A kayıtlarına sahip bir alan adına ulaşır (iptestv4.myipdns.com), biri yalnızca AAAA kayıtlarına sahip bir alan adına ulaşır (iptestv6.myipdns.com) ve üçüncüsü her iki kayıt ailesine sahip çift yığınlı bir alan adına ulaşır. İlk ikisi zorunludur — her ana bilgisayar adı yalnızca bir adres ailesine çözümlenir ve sisteminize başka seçenek bırakmaz, böylece gerçek çıkış IP'nizi IPv4 ve IPv6 üzerinde bağımsız olarak yakalar. Üçüncü prob zorunlu değildir; bunun yerine sisteminizin kendi kendine hangi adres ailesini seçtiğini gözlemler, bu da "Öncelikli Protokol" sütununda gösterilir: bu sonuç tarafımızdan değil, işletim sisteminiz ve tarayıcınızın adres seçimi politikası (Happy Eyeballs, RFC 8305: çift yığın mevcut olduğunda önce IPv6'yı dene, yalnızca başarısızlık durumunda IPv4'e geri dön) tarafından belirlenir. Her üçünü yan yana koymak kritik öneme sahiptir çünkü birçok proxy ve VPN istemcisi yalnızca IPv4'ü tüneller: IPv4 çıkışınız proxy ASN'sinde bulunurken IPv6 çıkışınız bireysel ISP'nizde kalıyorsa ve tercih edilen protokol IPv6 gösteriyorsa, çift yığınlı web sitelerini ziyaret ederken trafiğinizin çoğu asla tünelden geçmez — bu, "VPN etkin ancak gerçek kimlik ifşa oldu" durumunun en yaygın biçimidir ve kesinlikle hiçbir hata vermez.

⚠ Size yalnızca çift aileli çıkışlarınızın farklı ağlarda sonlanıp sonlanmadığını söyleyebiliriz; proxy yazılımınızın nasıl yapılandırılması gerektiğine karar veremeyiz. Tersine, IPv6'nın kullanılamaz olarak gösterilmesi güvenlik ile aynı anlama gelmez; yalnızca ağınızın IPv6'dan yoksun olduğu veya proxy'nizin IPv6'yı tamamen devre dışı bıraktığı anlamına gelebilir — ikincisi genellikle hedeflenen davranıştır.

Yerel sistem ayarlarınızı okumuyoruz — tarayıcılar bunları kesinlikle okuyamaz ve yerel DNS yapılandırmanızı okuduğunu iddia eden herhangi bir web sayfası yalnızca tahminde bulunmaktadır. Gerçek yaklaşım tersine test etmektir: sitemiz yetkili bir DNS sunucusu çalıştırır ve tarayıcınızın çözümlemesi için her testte benzersiz rastgele bir alt alan adı oluşturur (örneğin k3f9x2ab.leakv4.myipdns.com). Bu ana bilgisayar adı tarihte yalnızca bir kez görünür ve hiçbir önbellekte asla bulunmaz, bu nedenle özyinelemeli çözümleme zinciriniz yetkili sunucumuza kaynağa kadar sorgu yapmak zorundadır; sorguyu gerçekte kimin yaptığını kaydederiz ve ardından bu adresi tarayıcınıza geri göndeririz. Sonuç olarak "DNS Çıkışı" sütunu sistem ayarlarınızda girdiğiniz yukarı akış IP'sini değil, özyinelemeli çözümleyicinizin gerçek giden ağ adresini görüntüler: 8.8.8.8 ayarlarsanız bizi sorgulayan makine o kümedeki belirli bir giden düğüm olacaktır ve bu düğüm pekala farklı bir ülkede bulunabilir; büyük genel çözümleyiciler anycast ve kümelemeye dayanır, bu nedenle tek bir testte birkaç farklı çıkış adresi gözlemlemek tamamen normaldir. Gerçek kriter adreslerin eşleşip eşleşmediği değil, şudur: bu çıkış IP çıkışınız bir proxy'de sonlanırken kendi geniş bant ISP'nizin ağına düşüyorsa — bu DNS sorgularının tüneli takip edemediği anlamına gelir.

⚠ Bu metodoloji yalnızca kendi yetkili sunucumuzu kimin sorguladığını gözlemleyebilir; çözümlediğiniz diğer hiçbir alan adını göremeyiz ve görmüyoruz. Bilinen bir kör nokta da vardır: proxy'niz DNS sorgularını da kesintiye uğratıyorsa gözlemlediğimiz şey proxy sağlayıcısının çözümleyicisidir — yerel ISP'nize sızıntı olmadığını doğrular, ancak DNS sorgu günlüğünüz proxy sağlayıcınız tarafından görünür kalır; bu bu aracın tespit ettiğinin ötesinde ayrı bir husustur.

WebRTC aracılığıyla döndürülen srflx adaylarını toplamak için birden fazla STUN sunucusuna tekli problar gönderilir — yani NAT dönüştürmesinden sonra uzak sunucu tarafından gerçekte gözlemlenen genel IP ve bağlantı noktası. Tek bir belirleyici kriter vardır: adaylar dönüştürülen genel IP'ye göre gruplandırılır; aynı IP altında iki veya daha fazla farklı bağlantı noktası görünüyorsa Simetrik NAT (her farklı hedef için yeni bir eşlenmiş bağlantı noktası atama) olarak sınıflandırılır; aksi takdirde Koni NAT (aynı dahili bağlantı noktasını sürekli olarak aynı harici bağlantı noktasına eşleme) olarak sınıflandırılır. Bağlantı noktalarını karşılaştırmadan önce adayları gruplandırma kasıtlı olarak tanıtıldı: bölünmüş tünelli proxy ortamlarında farklı STUN sunucuları farklı çıkışlar üzerinden yönlendirilebilir ve bu da doğal olarak bağlantı noktalarının ayrışmasına neden olur; ancak bu ayrışma NAT davranışından ziyade yol farklılıklarından kaynaklanır ve gruplandırmanın atlanması tüm bu tür kurulumları Simetrik olarak yanlış teşhis eder. "Bilinmiyor" görüntülenmesinin iki nedeni vardır: birincisi 4 saniyelik zaman aşımı içinde herhangi bir srflx adayı alamamak (tarayıcıda WebRTC devre dışı, uzantılar tarafından engellenmiş veya giden UDP filtrelenmiş); ikincisi genel IP'si bu siteye erişmek için kullanılan giriş IP'si ile eşleşmeyen tek bir aday almak; bu da tarayıcı adayı tekilleştirmesini trafik yönlendirme bölümlerinden ayırt etmeyi imkansız hale getirir, bu nedenle kasıtlı olarak bilinmiyor görüntüleriz.

⚠ Dürüst açıklama: biz yalnızca Koni ve Simetrik NAT arasında ayrım yaparız ve Tam Koni, Kısıtlı Koni veya Bağlantı Noktası Kısıtlı Koni olarak alt sınıflandırma yapmayız. RFC 3489 dört katmanlı modeli tekrarlanan problar genelinde kaynak bağlantı noktaları ve hedef hedeflerin kombinasyonlarını aktif olarak kontrol etmeyi gerektirir ve tarayıcılardaki WebRTC bu tür düşük seviyeli kontroller sağlamaz; web tabanlı araçlar dört kategoriden birini bildirdiğinde genellikle bu iki sonucu yeniden etiketlerler.

Ana sayfadaki bir inceleme birkaç istek grubundan oluşur: IPv4, IPv6 ve farklı HTTP sürümleri genelinde protokol yığını imzalarını toplamak için bu sitenin birkaç alt alan adına bağlanmak; farklı hedeflerin aynı çıkışı görüp görmediğini anlamak için birkaç üçüncü taraf IP sorgulama hizmetini ve WebRTC bileşenini sorgulamak; DNS çözümlemenizi kimin yaptığını görmek için rastgele alt alan adlarını çözümlemek; birkaç konumdan çapraz doğrulama yapmak üzere diğer bölgelerdeki düğümlerimizi yoklamak; ve birkaç popüler web sitesine olan gecikmeyi ölçmek.

⚠ Bunun bedeli, yükleme sırasında reklam engelleyicilerin veya katı gizlilik uzantılarının bazen engellediği pek çok alan adına bağlanmaktır. Etkilenen öğe gri bir nokta gösterir ve bilinmeyen bir durumda kalır; bu öğeyi başka sonuçlarla doldurmayız.