Makale içeriği

Giriş: Proxy kusursuz olabilir ama siz yine de görülüyorsunuz

Şu senaryoyu hayal edin. Kaliteli bir mobil proxy satın aldınız, antidetect tarayıcıyı kurdunuz, IP'nizi üç farklı serviste kontrol ettiniz — hepsinde doğru bölgede bir mobil operatör adresi görünüyor. Reklam hesabını açıyorsunuz, hesapları ısıtıyorsunuz, veri kazıyorsunuz. Birkaç gün sonra şüpheli aktivite gerekçesiyle blok yiyorsunuz. Tanıdık geldi mi? Bu tür hikâyelerin en çok göz ardı edilen nedenlerinden biri dns leak, yani DNS sorgularının proxy'yi atlayarak sızmasıdır.

İşin ironik tarafı şu: IP adresi gerçekten değişmiş durumda. Site, trafiği bir mobil operatörden geliyor olarak görüyor. Ama her bağlantıdan önce bilgisayarınız sessizce kendi sağlayıcınıza soruyor: "Falan sunucu nerede?". Ve bu soru doğrudan, proxy devreye girmeden gidiyor. Sonuçta gözlemci tarafta birbirine uymayan iki tablo oluşuyor: bağlantı bir bölgedeki mobil ağdan geliyor, ama isimler tamamen başka bir şehirdeki ev interneti sağlayıcısının çözümleyicisi üzerinden çözülüyor. 2026'nın anti-fraud sistemleri için bu tutarsızlık ufak bir detay değil, en güvenilir sinyallerden biri.

Destek ekibimize gelen başvurulardaki gözlemlerimize göre, "proxy çalışmıyor, geo yanlış çıkıyor, hesaplar sebepsiz uçuyor" şeklindeki şikâyetlerin hatırı sayılır bir kısmı ayrıntılı incelendiğinde aslında proxy sorunu değil. Bu, müşteri tarafındaki DNS katmanının sorunu. Üstelik işe başlamadan önce DNS'i bilinçli olarak test edenlerin sayısı hâlâ azınlıkta — çoğu sadece IP kontrolüyle yetiniyor.

Bu rehberde konuyu baştan sona ele alacağız. İsim çözümlemenin nasıl işlediğini ve tam olarak hangi anda proxy'yi atladığını öğreneceksiniz. DNS açısından HTTP ve SOCKS proxy'ler arasındaki farkı, bağlantı dizesindeki tek bir harfin neden her şeyi belirlediğini ve şifreli DNS'i açan tarayıcıların nasıl yeni bir sızıntı kategorisi yarattığını anlayacaksınız. Dört pratik yöntem sunacağız — teşhis, istemci yazılımı yapılandırması, tarayıcılar ve antidetect'ler, sistem düzeyi — her biri adım adım talimatlar ve kontrol listeleriyle birlikte. Tipik hataları, rakamlarla vakaları inceleyip zor soruları yanıtlayacağız.

Önemli bir sınır: bu makale DNS katmanıyla ilgili. WebRTC üzerinden sızıntılar, tarayıcı parmak izleri, zamanlama ve diğer deanonimizasyon kanalları blogun diğer yazılarında ele alınan ayrı konular. Burada tek ama temel bir kanala odaklanacağız, çünkü bunu anlamadan diğer tüm ayarlar kum üzerine kurulu kalır.

Temeller: DNS nasıl çalışır ve dns leak nedir

İnternetin telefon rehberi

Bir tarayıcı ya da betik bir siteye bağlanmak istediğinde domaine değil, IP adresine ihtiyaç duyar. Domain, insanın anlayacağı bir isimdir. Adres ise ağın anlayacağı koordinatlardır. Birini diğerine çeviren servise DNS (Domain Name System) denir. En basit benzetme telefon rehberidir: ismi bilirsiniz, rehber size numarayı verir. Ancak bu rehber binlerce sunucuya dağılmıştır ve milisaniyeler içinde çalışır.

İsim çözümleme pratikte şöyle görünür:

  1. Uygulama sistem fonksiyonunu çağırır (Unix dünyasında çoğunlukla getaddrinfo), ona domain adını verir.
  2. İşletim sistemi yerel önbelleği ve hosts dosyasını kontrol eder.
  3. Yanıt yoksa, işletim sisteminin stub çözümleyicisi (stub resolver) ağ ayarlarında tanımlı DNS sunucusuna bir sorgu gönderir. Bu genelde DHCP ile atanan sağlayıcınızın sunucusudur ya da elle girdiğiniz bir genel çözümleyicidir.
  4. Sağlayıcının özyinelemeli çözümleyicisi kök sunucular, alan adı bölge sunucuları ve yetkili sunucular zincirini takip eder, yanıtı bulur ve size döndürür.
  5. Uygulama IP'yi alır ve ancak şimdi bağlantıyı kurar.

Sıralamaya dikkat edin. Önce DNS, sonra bağlantı. Proxy, bağlantıya müdahale eden bir araçtır. DNS'e karışıp karışmayacağı ise proxy türüne, protokole ve uygulamanın onu tam olarak nasıl kullandığına bağlıdır.

Asıl sızıntı denen şey

DNS leak, uygulamanın trafiği proxy üzerinden giderken isim çözümleme sorgularının gitmemesi durumudur. Sorgular doğrudan, gerçek ağ arayüzünüzden, sistemde tanımlı çözümleyiciye gider. Sonuç: bağlandığınız site proxy IP'sini görür, ama sağlayıcınız ve çözümleyici sahibi eriştiğiniz tüm domainlerin listesini görür. Hedef servis de belirli koşullar altında bağlantının nereden geldiğiyle DNS sorgusunun nereden geldiğini eşleştirebilir.

Bu neden özellikle mobil proxy kullanıcıları için önemli? Çünkü mobil IP'nin tüm değeri inandırıcılığında. Adres bir mobil operatöre ait, arkasında binlerce gerçek abone var, değişiyor, itibarı iyi. Ama gerçek bir mobil ağ abonesi isimleri aynı operatörün DNS sunucuları üzerinden çözümler. Trafiğiniz mobil ağdan çıkıp isimler başka bölgedeki kablolu sağlayıcı üzerinden çözülürse, gerçek bir aboneye benzemeyi bırakırsınız. Proxy kullanan birine benzemeye başlarsınız. Zaten öylesiniz de — ve bunu kendiniz anlattınız.

Sızıntınızı gören üç rol

  • İnternet sağlayıcınız. Çözümleyicisine yapılan sorguları görür ve içerik proxy üzerinden gitmiş olsa bile hangi domainleri ziyaret ettiğinizi bilir.
  • Çözümleyici sahibi. Genel bir DNS tanımladıysanız, tüm domain listenizi ve gerçek IP'nizi onun operatörü görür.
  • Hedef site ve anti-fraud'u. Doğrudan DNS sorgusunu almaz, ama dolaylı kanalları vardır: yetkili sunucuların coğrafyası, EDNS Client Subnet mekanizması, CDN yönlendirmesi ve belirli bir oturuma özel oluşturulan test domainleri. Bunu bir sonraki bölümde ayrıntılı ele alacağız.

Derinlemesine: Proxy üzerinden çalışırken DNS sızıntısının anatomisi

