Pahalı bir yerleşik IP aldınız, döngüyü ayarladınız, gerçekçi bir User-Agent koydunuz - ama analizci yine de CAPTCHA'ya düşüyor veya boş bir yanıt alıyor. Sorun neredeyse her zaman IP'de değil, TLS parmak izinde: HTTPS isteği gönderdiğiniz kütüphane, gerçek bir tarayıcı gibi "ses çıkarmıyor". Wildberries, Ozon, Cloudflare ve Akamai'nin anti-bot sistemleri bunu IP adresinizi kontrol etmeden önce görüyor.
TLS parmak izi nedir ve neden IP'den daha önemlidir
Bir istemci HTTPS bağlantısı kurduğunda, sunucuya bir ClientHello paketi gönderir - bu, TLS el sıkışmasının bir parçasıdır. İçinde desteklenen TLS sürümleri, şifre setleri (cipher suites), genişletmelerin sırası (extensions), eliptik eğriler ve sıkıştırma algoritmaları şifrelenmiştir. Bu parametre seti, "kütüphane + işletim sistemi + TLS yığını sürümü" kombinasyonu için benzersizdir.
Chrome, Firefox ve Safari ClientHello'yu kendi tarzlarında oluşturur ve bu set neredeyse her istekte değişmez - IP veya User-Agent gibi metinle kolayca taklit edilebilenlerden farklı olarak. Ancak standart HTTP kütüphaneleri - requests, urllib3, Java'daki standart HttpClient, Node.js'in yerleşik TLS yığını - tamamen farklı bir ClientHello oluşturur, çünkü OpenSSL veya başka bir kütüphaneyi tarayıcıdan farklı bir şekilde kullanır.
Bu nedenle, mükemmel "temiz" bir yerleşik IP bağlayabilir, gerçek Chrome'un yeni bir User-Agent'ını koyabilirsiniz - ama yine de engellenirsiniz. Sunucu, bir yerleşik evden gelen IP'yi görür, "Chrome 124" başlığını görür, ancak TLS el sıkışması "bu bir Python betiği" der. Uyuşmazlık, anti-bot için doğrudan bir sinyaldir.
Anti-bot sistemleri JA3/JA4 ile analizciyi nasıl tespit eder
ClientHello parametrelerini kompakt bir tanımlayıcıya dönüştürmek için JA3 (ve daha yeni versiyonu JA4) algoritması kullanılır. Bu, TLS sürümünü, şifreler, genişletmeler ve eğrileri alır, bunları bir dizeye birleştirir ve MD5 ile hashler. Sonuç olarak, 769,47-53-5-10...,0-23-65281...,29-23-24,0 gibi kısa bir hash elde edilir ve bu, istemcinin "parmak izini" kesin bir şekilde tanımlar.
Antibot sağlayıcıları (Cloudflare, Akamai, PerimeterX, DataDome - ve Wildberries ve Ozon'un kullandığı benzerleri) popüler HTTP kütüphanelerinin bilinen JA3/JA4 hash'lerini tutar: requests, aiohttp, Scrapy, Node fetch, Java HttpClient, Go net/http. Eğer hash, bilinen bir "betik" imzasıyla eşleşiyorsa ve Chrome/Firefox/Safari imzasıyla değilse - istek, davranış analizi yapılmadan önce şüpheli olarak işaretlenir.
Daha sonra sistem, TLS parmak izinin belirtilen User-Agent ile eşleşip eşleşmediğine bakar. Eğer başlıklarda "Windows'ta Chrome 124" yazıyorsa ve TLS parmak izi Python'un standart kütüphanesindeki OpenSSL 1.1.1 ile eşleşiyorsa - bu, TLS/HTTP uyuşmazlığı olarak adlandırılır, otomasyonu tespit etmenin en güvenilir sinyallerinden biridir. İşte bu şekilde, analizciler mükemmel bir yerleşik IP ve doğru başlıklarla bile tespit edilir.
TLS parmak izinizi nasıl kontrol edersiniz: araçlar
Sorunu çözmeden önce, sunucunun ne gördüğünü görmek gerekir. JA3/JA4 hash'inizi ve ClientHello parametrelerinin tam setini gösteren birkaç kamuya açık hizmet vardır:
- tls.peet.ws - JA3, JA4, şifreler ve genişletmeler listesini JSON formatında gösterir, bu da otomatik kontrol için uygundur.
- ja3er.com - belirli kütüphaneler ve tarayıcılarla ilişkilendirilmiş bilinen JA3 hash'lerinin veritabanı.
- browserleaks.com/tls - parmak izinizi tipik tarayıcılarla görsel olarak karşılaştırır.
- Wireshark yerel olarak - isteği gönderirken ClientHello'nun ham paketini görmek istiyorsanız.
Pratik test basit: tls.peet.ws'i normal bir Chrome'da açın ve JA4 hash'ini kaydedin. Ardından, aynı adrese analizcinizden (requests, curl_cffi veya başka bir kütüphane aracılığıyla) aynı proxy üzerinden GET isteği gönderin ve hash'leri karşılaştırın. Eğer farklıysalar - sunucu her istekte "tarayıcı" ve "betik" arasındaki farkı görüyor, IP ne kadar temiz olursa olsun.
Python ile kontrol: requests, httpx, curl_cffi
Standart Python kütüphanelerinin neden analizciyi ifşa ettiğini pratikte inceleyelim. requests ile sıradan bir istek:
import requests
resp = requests.get("https://tls.peet.ws/api/all", proxies={
"https": "http://user:pass@proxy_host:port"
})
print(resp.json()["tls"]["ja4"])
# Sonuç, gerçek Chrome'dan farklı olacaktır,
# çünkü requests Python'un standart ssl modülünü kullanır
Sorun şu ki, requests ve httpx sistem OpenSSL'i ssl modülü aracılığıyla kullanır ve TLS genişletmelerinin sırası ve seti katı bir şekilde sabitlenmiştir ve Chrome/Firefox ile uyuşmaz. Çözüm, gerçek tarayıcıların TLS profillerini kullanan yamanmış curl ile çalışan curl_cffi kütüphanesidir:
from curl_cffi import requests as cffi_requests
resp = cffi_requests.get(
"https://tls.peet.ws/api/all",
impersonate="chrome124",
proxies={"https": "http://user:pass@proxy_host:port"}
)
print(resp.json()["tls"]["ja4"])
# Hash, masaüstünde gerçek Chrome 124 ile aynı olacaktır
impersonate parametresi, curl_cffi'nin sadece ClientHello'yu değil, aynı zamanda HTTP/2 başlıklarının sırasını (frame order) da yeniden oluşturmasını sağlar; bu da parmak izine dahil edilir. Benzer bir yaklaşım, gerçek tarayıcı aracılığıyla değil, HTTP istemcisi aracılığıyla analiz yapanlar için tls-client ve undetected-chromedriver kütüphaneleri tarafından kullanılır.
Eğer analiz, headless tarayıcı (Playwright, Puppeteer, Selenium) aracılığıyla yapılıyorsa, TLS parmak izi Chromium/Firefox motoru tarafından oluşturulur ve varsayılan olarak gerçek tarayıcı ile eşleşir. Ancak burada başka bir sorun ortaya çıkar - JS düzeyinde otomasyon imzaları (webdriver bayrakları, canvas parmak izi) nedeniyle, headless senaryolar için ek olarak playwright-stealth gibi yamalar gereklidir.
TLS + HTTP/2 + başlıklar: neden bağlantı önemlidir
TLS parmak izi sadece bir tespit katmanıdır. Anti-bot sistemleri aynı anda birkaç katmanı karşılaştırır:
- TLS ClientHello (JA3/JA4) - şifreler ve genişletmeler seti.
- HTTP/2 parmak izi - sahte başlıkların sırası (:method, :path, :authority), SETTINGS çerçevesinin ayarları, pencere boyutu.
- HTTP başlıkları - normal başlıkların sırası ve seti (Accept-Language, Sec-Ch-Ua, Sec-Fetch-*).
- User-Agent - TLS profilinin sürümü ile eşleşmelidir: eğer UA "Chrome 124" diyorsa ve TLS Chrome 110 ile eşleşiyorsa, bu da şüpheli bir durumdur.
Yaygın bir hata, User-Agent'ı en son Chrome sürümüne güncelleyip, curl_cffi veya başka bir kütüphanedeki TLS profilini güncellemeyi unutmaktır. Bu tür bir sürüm uyuşmazlığı, anti-bot tarafından tamamen maskelenmemiş gibi net bir şekilde görülür. impersonate sürümünün ve User-Agent'taki sürümün eşleştiğinden emin olun ve tarayıcıların yeni sürümleri çıktığında her iki parametreyi senkronize olarak güncelleyin.
Bir diğer nokta ise başlıkların sırasıdır. Tarayıcı başlıkları belirli bir sırayla gönderir, ancak birçok HTTP kütüphanesi bunları alfabetik olarak veya kodda eklenme sırasına göre sıralar. Başlık seti tarayıcı ile aynı olsa bile, yanlış bir sıra, DataDome gibi gelişmiş anti-bot sistemleri için ek bir sinyal oluşturur.
Proxy'nin rolü: neden temiz IP kurtarmaz
Yerleşik IP, coğrafya, ASN ve adresin itibarı açısından şüpheyi azaltmak için belirli bir görevi yerine getirir. Veri merkezi IP'leri genellikle kara listelerde yer alır çünkü bunlardan otomatik trafik yoğun bir şekilde gelir, oysa yerleşik IP'ler gerçek sağlayıcılara ve sıradan kullanıcılara aittir. Wildberries, Ozon veya Avito için bu kritik öneme sahiptir: temiz bir IP olmadan, istek bu özelliğe dayanarak engellenir, TLS'yi kontrol etmeden bile.
Ancak IP ve TLS parmak izi, iki bağımsız koruma katmanıdır ve farklı sorunları çözerler. IP, sunucuya isteğin "nereden" geldiğini söyler, TLS parmak izi ise "ne ile" gönderildiğini belirtir. Bu nedenle, temiz bir IP ve doğru bir TLS profilinin kombinasyonu, istikrarlı bir analiz için minimum gerekliliktir. Yüksek istek sıklığı ve agresif anti-bot içeren görevler için yerleşik proxy'ler kullanmak daha iyidir, bunlar IP itibarı açısından düşük bir yasaklama oranı sağlar, ancak mutlaka gerçek bir tarayıcının TLS profilini doğru bir şekilde yeniden üreten bir kütüphane ile birleştirin.
Hız ve istek hacminin önemli olduğu pazar yerlerinde fiyat izleme için genellikle veri merkezi proxy'leri TLS maskesi ile birlikte kullanılır - bu, yerleşik olanlardan daha ucuzdur ve eğer sitenin anti-bot sistemi çok agresif değilse oldukça etkilidir. Ve sitenin mobil ağları aktif olarak kontrol ettiği görevler için (örneğin, API aracılığıyla mobil uygulamaların mobil versiyonlarını analiz etmek) mobil proxy'ler kullanılır - bunlar operatör ağlarının itibarı sayesinde ek bir güven düzeyi sağlar.
Tespit olmadan analizci ayarlama kontrol listesi
Analizciyi üretim ortamında çalıştırmadan önce kontrolü tek bir süreçte toplayın:
- Betik JA4 hash'inizi tls.peet.ws üzerinden ölçün ve aynı sürümdeki gerçek tarayıcı ile karşılaştırın.
- TLS taklit desteği olan bir kütüphane kullanın: curl_cffi (Python), tls-client (Go), CycleTLS (Node.js).
- TLS profilinin sürümünü (impersonate) User-Agent'taki sürümle senkronize edin.
- HTTP başlıklarının sırasını kontrol edin - gerçek tarayıcı ile eşleşmeli, alfabetik değil.
- Göreviniz için coğrafi olarak temiz bir yerleşik veya mobil IP bağlayın.
- IP döngüsünü TLS profilinden ayrı olarak ayarlayın - birini diğerine sıkı bir şekilde bağlamayın.
- Yeni Chrome sürümleri çıktığında TLS profilini düzenli olarak güncelleyin - eski imzalar, anti-bot veritabanlarına daha hızlı girer.
- JS kontrolleri olan senaryolar (Cloudflare Challenge) için temiz bir HTTP istemcisi yerine stealth yamaları ile headless tarayıcı kullanın.
Kütüphanelerin ve araçların karşılaştırması
| Araç | Tarayıcı TLS parmak izi | Hız | Ne zaman kullanılmalı |
|---|---|---|---|
| requests / httpx | Hayır, betik verir | Yüksek | TLS tespiti olmayan siteler, dahili API'ler |
| curl_cffi | Evet, tam kopya | Yüksek | Pazar yerleri, Cloudflare/Akamai anti-botu |
| tls-client (Go) | Evet | Çok yüksek | Yüksek yük, toplu analiz |
| Playwright / Puppeteer | Evet, gerçek motor | Düşük | JS-render, Cloudflare Challenge, karmaşık SPA'lar |
| Scrapy (standart) | Hayır | Yüksek | Sert anti-bot koruması olmayan siteler |
Sonuç
TLS parmak izi, birçok analizcinin tamamen göz ardı ettiği bir koruma katmanıdır; mükemmel bir IP ve User-Agent seçimine kaynak harcarken, TLS el sıkışmasının yapısının otomasyonu sunucu başlıklara bakmadan önce ifşa ettiğini unutur. Çözüm, TLS taklit desteği olan kütüphaneler (curl_cffi, tls-client) kullanmak, profil sürümünü User-Agent ile senkronize etmek ve ölçeklenmeden önce nihai JA4 hash'ini kontrol etmektir.
IP yine de önemli bir faktör olmaya devam ediyor - temiz bir adres olmadan, mükemmel bir TLS parmak izi bile ağ itibarı nedeniyle engeli aşmaya yardımcı olmaz. Pazar yerlerinde analiz yapmak ve fiyat izlemek için doğru TLS ayarını yerleşik proxy'ler ile birleştirmek mantıklıdır - bu tür bir bağlantı, her iki tespit katmanını kapatır ve uzun analiz oturumlarında yasaklama oranını önemli ölçüde azaltır.