Yerleşik IP artık kurtarmıyor. 2026 yılında en büyük anti-bot sistemleri — Cloudflare, Akamai, AWS WAF — otomatik trafiği, sunucu ilk HTML baytını göndermeden önce tanımayı öğrendi. Bir bot mu yoksa insan mı olduğuna dair karar, TLS el sıkışma aşamasında, istemcinizin dijital "parmak izi" üzerinden veriliyor. Ve eğer bu parmak izi gerçek bir tarayıcının formuyla uyuşmuyorsa, hiçbir temiz yerleşik IP sizi kurtaramaz. Scraping, "proxy oyunu" olmaktan "kimlik oyunu" haline geldi.
Ne oldu: JA4+ sektörel standart haline geldi
Birkaç yıl önce TLS parmak izi için standart JA3 idi — ClientHello mesajındaki TLS sürümü, şifreleme setleri, uzantılar ve eliptik eğrileri tek bir MD5 dizesine dönüştüren bir hash. Bu yöntem, Chrome 110'a (Ocak 2023) kadar çalışıyordu, o zaman Google, parmak izine karşı bir önlem olarak TLS uzantılarının sırasını rastgele hale getirmeyi kasıtlı olarak etkinleştirdi. Bunun ardından JA3 hash'i, aynı tarayıcıda bile her bağlantıda değişmeye başladı — bu nedenle istemciyi güvenilir bir şekilde tanımak imkansız hale geldi.
Cevap, FoxIO'dan JA4+ oldu: hash işleminden önce şifreleme setleri ve uzantılar sıralanıyor, bu nedenle Chrome'un rastgeleleştirmesi artık parmak izini bozmaz. 2026 yılına gelindiğinde JA4, de facto standart haline geldi ve bot yönetiminde Cloudflare, AWS WAF, VirusTotal ve Akamai için ana sinyal olarak çalışıyor. Üç parçadan oluşan format (a_b_c) tarayıcı sürümleri arasında istikrarlıdır: örneğin, Chrome 120–131 t13d1516h2_8daaf6152771_02713d6af862 verirken, Chrome 133–136 t13d1516h2_8daaf6152771_d8a2da3f94cd verir.
Bu tespitlerin ölçeğini abartmak zor. Cloudflare, 500+ milyon user-agent'tan toplanan 15 milyon benzersiz JA4 parmak izini analiz ediyor ve sekizinci nesil ML modeli, saniyede yaklaşık 46 milyon HTTP isteğini işliyor. DataDome, kendi verilerine göre, günde 5 trilyondan fazla sinyali 2 ms'den daha kısa bir gecikme ile işliyor ve 85,000'den fazla müşteri ML modeli tutuyor. Akamai, katmanlar arası analiz sayesinde bot sınıflandırma doğruluğunu %92–98 aralığında olduğunu bildiriyor.
Post-kuantum TLS: scraper'lar için yeni bir tuzak
2026 yılının pek az kişinin bildiği en büyük değişikliği, tarayıcıların post-kuantum kriptografiye geçişi. İşte bu, günümüzde eski scraping araçlarını etkisiz hale getiriyor.
Takvim basit. Nisan 2024'te Chrome 124 varsayılan olarak hibrit anahtar değişimi X25519MLKEM768'i (klasik X25519 artı ML-KEM-768, eski Kyber) etkinleştirdi. Kasım 2024'te Firefox 132 desteği ekledi, Ekim 2025'te Apple iOS ve macOS'ta destek sağladı. Ve 31 Ocak 2026'da Akamai, tüm müşteriler için post-kuantum bağlantılarını varsayılan hale getirdi. F5 Labs'a göre, şu anda tüm tarayıcı bağlantılarının %57,4'ü post-kuantum anahtar paylarını taşıyor; Chrome trafiği arasında PQ uyumlu olanlar %93'tür.
Scraper'lar için sorun, post-kuantum anahtar payının 1088 bayt eklemesidir; ClientHello mesajı, alışılmış ~300–500 bayttan 1400 bayttan fazla bir boyuta genişliyor ve artık tek bir TCP paketine sığmıyor. Bu, dedektör için üç ipucu sağlıyor:
- İkili sinyal. Chrome 131 olarak görünen ancak post-kuantum anahtar payı olmayan bir istek — "HTTP trafiğinin ilk baytından önce tetiklenen kırmızı bayrak".
- ClientHello'nun parçalanması. Genişleyen mesaj birkaç TCP paketine bölünüyor ve segmentasyon görüntüsü gerçek bir tarayıcıdan farklı.
- Genişletilmiş JA4. Bilimsel çalışma (arXiv, Mart 2026) sadece el sıkışma verilerine dayanarak klasik ve post-kuantum TLS'yi ayırt etmede %98 doğruluk gösterdi.
Ayrıca, birçok Go scraper'ının temelini oluşturan uTLS kütüphanesindeki zayıflıklar ayrı bir hikaye. İki CVE (CVE-2026-26995 ve CVE-2026-27017) iki yıldan fazla bir süre boyunca fark edilmeden kaldı ve eksik bir padding uzantısı ve GREASE/ECH uyumsuzluğu nedeniyle bağlantıda %25–50 tespit olasılığı sağladı. uTLS'yi 1.8.2+ sürümüne güncelleyerek bu sorun giderilebilir. Ders: HelloChrome_120 gibi eski parmak izlerine sıkı sıkıya bağlılık, bir tarayıcı güncellemesi ile bir yük haline geldi.
Sadece TLS değil: HTTP/2 ve katmanlı tespit
TLS el sıkışması yalnızca ilk savunma hattıdır. Hemen ardından HTTP/2 parmak izi gelir: her tarayıcı, karakteristik bir SETTINGS parametreleri seti ve kendi sahte başlık sırasını gönderir. Chrome'da bu masp, Firefox'ta mpas, Safari'de mspadır. Ancak sıradan bir curl'deki sahte başlık sırası (mpsa) gerçek bir tarayıcıyla uyuşmaz — yani curl anında tespit edilir.
2026'da tespit, sinyallerin birbirleriyle tutarlılığını kontrol eden net bir zincir halinde yapılandırılmıştır:
- TCP/IP parmak izi — şifrelemeden önce işletim sisteminin belirlenmesi;
- TLS ClientHello (JA4) — el sıkışma sırasında;
- HTTP/2 SETTINGS — TLS'den sonraki ilk çerçeve;
- istekteki HTTP başlıklarının sırası;
- çapraz kontrol: tüm sinyaller "birbirine uyan" tek bir kimlik oluşturmalıdır.
Bu nedenle, günümüzde yalnızca JA3 ile eşleşme, hiçbir şeyden daha kötü: sistem "yanlış şekilli Chrome" görüyor ve onu bir bot olarak sıralıyor. Uygulayıcı mühendislerin ifadesiyle: TLS parmak izi eşleşmesi, artık statik bir hash ile değil, istemcinin tüm katmanlarda bütünsel kimliği ile ilgilidir.
Pratikte bu ne anlama geliyor
2026 yılının tüm ciddi kaynakları tarafından tekrarlanan sonuç: "mükemmel TLS sahteciliği, eğer istekler birden fazla lokasyondan iki dakika içinde gelirse değersizleşir". Proxy ve parmak izi artık yalnızca birlikte çalışıyor. Ne değiştiğine bakalım.
1. Parmak izi gerçek olmalı, "üzerine çizilmiş" değil
JavaScript çalıştırmayan HTTP istekleri için anahtar sinyallerin önemi: doğru JA4, doğru HTTP/2 SETTINGS ve sahte başlıkların sırası, başlıkların doğru sıralaması ve tüm katmanların tutarlılığı. Yerel Python-requests, standart curl ve Go net/http bunu yeniden oluşturamaz. 2026 yılının çalışan araçları — curl_cffi, curl-impersonate, uTLS, tls-client, TLS parmak izini BoringSSL seviyesinde tutanlardır. Tarayıcı otomasyonu için en güçlü açık çözüm — Camoufox: bu, parmak izini C++ seviyesinde değiştirir, belirgin JS yamanmalarıyla değil. Ancak CVE'leri unutmayın — kütüphanelerin güncellenmesi gerekir.
2. Proxy, parmak izinin çözemediği sorunları çözer
Hatasız bir TLS sahteciliği bile, IP adresinin kötü bir üne sahip olması veya ASN'nin bir veri merkezi olarak biliniyorsa işe yaramaz. Ağ, ayrı bir güven katmanıdır: coğrafi konum tutarlılığı, ASN'nin itibarı, hız ve isteklerin dağılımı. Burada yerleşik proxy'ler devreye giriyor — trafik, gerçek ev kullanıcılarının ISP adresleri üzerinden geçiyor, bu nedenle ağ sinyalleri açısından sıradan bir ziyaretçiden ayırt edilemezsiniz. En agresif platformlar (sosyal medya mobil uygulamaları, bankalar, anti-fraud) için daha da dayanıklı mobil proxy'ler: hücresel operatörlerin NAT paylaşımı ile IP'leri en yüksek güven düzeyini sağlar ve neredeyse toplu olarak yasaklanmazlar.
3. Kazanan, bir bütün olarak kombinasyon, tek bir numara değil
2026 yılının en etkili (ve dürüst olmak gerekirse en pahalı) yaklaşımı, aynı anda dört bileşenden oluşur: gerçek tarayıcı otomasyonu (Chromium/Firefox), yerleşik veya mobil ISP adresleri üzerinden yönlendirme, otomasyon telemetrisini kaldıran stealth eklentileri ve insan benzeri davranışların rastgeleleştirilmesi. Kural basit: "el sıkışmayı düzelt, yerleşik IP'yi koru — ve başarı oranı hızla artar". Bu unsurlardan hiçbiri 2026'da artık tek başına yeterli değildir.
Altyapınızı inşa etmek için ne seçeceğinizi düşünüyorsanız, temelden başlamak — taşıma protokollerini anlamak ve HTTP/HTTPS proxy'lerinin farklı scraping görevleri için SOCKS5'ten nasıl farklılaştığını öğrenmek iyi bir fikirdir. Bunu ayrı bir kılavuzda ele aldık: HTTP, HTTPS ve SOCKS5 — hangi proxy'yi seçmelisiniz.
Sonuç
2026 yılı, scraping için "yerleşik proxy satın alıp IP döndürmek" dönemini kesin olarak kapattı. Artık sizi TLS el sıkışmasının şekli, post-kuantum anahtarları, HTTP/2 başlıklarının sırası ile tanıyorlar — ve tüm bu sinyaller birbirleriyle ve geldiğiniz ağla karşılaştırılıyor. Kazanan, kimliği tüm katmanlarda bütünsel olan: inandırıcı bir parmak izi, güncellenmiş kütüphaneler, insan gibi davranış ve altında kaliteli bir yerleşik veya mobil ağ olan kişidir. Proxy'ler artık gerekli olmaktan çıkmadı — onlar, tüm diğer unsurların inşa edildiği temel haline geldi.
```