HTTP proxy: neden genelde sızdırmaz ama istisnalar var

HTTP proxy üzerinden çalışırken tarayıcı ona domainin metin olarak belirtildiği bir istek gönderir. Şifrelenmemiş HTTP için bu, istek satırındaki tam URL'dir. HTTPS için tarayıcı CONNECT komutunu host adı ve portla gönderir, proxy bu ismi kendisi çözer ve tüneli kurar. Her iki durumda da istemcinin hedef sunucunun IP'sini bilmesine gerek yoktur. Çözümlemeyi proxy kendi tarafında, kendi çözümleyicileriyle yapar. Mobil proxy durumunda — modem ya da telefon tarafında, operatörün DNS sunucuları üzerinden. Olması gereken de tam olarak budur.

Peki HTTP proxy ile sızıntılar nereden geliyor? Kaynakları dolaylıdır:

  • PAC betikleri. Proxy otomatik yapılandırma dosyası, isteğin proxy üzerinden gönderilip gönderilmeyeceğine karar vermek için domaini yerel olarak çözen dnsResolve fonksiyonu içerebilir. Karar, yerel DNS sorgusundan sonra verilir.
  • Önceden isim çözümleme. Bazı uygulamalar bağlanmadan önce host erişilebilirliğini kontrol eder: ping atar, çözer, sonra proxy üzerinden gider. InetAddress kullanan Java uygulamaları, bazı kazıyıcılar, bağlantı kontrol eklentileri.
  • Tarayıcının arka plan servisleri. Sayfa ön yükleme, DNS-prefetch, güvenli gezinme ve güncelleme kontrolleri kendi kurallarıyla çalışabilir ve proxy ayarlarına her zaman uymayabilir.

SOCKS: temiz oturumla sızıntı arasındaki tek harf

İşin en ilginç kısmı burada başlıyor. SOCKS4 protokolü orijinal hâliyle proxy'ye yalnızca hedef IP adresini iletebilir. Bu, istemcinin bağlanmadan önce ismi kendisinin çözmesi gerektiği anlamına gelir. Sızıntı protokolün içine gömülüdür. SOCKS4a uzantısı host adını iletme olanağını ekledi. SOCKS5 üç tür hedef adres destekler: IPv4, IPv6 ve domain adı.

Görünüşe göre SOCKS5 sorunu çözüyor. Ama protokoldeki domain adı desteği, istemcinin onu kullanacağı anlamına gelmez. Birçok kütüphane ve program varsayılan olarak ismi yerel çözer ve proxy'ye hazır IP'yi gönderir. Protokol buna izin verir — sızıntı sadece bir adım önce gerçekleşir.

Meşhur h harfi buradan gelir. curl'de ve onun geleneğini izleyen kütüphanelerde socks5:// şeması yerel isim çözümleme, socks5h:// ise ismi uzaktan çözümlemesi için proxy sunucusuna iletmek anlamına gelir. Tek harf. DNS dahil her şeyin operatörün mobil ağından çıktığı temiz bir oturumla her ismin önce sağlayıcınıza sızdığı bir oturum arasındaki fark.

Proxy sunucusunun kendisinin çözümlemesi neden daha iyi

Burada çoğu kişinin kaçırdığı, pek bariz olmayan bir nokta var. Mesele sadece gizlilik değil. İsmi mobil proxy'nin uzak tarafı çözdüğünde, DNS yanıtı operatörün konumuna göre şekillenir. Büyük servisler CDN ve geo-DNS kullanır: aynı domaine farklı istemcilere kendilerine en yakın farklı IP'ler döner. Ev sağlayıcınız çözerse, gerçek konumunuza yakın bir CDN düğümünün adresini alırsınız. Sonra başka bölgedeki mobil proxy üzerinden o düğüme bağlanırsınız. Servis için bu tuhaf görünür: A bölgesinin mobil ağından gelen bir istemci nedense B bölgesi için ayrılmış bir düğüme gelmiş. İşte bu, DNS sorgularınıza hiç erişim gerektirmeyen dolaylı dns leak tespit kanalıdır.

EDNS Client Subnet: çözümleyici alt ağınızı nasıl dağıtıyor

EDNS Client Subnet (ECS) mekanizması, genel çözümleyicilerin yetkili sunuculara istemci adresinin bir kısmını — genelde IPv4 için ilk 24 biti — iletebilmesi için tasarlandı. Böylece CDN gerçek kullanıcının nereden geldiğini anlar ve en yakın düğümü verir. Hız açısından kullanışlıdır. Ama sızıntı açısından bu, ECS destekli genel DNS üzerinden yerel çözümleme yapıldığında hedef domainin yetkili sunucusunun gerçek bağlantınızın alt ağını aldığı anlamına gelir. Tam adres değil, ama sağlayıcıyı ve şehri anlamaya yeter. Bağlantı ise sonradan mobil IP'den gelir. İki alt ağ, iki operatör, tek kullanıcı.

Şifreli DNS: yeni bir sızıntı kategorisi

2020'lerden bu yana tarayıcılar ve işletim sistemleri toplu hâlde DNS over HTTPS (DoH) ve DNS over TLS (DoT) kullanımına geçti, 2026'ya gelindiğinde DNS over QUIC de eklendi. Fikir iyi niyetli: sağlayıcı artık sorgularınızı görmüyor. Ama proxy üzerinden çalışırken bir yan etki doğdu. "Güvenli DNS" açık bir tarayıcı, seçilen DoH sunucusuna kendi istemcisiyle başvurur ve bu trafik proxy ayarlarına her zaman uymaz. Yani isimler mobil operatörde değil, büyük bir genel çözümleyicide, üstelik gerçek IP'nizle çözülür. Şifreleme sağlayıcıdan korur ama DNS tarafıyla bağlantı tarafı arasındaki tutarsızlıktan korumaz.

Ek bir karmaşıklık katmanı da Encrypted Client Hello (ECH) ekler. Çalışması için tarayıcı DNS'te özel HTTPS kayıtları sorgular. Ne kadar çok site ECH kullanırsa tarayıcı o kadar çok DNS sorgusu yapar — ve DNS doğru yoldan gitmediğinde o kadar çok sızıntı fırsatı doğar.

IPv6 ve Happy Eyeballs

Modern sistemler aynı anda A (IPv4) ve AAAA (IPv6) kayıtlarını sorgular ve daha hızlı yanıt verene bağlanmayı dener — Happy Eyeballs algoritması. Gerçek ağınız IPv6 destekliyor ama proxy yalnızca IPv4 üzerinden çalışıyorsa, bazı uygulamalar doğrudan IPv6 üzerinden, proxy'yi tamamen atlayarak gidebilir. Kesin konuşmak gerekirse bu dns leak değil, bağlantı sızıntısıdır, ama tetikleyici tam da AAAA kayıtlı DNS yanıtıdır. Bu yüzden DNS hijyeni bağlamında IPv6'nın akılda tutulması gerekir.

Önbellek ve hosts: geçmişten gelen sızıntı

