Klasik bir durum: Wildberries veya Ozon'da fiyatları izlemek için yazılmış bir script, evdeki dizüstü bilgisayarda mükemmel çalışıyor, ancak VPS'ye taşındıktan sonra 403, CAPTCHA veya IP üzerinden anında engelleme alıyor. Geliştirici başlıkları değiştiriyor, gecikmeler ekliyor - ama sonuç değişmiyor. Sorun, neredeyse hiçbir zaman parser'ın kodunda değil, yaptığı isteklerin yapıldığı ortamda. Parser'ın sunucuda istikrarlı bir şekilde çalışması için neleri değiştirmemiz gerektiğini inceleyelim.
Neden yerel olarak her şey çalışıyor, ama sunucuda - engel var
Ev bilgisayarınızdan parser'ı çalıştırdığınızda, site, sağlayıcınızın normal bir ev IP adresinden gelen isteği görür, alışık olduğu bölgeden, gerçek bir tarayıcı ortamından, eğer Selenium veya Playwright ile gerçek bir profil kullanıyorsanız. Aynı script Almanya, Hollanda veya ABD'deki bir VPS'ye taşındığında, manzara tamamen değişir: IP, veri merkezine aittir, TLS parmak izi farklı kütüphane sürümleri nedeniyle değişebilir, sunucunun saat dilimi IP'nin coğrafi konumu ile uyuşmaz ve istek sıklığı aniden artar çünkü sunucu 24/7 kesintisiz çalışır.
Wildberries, Ozon, Avito ve çoğu büyük pazar yeri, artık yalnızca User-Agent'a bakmıyor. IP türü, isteklerin hızı ve düzenliliği, sayfadaki davranış, başlıkların ve TLS parametrelerinin uyumu, çerezlerin varlığı ve oturum geçmişi gibi onlarca sinyalin toplamını analiz ediyorlar. Yerel makine çoğu noktada rastgele kontrolü geçerken, sunucu neredeyse tümünde başarısız oluyor. Aşağıda her bir nedenin detaylı incelemesi yer alıyor.
Neden 1: Veri merkezi IP'si yerine ev IP'si
Bu, %80 oranında en yaygın neden. VPS ve bulut sunucularının IP adresleri (AWS, DigitalOcean, Hetzner, sıradan VDS barındırma) veri merkezi veritabanlarında yer alıyor - bu sağlayıcıların ASN'leri kamuya açık olarak biliniyor ve anti-bot sistemleri tarafından trafiği anında filtrelemek için kullanılıyor. Pazar yerleri, otomatikleştirilmiş parsing'in %95'inin sunucu IP'lerinden geldiği için bu tür listeleri öncelikle kullanıyor.
Çözüm, görsel olarak normal bir internet kullanıcısından farklı olmayan IP'ler kullanmaktır. Wildberries, Ozon ve Avito için en uygun olanı rezidans proxy'leri: bu, gerçek ev sağlayıcılarından verilen, normal abonelere ait gerçek IP adresleridir. Antibot sistemleri, böyle bir isteği canlı bir kullanıcıdan gelen trafik olarak görür, veri merkezindeki bir sunucudan değil, bu da çoğu engeli hemen kaldırır.
Neden 2: IP rotasyonu ve istek sıklığı limiti yok
Yerel makinede testler sırasında 20-50 isteği manuel olarak yapıyorsunuz ve site bunu fark etmiyor. Sunucuda script, her 5 dakikada bir cron ile çalıştırılıyor ve bir IP'den ardışık olarak binlerce ürün kartını işliyor. Bu tür bir desen, anti-bot sistemine doğrudan bir sinyal gönderiyor: gerçek bir insan, bir saatte 3000 katalog sayfasını tek bir duraksama olmadan açamaz.
IP rotasyonu uygulamak ve bir adrese belirli bir zaman diliminde istek sayısını sınırlamak gerekiyor. Pratik kural: ürün kartları için bir IP'den dakikada en fazla 30-60 istek, her istek grubundan sonra adresin otomatik olarak değiştirilmesi. Python'da proxy havuzu üzerinden rotasyon ayarının bir örneği:
import requests
proxies_pool = [
"http://user:[email protected]:9000",
"http://user:[email protected]:9001",
"http://user:[email protected]:9002",
]
def get_page(url, session_id):
proxy = proxies_pool[session_id % len(proxies_pool)]
resp = requests.get(
url,
proxies={"http": proxy, "https": proxy},
headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"},
timeout=10
)
return resp.textGünlük büyük miktarda ürün kartı toplarken, isteğe veya zamanlayıcıya göre otomatik IP rotasyonu yapan proxy'leri almak daha uygundur - bu, adres listesini manuel olarak tutma gereğini ortadan kaldırır.
Neden 3: Başlıklar ve User-Agent tarayıcıya benzemiyor
Birçok parser, requests veya aiohttp kullanarak, minimum başlık seti ile ya da kütüphanenin standart User-Agent'ı ile istek gönderiyor, bu da hemen script'i ifşa ediyor (örneğin python-requests/2.31.0). Yerel makinede tarayıcı üzerinden başlık seti tamdır: Accept, Accept-Language, Accept-Encoding, Sec-Ch-Ua, Referer ve diğerleri - bunların toplamı doğal görünür.
Gerçek bir tarayıcının tam başlık setini kopyalamak gerekiyor, gönderim sırasını da dahil etmek - bazı anti-bot sistemleri bunu bile kontrol ediyor. Ayrıca, User-Agent'ı TLS parmak izi sürümü ile senkronize olarak döndürmek önemlidir (bir sonraki maddeye bakın), aksi takdirde tarayıcı başlığı ile gerçek TLS istemcisi arasındaki uyumsuzluk yeni bir bot sinyali haline gelecektir.
Neden 4: TLS/JA3 parmak izi script'i ifşa ediyor
Bu, sunucuda engellemelerin en yaygın nedenlerinden biridir, ancak daha az bilinir. Requests, urllib, aiohttp kütüphaneleri, Chrome veya Firefox'taki uygulamadan farklı bir TLS el sıkışma uygulaması kullanır. Anti-bot sistemleri, TLS bağlantısının JA3/JA4 parmak izini hesaplar - ve python script'inin parmak izi, başlıklar mükemmel kopyalansa bile gerçek bir tarayıcı parmak izine hiç benzemiyor.
Çözüm, tarayıcı parmak izini taklit eden kütüphaneler kullanmaktır (örneğin Python'da curl_cffi, tls-client veya Playwright/Puppeteer üzerinden tam bir headless tarayıcı). İkinci seçenek, temiz bir HTTP istemcisi yerine, gerçek bir tarayıcı motoru ile yönetilen bir tarayıcı motoru kullanmaktır; burada TLS ve başlıklar gerçek bir tarayıcı çekirdeği tarafından oluşturulur, kütüphanenin taklidi değil.
Neden 5: Saat dilimi, yerel ayar ve DNS sunucuları
Script, Selenium veya Playwright üzerinden tarayıcıyı taklit ediyorsa, anti-bot sistemi sistem saat dilimini, arayüz dilini, DNS çözümleyicisini ve hatta gerçek sunucunun IP'sinin WebRTC sızıntısını kontrol edebilir. Frankfurt'taki bir veri merkezinde sistem saat dilimi UTC ve barındırma sağlayıcısının DNS sağlayıcısı ile VPS kullanmak, Moskova'dan gelen bir IP ile birlikte açık bir coğrafi veri uyumsuzluğu yaratır - bu, tespit için en güvenilir sinyallerden biridir.
Tüm çevre parametreleri - saat dilimi, tarayıcı dili, DNS, WebRTC üzerinden coğrafi konum - istek için kullanılan IP adresinin bölgesi ile uyumlu olmalıdır. Bu sorunu çözmek için anti-detect tarayıcıları geliştirilmiştir: Dolphin Anty, AdsPower, Multilogin, Octo Browser ve GoLogin, her proxy için ayrı bir "tarayıcı profili" ayarlamanıza olanak tanır; burada otomatik olarak saat dilimi, yerel ayar, ekran çözünürlüğü ve WebRTC, IP'nin coğrafi konumuna göre ayarlanır.
Neden 6: İsteklerin deseni çok "robotik"
İnsan, katalogda farklı duraksamalarla dolaşır, rastgele ürünlere tıklar, bazen geri döner, sayfayı düzensiz bir şekilde kaydırır. Sunucu script'i genellikle eşit aralıklarla (örneğin kesinlikle 2 saniyede bir) istek yapar ve yalnızca gerekli URL'lere başvurur - etrafında "gürültü" olmadan - resim yüklemeden, script'lerden, ürün kartına gitmeden önce ana sayfayı ziyaret etmeden.
Neleri değiştirmeli: rastgele gecikmeler eklemek (sabit 2 saniye değil, 1.5 ile 6 saniye arasında rastgele), ara sayfalara (kategori → kart, API'ye doğrudan istek yerine) zaman zaman girmek, headless tarayıcı ile çalışırken kaydırma ve fare hareketlerini taklit etmek. Bu, veri toplama süresini artırır, ancak engel sayısını keskin bir şekilde azaltır.
Neden 7: Oturumlar ve çerezler istekler arasında saklanmıyor
Genellikle sunucudaki parser, her istek için yeni bir requests oturumu oluşturur - çerez olmadan, saklanmış bir yetkilendirme token'ı olmadan, ziyaret geçmişi olmadan. Wildberries ve Ozon gibi pazar yerleri, ilk girişte geçici çerezler ve token'lar verir ve bunlar olmadan sonraki istekler şüpheli görünür, sanki her istek yeni bir anonim ziyaretçi tarafından yapılıyormuş gibi.
Doğru şema: bir oturum (requests.Session() veya tarayıcı bağlamı) - proxy havuzundan bir IP için, bu IP'ye yapılan tüm istekler boyunca çerezleri saklayarak. Proxy değiştiğinde, yeni bir kullanıcıyı taklit ederek temiz çerezlerle yeni bir oturum başlatmak gerekir, eski çerezleri yeni bir IP ile kullanmaya devam etmek yerine - bu da bir uyumsuzluk yaratır ve engelleme tetikler.
Kontrol listesi: sırayla neleri değiştirmeli
Eğer parser sunucuda sürekli engelleniyorsa, ancak yerel olarak çalışıyorsa, bu sırayla değişiklikleri kontrol edin - böylece nedeni daha hızlı bulabilirsiniz:
| Adım | Kontrol edilecek | Neleri değiştirmeli |
|---|---|---|
| 1 | Sunucu IP türü | Doğrudan barındırma IP'si yerine rezidans proxy'lerine geçin |
| 2 | İstek sıklığı | IP rotasyonu ve adres başına istek limiti getirin |
| 3 | İstek başlıkları | Gerçek bir tarayıcının tam başlık setini kopyalayın |
| 4 | TLS parmak izi | Temiz requests yerine curl_cffi / headless tarayıcı kullanın |
| 5 | Saat dilimi ve yerel ayar | Dolphin Anty / AdsPower'da IP bölgesi için profil ayarlayın |
| 6 | Davranış deseni | Gecikmeleri rastgele hale getirin, ara sayfalar ekleyin |
| 7 | Oturumlar ve çerezler | Bir oturumu tüm istek döngüsü boyunca bir IP'ye bağlayın |
Wildberries ve Ozon kataloglarını yüksek frekansta parse etmek için, binlerce sayfayı dolaşmanın hızının önemli olduğu durumlarda, genellikle iki tür proxy kombinasyonu kullanılır: veri merkezi proxy'leri teknik ön kontroller (erişilebilirlik kontrolü, durum kodları) için ve rezidans proxy'leri - ürün kartlarından veri toplarken gerçek bir kullanıcı gibi görünmek için. Pazar yerlerinin ve Avito'nun mobil uygulamaları için bazen mobil proxy'ler daha etkili olabilir, çünkü bunlar ASN'ye göre otomatik engelleme listelerine daha az düşer.
Sonuç
Sunucuda parser'ın engellenmesi, yerel versiyon çalışırken genellikle script'in mantığıyla değil, ortamla ilgilidir: IP türü, TLS parmak izi, başlıklar, saat dilimi, istek deseni ve oturum yönetimi. Her bir nedeni sırayla kontrol ederek - en yaygın olanından (veri merkezi IP'si) en az belirgin olana (saat dilimi ve IP bölgesi arasındaki uyumsuzluk) - veri toplama iş mantığını değiştirmeden parser'ın istikrarlı çalışmasını yeniden sağlamak mümkündür.
Eğer Wildberries, Ozon veya Avito'da fiyatları ve stokları endüstriyel miktarlarda topluyorsanız, IP değişikliği ile başlayın: standart VPS adresi yerine rezidans proxy'lerini deneyin - çoğu durumda, başlıkları ve TLS parmak izlerini ayarlamaya başlamadan önce %70'e kadar engeli ortadan kaldırır.