İşletim sistemi DNS yanıtlarını önbelleğe alır. Proxy'siz çalıştıysanız ve sonra proxy'yi açtıysanız, bazı isimler zaten ev çözümleyiciniz üzerinden alınan adreslerle önbellekte duruyordur. Yeni sorgu olmaz ama bağlantılar "ev" CDN düğümlerine gider. Benzer şekilde hosts dosyası: içindeki kayıtlar isim çözümlemeyi tamamen değiştirir ve proxy bunu öğrenmez.

Yöntem 1. Teşhis: dns leak nasıl kendi elinizle test edilir

Bir şeyi yapılandırmadan önce sorunu görmek gerekir. İyi haber: DNS sızıntısı testi beş dakikalık bir işlemdir ve her çalışma oturumundan önce ritüele dönüştürülebilir, dönüştürülmelidir.

Çevrimiçi testler nasıl çalışır

Her dns leak test servisi aynı mantıkla çalışır. Sayfa rastgele-dize.test-domaini biçiminde birkaç benzersiz alt alan adı üretir ve tarayıcınıza bunları çözdürür, genelde görünmez resim ya da betik yükleyerek. Alt alan adları benzersiz olduğundan hiçbir önbellekte yoktur. Sorgu mutlaka test domaininin servise ait yetkili sunucusuna ulaşır. Servis, sorgunun hangi IP'den geldiğini kaydeder — bu kullandığınız özyinelemeli çözümleyicinin adresidir. Sonra sayfa size iki sütun gösterir: HTTP bağlantısının geldiği adres ve çözümleyici adresleri. Bağlantı mobil operatörden, çözümleyici ise ev sağlayıcısına ya da genel bir DNS servisine aitse sızıntı vardır.

Şunu iyi anlamak gerekir: herhangi bir site de tam olarak bunu yapabilir. Mekanizma özel yetki gerektirmez. Büyük platformların anti-fraud sistemleri benzer teknikleri oturum risk değerlendirmesinin parçası olarak kullanır. Bu bir komplo teorisi değil, standart mühendisliktir.

Adım adım test prosedürü

  1. Temel çizgiyi kaydedin. Proxy'yi kapatın, dns leak testini açın, hangi çözümleyicilerin göründüğünü yazın. Bu sizin "ev" parmak izinizdir. Bir bakışta tanımanız gerekir.
  2. DNS önbelleğini temizleyin. Windows'ta ipconfig /flushdns, macOS'ta mDNSResponder servisini yeniden başlatma, Linux'ta çözümleyiciye bağlı (örneğin systemd-resolved için resolvectl flush-caches). Tarayıcıyı yeniden başlatın — kendi önbelleği vardır.
  3. Proxy'yi açın gerçekten çalışacağınız şekilde: antidetect profili, eklenti, sistem ayarları ya da kod üzerinden.
  4. Bir değil onlarca kontrol yapan genişletilmiş testi çalıştırın. Sızıntı kısmi olabilir: on sorgudan dokuzu proxy üzerinden gider, onuncusu doğrudan. Tek test bunu kaçırır.
  5. Karşılaştırın. Tüm çözümleyiciler proxy'nin çalıştığı mobil operatöre ya da proxy servisinin altyapısına ait olmalı. Temel çizgiden tek bir adres bile olmamalı. Bilinçli seçmediğiniz hiçbir genel çözümleyici olmamalı.
  6. IPv6'yı ayrıca kontrol edin. Test proxy'ye ait olmayan herhangi bir IPv6 adresi gösteriyorsa — sızıntı.
  7. On dakikalık çalışmadan sonra tekrarlayın. Bazı arka plan süreçleri gecikmeli başlar.

Üçüncü taraf servis olmadan test: kendi test domaininiz

Hesap çiftlikleri ya da endüstriyel ölçekte veri kazıma yapanlar için kendi aracına sahip olmak mantıklıdır. Şema şöyle: ucuz bir domain alıp VPS'inizde sorgu kaydı açık bir yetkili DNS sunucusu kurarsınız. Sonra herhangi bir projede, her oturum başlangıcında oturum-kimliği.sizin-domaininiz biçiminde benzersiz bir alt alan adına başvurursunuz. DNS sunucusunun kaydında şu belirir: hangi alt alan adı sorgulandı ve hangi çözümleyici IP'sinden geldi. Oturum kimliğiyle eşleştirip hangi oturumun, hangi profilin, hangi worker'ın sızdırdığını anında görürsünüz. Bu, tek seferlik testi sürekli izlemeye dönüştürür.

Düşük seviyeli kontrol: ağa bakmak

En dürüst yol, ağ arayüzünden gerçekte ne çıktığına bakmaktır. Makinenin fiziksel arayüzünde bir trafik analizörü (Wireshark ya da tcpdump) çalıştırın ve 53 numaralı UDP ve TCP portunu, ayrıca DoT için 853 portunu filtreleyin. Sonra beş dakika proxy üzerinden çalışın. İdeal dünyada filtre boş kalır: tüm isimler proxy tarafında çözülür, yerel DNS paketi hiç yoktur. Paket varsa hangi domainlerin nereye gittiğini hemen görürsünüz. DoH'ta filtre daha karmaşıktır çünkü 443 portunda sıradan bir HTTPS'tir, ama ipucu olarak proxy üzerinden gitmeyen, tanıdık genel DoH sağlayıcılarına yapılan bağlantılar göze çarpar.

Teşhis kontrol listesi

  • Proxy'siz temel çizgi kaydedildi.
  • Testten önce işletim sistemi ve tarayıcı önbelleği temizlendi.
  • Onlarca sorguluk genişletilmiş test yapıldı.
  • Tüm çözümleyiciler proxy tarafına uygun.
  • Yabancı ağa ait IPv6 adresi yok.
  • 10 dakikalık çalışmadan sonraki tekrar testi geçildi.
  • Kritik projeler için: 53 portundaki trafik analizörü sıfır paket gösteriyor.

Yöntem 2. İstemci yazılımı ve kodun doğru yapılandırılması

Sızıntıyı buldunuz. Şimdi uygulamanın tam olarak nerede ismi yerel çözme kararı aldığını anlayıp onu uzak çözümlemeye geçirmeniz gerekiyor. Trafik uzmanı ve geliştiricilerin pratiğinden en yaygın ortamları ele alalım.

İlke: host adı proxy'ye ulaşmalı

Kural tek ve evrenseldir. Proxy sizden domain adını almalı, IP'yi değil. HTTP proxy için bu doğal olarak gerçekleşir. SOCKS5 için uzaktan DNS modunu açıkça seçmeniz gerekir. Uzantı olmadan SOCKS4 için bu ilke gereği imkânsızdır — bu proxy'ler temiz çalışma için uygun değildir. Modern servislerin mobil proxy'leri hem HTTP hem de uzaktan çözümlemeli SOCKS5 destekler, dolayısıyla kısıtlama yalnızca istemci tarafındadır.

curl ve komut satırı

SOCKS5 için her zaman h harfli şemayı kullanın. Doğru çağrı örneği:

curl -x socks5h://user:pass@host:port https://example.com/

h harfi olmadan curl ismi yerel çözer. Bu, libcurl üzerine kurulu tüm araçlar için de geçerlidir. HTTP proxy için -x parametresindeki http:// şeması yeterlidir: isim CONNECT isteğinde gidecektir.

Python: requests, httpx, aiohttp

SOCKS destek paketi kurulu requests kütüphanesinde de aynı kural geçerlidir: socks5:// yerel çözümleme, socks5h:// uzak çözümleme demektir. Bu, kazıyıcılardaki en yaygın hatadır: geliştirici belgelerden socks5 yazan bir örnek kopyalar ve yıllarca farkında bile olmadan dns leak'li trafik döndürür. httpx ve aiohttp'te SOCKS desteği üçüncü taraf taşıma katmanlarıyla sağlanır ve uzak çözümleme modunu ilgili taşıma katmanının belgelerinden kontrol etmeniz gerekir — bazısında rdns parametresidir, bazısında yine h harfli şemadır. Belgelerden değil, gerçekten kontrol edin: betiği kendi test domaininize karşı çalıştırıp kayda sorgunun nereden geldiğine bakın.

Ayrı bir tuzak da tüm trafiği SOCKS üzerinden geçirmek için standart socket modülünü monkey-patch'leyen düşük seviyeli soket kütüphaneleridir. Uzak çözümleme bayrakları vardır, ama varsayılan olarak pek çok kez kapalıdır. Üstüne kodunuzdaki ya da bağımlılıklarınızdaki her socket.gethostbyname çağrısı bunu atlayıp ismi sistem çözümleyicisi üzerinden çözer.

Node.js ve headless tarayıcılar

Node.js ekosisteminde SOCKS ajanları genelde host adını proxy'ye iletir, ama bu kullandığınız pakete ve sürüme bağlıdır. Puppeteer ve Playwright için proxy tarayıcı başlatma düzeyinde tanımlanır ve davranış Chromium motorundan miras alınır — SOCKS5'teki özelliklerini bir sonraki bölümde konuşacağız. Mobil proxy'nin HTTP moduyla çalışıyorsanız soru ortadan kalkar: Chromium host adıyla CONNECT gönderir.

Go, Java ve diğer diller

Go'da golang.org/x/net/proxy standardı SOCKS5 için host adını uzaktan iletir, ama yalnızca Dialer'ı doğrudan kullanırsanız, önceden çözmezseniz. Java'da SOCKS proxy için sistem özellikleri çalışır, ama birçok HTTP istemcisi önceden çözümlemeli bir InetSocketAddress nesnesi oluşturur ve sızıntı buradan çıkar. Çözüm — çözümlenmemiş adres oluşturmak (createUnresolved benzeri metotlar) ve istemcinin isim iletimini desteklediğinden emin olmak. Her dil için evrensel tavsiye: kodda ve bağımlılıklarda domainin IP'ye dönüştüğü tüm yerleri bulun ve bunun proxy bağlantısından sonra gerçekleştiğinden emin olun, öncesinde değil.

Adım adım proje denetimi

  1. Kodda proxy bağlantı dizelerinin tüm satırlarını bulun. Şemaları kontrol edin: h'siz socks5 — kırmızı bayrak.
  2. Açık isim çözümleme çağrılarının tümünü bulun: gethostbyname, getaddrinfo, dns.lookup, InetAddress.getByName. Her biri potansiyel sızıntı.
  3. Bağımlılıkları kontrol edin: erişilebilirlik kontrol kütüphaneleri, health-check, önceden ping atan retry'lar.
  4. Projeyi her worker için benzersiz alt alan adıyla kendi test domaininize karşı çalıştırın. DNS sunucusu kaydı kimin sızdırdığını gösterecek.
  5. Otomatik test ekleyin: DNS kontrolü çözümleyicinin proxy tarafına ait olduğunu doğrulamadıkça oturum geçerli sayılmaz.
  6. Sonucu proje belgelerine işleyin: hangi kütüphane, hangi sürüm, hangi mod.

Geliştirici kontrol listesi

  • Tüm SOCKS5 bağlantıları uzaktan çözümleme kullanıyor.
  • Bağlantı öncesi ön çözümleme yok.
  • Kütüphaneler belgelerden değil, test domaini kaydından doğrulandı.
  • Oturum başlangıcına otomatik DNS kontrolü entegre edildi.
  • Proxy'nin HTTP modu için IP ikamesi değil, CONNECT kullanıldığı doğrulandı.

Yöntem 3. DNS sızıntısız tarayıcılar ve antidetect tarayıcılar

Mobil proxy kitlesinin büyük kısmı kodda değil tarayıcıda çalışır: reklam hesapları, sosyal ağlar, pazaryerleri, çoklu hesap yönetimi. Burada kendi kuralları vardır ve motordan motora farklılık gösterir.

Firefox ve türevleri

Firefox tarihsel olarak en şeffaf kontrolü sunar. about:config'teki kilit parametre network.proxy.socks_remote_dns'tir. true değeri isimlerin uzaktan çözümleme için SOCKS proxy'ye iletilmesini sağlar. false ise yerel çözümleme demektir. Birçok eski derlemede ve profilde kapalıdır. İkinci parametre şifreli DNS'i yöneten network.trr.mode'tur: 5 değeri onu tamamen kapatır, bu proxy üzerinden çalışmak için tercih edilir çünkü aksi hâlde tarayıcı kendi istemcisiyle DoH sunucusuna başvurabilir. Üçüncü blok ön yükleme: network.dns.disablePrefetch true ve network.predictor.enabled false, sayfadaki bağlantılar için spekülatif isim çözümlemeyi kapatır; aksi hâlde gerçek geçişten önce proxy dışına çıkabilir. Firefox motorlu antidetect tarayıcılar bu parametreleri genelde doğru ayarlar, ama her güncellemeden sonra kontrol etmeye değer.

Chrome, Chromium ve türevi antidetect'ler

Chromium'da mesele daha karışık. HTTP proxy üzerinden çalışırken isimle CONNECT gönderir — sızıntı yok. Ama başlatma bayrağı üzerinden SOCKS5 proxy kullanırken motor bazı yapılandırmalarda isimleri yerel çözer ve arayüzde standart bir "uzaktan DNS" ayarı yoktur. Bilinen mühendislik hilesi, tüm isimleri "bulunamadı" durumuna eşleyip proxy adresinin kendisini hariç tutan bir kural içeren --host-resolver-rules bayrağıdır. Sonuçta yerel çözümleyici hiçbir şeyi çözemez ve tarayıcı isimleri proxy'ye iletmek zorunda kalır. Yamalı görünür ama güvenilir çalışır. İkinci önemli nokta, gizlilik bölümündeki güvenli DNS ayarı: açık olduğunda Chromium seçilen sağlayıcıya DoH yapar ve bu trafik her zaman proxy'ye uymaz. Mobil proxy üzerinden çalışmak için kapatılmalı ya da testlerle doğru tünellendiğinden emin olunmalı. Üçüncüsü sayfa ön yükleme: performans ayarlarında, henüz tıklamadığınız bağlantılar için DNS sorgularını başlatan bir ön yükleme seçeneği vardır.

İyi bir antidetect tarayıcının yapabilmesi gerekenler

İyi bir antidetect tüm bu rutini üstlenir. Ama uygulama kalitesi çok farklıdır. Seçerken ve her güncellemeden sonra kontrol edilmesi gerekenler:

  • SOCKS5 için uzaktan DNS modu her profil için varsayılan olarak açık, genel değil.
  • Profiller arası DNS izolasyonu. Çözülmüş isimlerin önbelleği ortak olmamalı: aksi hâlde bir bölgenin mobil proxy'sindeki profil başka bir bölgenin proxy'sindeki profilin önbelleğe aldığı IP'yi alır.
  • Kapalı ya da tünellenen şifreli DNS. Doğrudan destek ekibine sorun: proxy üzerinden çalışırken dahili DoH nasıl davranıyor.
  • Kapalı prefetch. Spekülatif çözümleme, sıradan bir mobil kullanıcı taklidi yapan profilde bulunmamalı.
  • Yerleşik kontrol profil başlangıcında dns leak ya da en azından teste kolay erişim.
  • Proxy koptuğunda davranış. Proxy erişilemezse tarayıcı ne yapıyor: bağlantıları bloke mi ediyor, doğrudan mı gidiyor? İkincisi sadece DNS için değil, her şey için felakettir.

Proxy eklentileri: ince buz

Proxy'yi değiştiren tarayıcı eklentileri tarayıcı API'si üzerinden çalışır. Bağlantılar için proxy atayabilirler, ama DNS üzerindeki kontrolleri motorun olanaklarıyla sınırlıdır. Bir eklenti, motor belirli yapılandırmada bunu yapmıyorsa Chromium'u SOCKS5 için uzaktan DNS kullanmaya zorlayamaz. Üstüne tarayıcının arka plan servislerini de yönetemez. Bu yüzden eklentiler mobil proxy'nin HTTP modu ve hızlı kontroller için kabul edilebilir bir seçenek, ama hassas hesaplarla ciddi çalışma için değil.

Adım adım profil yapılandırması

  1. Profil oluşturun ve mobil proxy'yi tanımlayın. Antidetect SOCKS5 için uzaktan DNS'i garanti etmiyorsa HTTP modunu tercih edin.
  2. Motor ya da profil ayarlarında şifreli DNS'i kapatın.
  3. Sayfa ön yükleme ve DNS-prefetch'i kapatın.
  4. Firefox benzeri bir motorsa socks_remote_dns'i elle kontrol edin.
  5. Profili başlatın, önbelleği temizleyin ve genişletilmiş dns leak testinden geçin.
  6. Aktif analitikli birkaç siteyi gezdirin ve testi tekrarlayın: yeni çözümleyici belirdi mi.
  7. Sonucu bu profilin referans değeri olarak kaydedin.

Yöntem 4. Sistem düzeyi ve altyapı: sızıntıları zorla kapatmak

Önceki yöntemlerin hepsi güven ilkesiyle çalışır: uygulamayı yapılandırırız ve doğru davranmasını umarız. Mühendislik yaklaşımı farklıdır: sızıntıyı teknik olarak imkânsız kılmak. Uygulama doğrudan DNS sorgusu göndermeye çalışsa bile gitmemelidir.

"Proxy dışında her şey yasak" ilkesi

Çalışma makinesinde ya da çiftlik sunucusunda, açıkça izin verilenler dışındaki tüm süreçler için 53 (UDP ve TCP) ve 853 portlarına giden trafiği bloke eden bir güvenlik duvarı kurulur. Windows'ta güvenlik duvarındaki giden bağlantı kuralları, Linux'ta nftables ya da iptables, macOS'ta pf. Mantık: tarayıcı ya da betik ismi yerel çözmeye kalkarsa sessiz sızıntı yerine hata alır. Hata hemen fark edilir, görürsünüz ve uygulama yapılandırmasını düzeltirsiniz. Sessiz sızıntı aylarca yaşayabilir.

DoH ile ilgili incelik: 443 portunda çalışır, o portu tamamen kapatmak olmaz. Çözüm — port yerine, yalnızca proxy üzerinden gitmesi gereken süreçler için bilinen genel DoH çözümleyicilerinin adreslerini bloke etmektir. Liste bakımı gerektirir, ama liste nadiren değişir.

Konteynerler ve ağ ad alanlarıyla izolasyon

Linux'taki geliştiriciler ve çiftlik sahipleri için en güçlü araç ağ ad alanları (network namespaces) ve konteynerlerdir. Fikir: her worker, her tarayıcı profili ya da profil grubu, dış internete varsayılan rotası hiç olmayan kendi ağ ad alanında yaşar. Dışarıya tek yol proxy adresidir. Uygulama ne yapmaya çalışırsa çalışsın — ismi çözmek, IPv6 üzerinden çıkmak, doğrudan bağlantı açmak — fiziksel olarak rotası yoktur. Bu, ölçekte dns leak olmadığını garanti etmenin en güvenilir yoludur. Docker'da dış ağ geçidi olmayan kullanıcı ağı artı yalnızca proxy adresine açık erişimle sağlanır. Ek olarak konteynerin çözümleyici yapılandırmasına kasıtlı olarak erişilemez bir adres yazılabilir; böylece yerel çözümleme denemesi zaman aşımına takılmadan anında çöker.

Sistem düzeyinde IPv6

Mobil proxy'niz IPv4 üzerinden çalışıyor ama makinenin IPv6 bağlantısı varsa en basit ve güvenilir çözüm — proxy profillerinin çalıştığı arayüzde IPv6'yı devre dışı bırakmak ya da güvenlik duvarıyla giden IPv6'yı yasaklamaktır. Evet, kaba bir yöntem. Ama DNS yanıtındaki AAAA kaydının bağlantıyı doğrudan başka yere götürdüğü bütün bir sorun sınıfını ortadan kaldırır.

Sistem çözümleyicisi ve özellikleri

Modern işletim sistemlerinde çok katmanlı çözümleyiciler vardır. Windows 11'de sistem düzeyinde DoH desteği var ve adaptörünüz için açıksa tüm yerel çözümlemeler seçili DoH sunucusuna gider. Proxy'li çalışma makinesi için bunun farkında olmak gerekir: açık sistem DoH'u sızıntı tablosunu değiştirir ama ortadan kaldırmaz. Android Private DNS özelliğini kullanır — mobil cihazlarda ya da emülatörlerde proxy'yle çalışanlar için benzer bir durum. systemd-resolved'lı Linux'ta her arayüze hangi DNS sunucularının atandığını kontrol etmeye değer, çünkü çözümleyici sorguları domain soneklerine göre arayüzler arasında yönlendirebilir ve bu beklenmedik yollar yaratır.

Süreç olarak izleme

Altyapı düzeyinde dns leak kontrolü tek seferlik olmaktan sürekli bir hâle dönüşür. Uygulanmaya değer olanlar:

  • Güvenlik duvarının bloke ettiği DNS denemelerinin kaydı. Kayıttaki her satır, yerel çözmeye çalışan bir uygulamadır. Bu, düzeltilecekler listenizdir.
  • Oturum başına benzersiz alt alan adlarıyla kendi test domaininiz ve yabancı çözümleyici belirdiğinde otomatik uyarı.
  • Fiziksel arayüzde 53 portundaki ağ trafiğinin periyodik anlık görüntüsü — günde bir, otomatik, sıfırdan farklı sayaçta uyarıyla.
  • Her güncellemeden sonra kontrol — tarayıcı, antidetect, kütüphaneler. Güncellemeler en büyük gerileme kaynağıdır: geliştiriciler varsayılanları değiştirir, yeni ön yükleme özellikleri açar, şifreli DNS ekler.

Sistem düzeyi kontrol listesi

  • Çalışma süreçleri için 53 ve 853 portlarına giden trafik bloke.
  • Aynı süreçler için bilinen genel DoH adresleri bloke.
  • Çalışma arayüzlerinde IPv6 kapalı ya da bloke.
  • Kritik worker'lar doğrudan rotası olmayan ağ ad alanlarında izole.
  • Güvenlik duvarının DNS kayıtları toplanıyor ve inceleniyor.
  • Test domaini ve uyarı sistemi kurulu.

Tipik hatalar: yapılmaması gerekenler

Hata 1. Yalnızca IP'yi kontrol etmek

En yaygını. Kişi IP kontrol sayfasında mobil operatör adresini görür ve işi bitti sanır. Ama IP kontrolü yalnızca "bağlantı nereden geldi" sorusunu yanıtlar, "DNS sorguları nereden geldi" sorusunu değil. Bunlar farklı sorulardır ve yanıtları da farklıdır.

Hata 2. Genel DNS tanımlayıp rahatlamak

Mantık anlaşılır: sağlayıcı sorgularımı görüyorsa, genel çözümleyici tanımlarım. Ama proxy üzerinden çalışmak için bu çözüm değil, bir sızıntıyı başkasıyla değiştirmektir. Sorgular yine gerçek IP'nizden çıkar, bu sefer başka bir gözlemciye. Üstüne genel çözümleyiciler ECS'i yoğun kullanır ve alt ağınızı yetkili sunuculara iletir. DNS tarafıyla bağlantı tarafı arasındaki tutarsızlık kalır.

Hata 3. Uzaktan DNS olmadan SOCKS5 kullanmak

Kodda socks5h yerine socks5 şeması, tarayıcıda kapatılmış socks_remote_dns, varsayılan yerel çözümlemeli antidetect. Binlerce proje bu hatayla yıllarca yaşıyor.

Hata 4. Şifreli DNS'i sorunun çözümü sanmak

DoH sorgu içeriğini sağlayıcıdan korur. Ama proxy üzerinden çalışırken proxy'den geçmeyen ayrı bir kanal yaratır. Şifreleme doğru yönlendirme demek değildir.

Hata 5. Ön yükleme ve arka plan servislerini görmezden gelmek

Tarayıcı henüz açmadığınız bağlantıların isimlerini çözer. Antivirüs URL'yi kontrol eder. Güncelleyici güncelleme sunucusunu arar. Hepsi dışarıdan geçebilecek DNS sorgularıdır. Tek testle kontrol bunları yakalamaz.

Hata 6. Profiller arası ortak DNS önbelleği

Farklı bölgelerin proxy'sindeki iki profil önbelleği paylaşıyorsa, ikinci profil birinci bölge için seçilen CDN düğümüne bağlanır. Profil izolasyonu DNS'i de kapsamalıdır.

Hata 7. Güncellemelerden sonra test etmemek

Yeni tarayıcı sürümü varsayılan olarak güvenli DNS'i açtı. Güncellenen kütüphane SOCKS davranışını değiştirdi. Antidetect güncellemesi motor ayarlarını sıfırladı. Hepsi yalnızca tekrarlı kontrolle ortaya çıkan gerçek senaryolar.

Hata 8. Proxy erişilemezse doğrudan çıkışa izin vermek

"Proxy yanıt vermezse doğrudan git" türü ayarlar her arızayı, DNS'ten başlayarak tam deanonimizasyona çevirir. Doğru davranış — proxy düzelene kadar bağlantıları bloke etmek.

Hata 9. "Hız için" elle çözümleme

Bazı kazıyıcılar DNS'ten tasarruf etmek için domaini bir kez çözer ve ardından IP üzerinden gider. Sorgunun sızması bir yana, gerçek bölgeleri için geo-DNS tarafından seçilmiş bir IP alır, sonra o trafiği mobil proxy üzerinden "yabancı" CDN düğümüne gönderirler. Milisaniye tasarrufu tutarsız bir profile dönüşür.

Araçlar ve kaynaklar

Çevrimiçi sızıntı testleri

dns leak kontrol servisleri temel ve genişletilmiş olarak ikiye ayrılır. Temeller bir iki sorgu yapar, hızlı ön değerlendirme için yeterlidir. Genişletilmişler onlarca benzersiz alt alan adı üretir ve kısmi sızıntıları ortaya çıkarır. Çalışma için yalnızca çözümleyici IP'sini değil, kuruluşunu, otonom sistemini, ülkesini de gösterenleri seçin. İyi test ayrıca IPv4 ve IPv6'yı ayrı gösterir ve tekrarlı sorgularda davranışı kontrol edebilir.

Trafik analizörleri

Wireshark — dns ya da udp.port == 53 gibi filtreleri olan grafiksel analizör. tcpdump — sunucular ve Linux makineleri için konsol karşılığı. İkisi de gerçeği gösterir: ağ arayüzünden gerçekte ne çıkıyor. DoH için ek olarak genel çözümleyici adreslerine yapılan TLS bağlantılarına bakın.

Kendi yetkili DNS'iniz

Ölçekte izleme için: sorgu kaydı olan herhangi bir hafif DNS sunucusu (CoreDNS, yetkili modda Unbound, BIND, Go ya da Python'da kompakt sunucular) artı kendi domaininiz. Maliyet asgaridir, sonuç ise tüm worker'lar ve profiller üzerinde sürekli gözetimdir.

Komut satırı araçları

dig ve nslookup sistemin hangi çözümleyiciye başvurduğunu ve ne yanıt verdiğini gösterir. Linux'ta systemd-resolved'lı resolvectl arayüzlere göre DNS yapılandırmasını gösterir. Ayrıntılı çıktı bayraklı curl ismi proxy'ye iletip iletmediğini yoksa kendi mi çözdüğünü gösterir. Windows'ta ipconfig /displaydns önbellek içeriğini, PowerShell'de Get-DnsClientServerAddress adaptörlere atanmış sunucuları gösterir.

Güvenlik duvarları

Program bazlı kuralları olan yerleşik Windows güvenlik duvarı, Linux'ta nftables ve iptables, macOS'ta pf. Kuralları uygulamaya göre yönetmek için grafik üst katmanlar vardır. Temel gereksinim — belirli süreçler için portları bloke edebilme ve bloke kaydı tutabilme.

Konteynerleştirme

Kullanıcı ağlarıyla Docker ve Podman, ip netns üzerinden Linux ağ ad alanları ve tarayıcı çiftlikleri için profil düzeyinde ağ izolasyonunu destekleyen profil orkestratörleri. "Yalnızca proxy üzerinden" kuralını ayardan mimari garantiye dönüştürürler.

Proxy servisi tarafındaki olanaklar

Mobil proxy sağlayıcısının sunduğu şeylere dikkat edin: uzaktan isim çözümlemeli SOCKS5 desteği, CONNECT'i doğru işleyen HTTP modu, operatör tarafında DNS kararlılığı, altyapı tarafında DNS yanıtı ikamesinin yokluğu. Uzaktan çözümlemede isimlerin hangi çözümleyiciler üzerinden çözüldüğünü destek ekibinden sormakta fayda var — doğru yanıt: modemin bağlı olduğu mobil operatörün çözümleyicileri üzerinden.

Vakalar ve sonuçlar

Vaka 1. Reklam hesabı çiftliği ve görünmez ban nedeni

Bir trafik uzmanı ekibi popüler bir antidetect üzerinden mobil proxy'lerle yaklaşık 120 reklam hesabı yönetiyordu. Hesap başına bloka kadar ortalama ömür, görünüşte kusursuz yapılandırmayla 9-12 günde kalıyordu: doğru bölgede mobil IP'ler, özenli parmak izleri, ısıtma. Denetim, antidetect'in bir güncellemesinden sonra motorda şifreli DNS'in açık kaldığını ve tüm profillerin aynı genel DoH çözümleyicisi üzerinden, ofisin gerçek IP'siyle isim çözdüğünü gösterdi. Farklı şehirlerden 120 "bağımsız" kullanıcı isimleri tek noktadan çözüyordu. DoH'un kapatılması, uzaktan DNS'in açılması ve güvenlik duvarıyla 53 portunun bloke edilmesinden sonra hesapların ortalama ömrü 30+ güne çıktı ve ilk haftadaki erken blok oranı yaklaşık üç kat azaldı. Düzeltmenin maliyeti — bir uzmanın iki saatlik işi.

Vaka 2. Pazaryeri kazıyıcısı ve gizemli geo fiyatları

Bir geliştirici, farklı şehirlerin mobil proxy'leri üzerinden büyük bir pazaryerinden bölgesel fiyat topluyordu. Veriler o bölgelerdeki gerçek kullanıcıların gördükleriyle uyuşmuyordu: fiyat ve stokların bir kısmı tamamen başka bir şehre karşılık geliyordu. Neden bağlantı dizesindeki bir satır çıktı: h'siz socks5 şemalı requests kütüphanesi. İsimler geliştiricinin şehrinde yerel çözülüyor, pazaryerinin geo-DNS'i onun bölgesine uygun düğümü veriyor ve sonra başka bir şehirden geçen mobil proxy üzerinden gelen istekler, kendi mantığına göre bölgesel içerik sunan "yabancı" düğüme ulaşıyordu. Yapılandırmadaki tek harfin değiştirilmesi ve her worker başlangıcına otomatik DNS kontrolü eklenmesi veri doğruluğunu geri getirdi. Yan etki: pazaryerinin captcha yanıtladığı istek oranı düştü — oturumlar daha tutarlı hâle geldi.

Vaka 3. Bölgesel kitleler için reklam testi

Bir pazarlama ajansı, mobil proxy'ler ve SOCKS5 bağlantılı Chromium tarayıcı üzerinden reklam ve açılış sayfalarının farklı bölgelerdeki kullanıcılara nasıl göründüğünü kontrol ediyordu. Kontrollerin bir kısmı yanlış bölge içeriğini gösteriyordu. Ajansın kendi test domaininin kayıtlarında çözümleyiciler ofis sağlayıcısına aitti. Aynı mobil proxy'lerin HTTP moduna geçilmesi — bu modda Chromium isimleri CONNECT üzerinden iletir — artı sayfa ön yüklemenin kapatılması tutarsızlığı giderdi. Ek bonus: tekrarlı deneme gerektirmeyen istikrarlı kontrol sonuçları, ekip için düzenli denetimlerde zamanın yaklaşık yüzde 15'ini tasarruf ettirdi.

Vaka 4. Sosyal ağda çoklu hesap ve ortak önbellek

Bir sosyal ağda onlarca hesabı yöneten operatör, aynı gün çalışan hesapların gruplar hâlinde bloklandığını fark etti. İnceleme DNS katmanında iki faktör ortaya çıkardı: antidetect profiller arasında ortak DNS önbelleği kullanıyordu ve profillerin bir kısmı uzaktan çözümlemesiz SOCKS5'teydi. Sonuçta farklı bölgelerin proxy'lerindeki profiller aynı CDN düğümlerine bağlanıyor, bir kısmı da isimleri tek bir gerçek IP'den çözüyordu. Profillere önbellek izolasyonu getirilip tüm bağlantılar uzaktan DNS'e alındıktan sonra grup blokları durdu; sonraki iki ayda hesap kayıpları özenli manuel çalışmanın tipik düzeyine döndü.

Vakalardan genel çıkarım

Dört hikâyenin dördünde de proxy'ler sağlamdı. Sorun istemci tarafında yaşıyor ve haftalarca iş gücüne, bütçelere, hesaplara mal oluyordu. Düzeltme her seferinde saatler sürdü. Bu oran dns leak'in karakteristik özelliğidir: sorun özel kontrol olmadan görünmez, ama nereye bakacağınızı biliyorsanız basitçe düzeltilir.

SSS: DNS sızıntılarıyla ilgili zor sorular

Site DNS sorgularımı almıyorsa sızıntıyı nasıl öğreniyor?

Üç dolaylı yoldan. Birincisi — benzersiz test alt alan adları: site, kendi kontrol ettiği bir domaini tarayıcınıza çözdürüp sorgunun hangi çözümleyiciden geldiğine bakabilir. İkincisi — geo-DNS ve CDN: başka bir bölge için ayrılmış düğüme geliyorsanız, bu tutarsızlık IP'nizle altyapı tarafında görülür. Üçüncüsü — EDNS Client Subnet: genel çözümleyiciler istemci alt ağını yetkili sunuculara iletir ve bu, bağlantının alt ağıyla uyuşmaz. Bu yolların hiçbiri sağlayıcınıza erişim gerektirmez.

Mobil proxy isimleri operatör üzerinden çözüyor. Bu iyi mi kötü mü?

İnandırıcılık için mükemmel. Gerçek bir mobil abone isimleri operatörün çözümleyicileri üzerinden çözer ve bağlantıları aynı operatörün adreslerinden gelir. Proxy'niz de aynısını yaptığında, DNS tarafıyla bağlantı tarafı aynı ağa aittir. Testlerde görmeniz gereken durum tam olarak budur: operatörün çözümleyicileri, operatörün IP'si, tek bölge.

HTTP modu DNS açısından SOCKS5'ten neden daha iyi?

HTTP modunda host adı protokol gereği proxy'ye iletilir — HTTPS için CONNECT'te, HTTP için URL'de. İstemci, PAC betikleri gibi egzotik durumlar dışında ismi yanlışlıkla yerel çözemez. SOCKS5'te uzaktan çözümleme, istemcinin açıkça seçmesi gereken bir opsiyondur ve birçok istemci varsayılan olarak bunu yapmaz. Belirli bir tarayıcının ya da kütüphanenin davranışından emin değilseniz HTTP modu daha güvenlidir. SOCKS5, HTTP olmayan protokoller için daha uygundur ama kontrol gerektirir.

Tarayıcıda güvenli DNS'i kapatmak yeterli mi?

Hayır. Bu tek kanalı — tarayıcının DoH'unu — kapatır. Geriye SOCKS5 için yerel çözümleme, ön yükleme, arka plan servisleri, işletim sistemindeki sistem DoH'u ve IPv6 kalır. Güvenli DNS'i kapatmak gerekli ama yeterli olmayan bir adımdır. Yeterli olan tek şey genişletilmiş testle doğrulama ve ideal olarak sistem düzeyinde doğrudan DNS'in bloke edilmesidir.

Testte ne bana ne operatöre ait olmayan çözümleyiciler çıkarsa ne yapmalıyım?

Zincir boyunca inceleyin. Önce IP'den kuruluşu belirleyin: genel bir DNS servisiyse tarayıcıda veya sistemde açık DoH arayın. Bilinmeyen bir hostingse proxy altyapısı operatör çözümleyicileri yerine kendi çözümleyicilerini kullanıyor olabilir — sağlayıcıya danışın. Temel çizgide gördüğünüz değil de sağlayıcınıza aitse — belki IPv6 ya da başka bir adaptördür. Her beklenmeyen çözümleyicinin bir açıklaması vardır ve bulunması gerekir, görmezden gelinmesi değil.

dns leak proxy üzerinden çalışma hızını etkiler mi?

Etkiler ve çoğu kez beklenmedik yönde. Yerel çözümlemede geo-DNS gerçek konumunuza yakın CDN düğümünü seçer, trafik sonra başka bölgenin mobil ağından bu düğüme gider — rota optimumdan uzun olur. Uzaktan çözümlemede düğüm proxy çıkışına yakın seçilir ve proxy'den sunucuya yol kısadır. Yani doğru DNS yapılandırması genelde yavaşlatmaz, birçok durumda yüklemeyi hızlandırır.

Tarayıcısız otomatik senaryolarda dns leak nasıl test edilir?

En güvenilir yol — kendi test domaininiz. Her worker başlangıcında betik proxy üzerinden benzersiz bir alt alan adına başvurur, sizin yetkili DNS sunucunuz sorgunun hangi çözümleyiciden geldiğini kaydeder. Betik sonra kaydı API'den okur ve çözümleyici adresini beklenen operatör aralığıyla karşılaştırır. Eşleşme yoksa oturum başlatılmaz. Bu, kontrolü elle yapılan bir işlemden sözleşmeye dönüştürür: worker DNS temizliğini kanıtlayana kadar çalışma hakkına sahip değildir.

ECH ve şifreli DNS'in yaygınlaşmasıyla 2026'da tablo nasıl değişiyor?

Manzara "DNS daha önemli hâle geliyor" yönünde ilerliyor. ECH, DNS'teki HTTPS tipi kayıtlara bağlı, tarayıcılar şifreli DNS'i varsayılan olarak açıyor, işletim sistemleri sistem DoH'u ve DoQ'yu ekliyor. Sıradan kullanıcı için bu gizliliğe artı. Proxy üzerinden çalışanlar için ise daha fazla DNS trafiği, sistem içinde daha fazla bağımsız DNS istemcisi ve sorgunun proxy'yi atlayabileceği daha fazla nokta demek. Anti-fraud sistemleri de DNS tarafıyla bağlantı tarafı arasındaki tutarlılığı sinyal olarak giderek daha aktif kullanıyor. Sonuç: DNS disiplini "tercihen"den "mutlaka"ya dönüşüyor.

dns leak koruması iddia eden antidetect tarayıcıya güvenilebilir mi?

Güvenmek — evet, kontrol etmek — şart. Pazarlama iddiası güncellemelerden sonra gerilemeleri, motorlar arası farkları ve proxy yapılandırmanızın özelliklerini ortadan kaldırmaz. Her profili oluşturduktan sonra ve her tarayıcı güncellemesinden sonra kontrol edin. Bir genişletilmiş test bir dakika sürer, yanmış bir çiftliği kurtarmak ise haftalar.

Sonuç: Temiz bir oturumun temeli olarak DNS

Özetleyelim. Proxy bağlantının geldiği adresi değiştirir ama isim çözümlemesinin aynı yoldan gideceğini garanti etmez. DNS sorgusu bağlantıdan önce yapılır ve dns leak tam bu boşlukta doğar. Mobil proxy kullanıcıları için bu özellikle kritik: mobil IP'nin tüm değeri gerçek bir aboneye benzemesinde, gerçek abone ise isimleri kendi operatörü üzerinden çözer. DNS tarafıyla bağlantı tarafı arasındaki tutarsızlık proxy kullanımını diğer birçok belirtiden daha güvenilir şekilde ele verir.

Farklı senaryolarda DNS'in nasıl sızdığını inceledik: uzaktan çözümlemesiz SOCKS, tarayıcılarda ve sistemlerde şifreli DNS, ön yükleme, ortak önbellek, IPv6, PAC betikleri ve koddaki ön çözümleme. Birlikte çalışan dört yöntem verdik: temel çizgi ve genişletilmiş testle teşhis, istemci ve kütüphane yapılandırması, tarayıcılar ve antidetect'ler, son olarak güvenlik duvarı ve ağ izolasyonu düzeyinde zorunlu koruma. Her yöntem tek başına sorunun bir parçasını kapatır. Hepsi birlikte — sızıntıyı teknik olarak imkânsız kılar.

Sıradaki adımlarınız

  1. Bugün: proxy'siz temel çizgiyi kaydedin, sonra her çalışma profilinde ve her betikte genişletilmiş dns leak testinden geçin. Sonuçları yazın.
  2. Bu hafta: koddaki tüm bağlantı dizelerinde h'siz socks5 arayın, tarayıcılarda şifreli DNS'i ve ön yüklemeyi kapatın, profiller arası önbellek izolasyonunun olduğundan emin olun.
  3. Bu ay: çalışma süreçleri için sistem düzeyinde doğrudan DNS'i bloke edin, çalışma arayüzlerinde IPv6'yı kapatın ya da bloke edin, kayıt tutan kendi test domaininizi kurun.
  4. Sürekli: her tarayıcı, antidetect ve kütüphane güncellemesinden sonra kontrolü tekrarlayın. IP kontrolü gibi bir ritüele dönüştürün.

İyi bir mobil proxy size inandırıcı bir adres ve operatörün inandırıcı çözümleyicilerini verir. Sizin işiniz bu avantajı son metrede, kendi sisteminizin içinde kaybetmemek. DNS'i bir kez doğru yapılandırın, kontrolü alışkanlık hâline getirin ve açıklanamayan bloklar kategorisi pratiğinizden kendiliğinden kaybolacak. Bu rehberi sonuna kadar bunun için okumadınız mı?

Yazar Hakkında

Andrey Kokh

Andrey Kokh

Leading Expert and Business Consultant

İş Deneyimi: Leading expert with 12 years of experience. Consults Forbes-listed companies, author of 3 books. Teaches at HSE and SKOLKOVO. His methodologies are used by hundreds of companies across Russia. RBC and Forbes expert on strategic development and digital transformation.
Eğitim: Higher School of Economics. Faculty of Economics, Master's Program
Uzmanlık:
Strategic Consulting Digital Transformation Change Management Business Strategy Innovation Management Organizational Development Lean Management Agile Transformation

Makaleyi paylaşın: