Eğer pazar yerlerini tarıyorsanız, rakip fiyatlarını izliyorsanız veya sosyal medya ile otomasyon yapıyorsanız, muhtemelen 429 Aşırı İstek hatası ile karşılaşmışsınızdır. Site, isteklerinizi şüpheli bulduğu için engeller ve tüm otomasyon durur. Bu makalede, bu sorunun neden ortaya çıktığını ve doğru proxy ayarları, IP döngüsü ve yük dağılımı ile nasıl çözüleceğini inceleyeceğiz.
Farklı görevler için somut çözümler sunacağız: Wildberries ve Ozon taraması, rakip izleme, sosyal medya API'leri ile çalışma, veri toplama. Tüm öneriler pratik deneyime dayanmaktadır ve gerçek projelerde çalışmaktadır.
429 Aşırı İstek hatası nedir ve neden ortaya çıkar
429 Aşırı İstek hatası, belirli bir zaman diliminde izin verilen istek sayısını aştığınızda sunucunun döndürdüğü bir HTTP yanıt kodudur. Bu, sitelerin aşırı yüklenmeyi ve otomatik veri toplamayı önlemek için kullandığı bir koruma mekanizmasıdır.
429 hatasının ortaya çıktığı tipik durumlar:
- Pazar yerlerini tarama — Wildberries, Ozon veya Avito'dan fiyatları topluyorsunuz ve dakikada yüzlerce istek yapıyorsunuz. Site, bir IP'den gelen anormal etkinliği görür ve onu engeller.
- Rakip izleme — ürünler, fiyatlar, stok durumu hakkında otomatik veri toplama. Sık kontrol edildiğinde limit devreye girer.
- API ile çalışma — birçok API'nin katı kısıtlamaları vardır: örneğin, Instagram API'si saatte 200 isteğe izin verir, Twitter ise 15 dakikada 300 isteğe izin verir.
- Toplu kayıt veya işlemler — hesap oluşturma, mesaj gönderme, beğenme. Platformlar otomasyonu hızla tespit eder ve IP'yi engeller.
Önemli olan: 429 hatası sadece teknik bir kısıtlama değildir. Bu, sitenin etkinliğinizi şüpheli olarak tanıdığına dair bir sinyaldir. Aynı IP'den saldırmaya devam ederseniz, kalıcı bir yasak alabilirsiniz.
Önemli: Bazı siteler 429 yerine 403 Yasaklı yanıtı döndürüyor veya sadece CAPTCHA gösteriyor. Temel mesele aynı — limitleri aştınız ve engellendiniz.
Siteler şüpheli etkinliği nasıl belirler
Engellemeleri etkili bir şekilde aşmak için, sitelerin sizi nasıl tespit ettiğini anlamak önemlidir. Modern koruma sistemleri birçok parametreyi analiz eder:
1. IP adresi ve istek sıklığı
En belirgin parametre. Eğer bir IP'den dakikada 100 istek geliyorsa ve normal bir kullanıcı 5-10 istek yapıyorsa — bu açık bir otomasyondur. Siteler limitler koyar:
- Wildberries: bir IP'den dakikada yaklaşık 60 istek
- Ozon: dakikada yaklaşık 30-40 istek
- Avito: özellikle arama istekleri için katı limitler
- Instagram API: uygulama başına saatte 200 istek
2. User-Agent ve tarayıcı başlıkları
Eğer istekleri doğru bir User-Agent olmadan bir script aracılığıyla gönderiyorsanız, site hemen bunun gerçek bir tarayıcı olmadığını anlar. Ayrıca başlıklar da analiz edilir: Accept, Accept-Language, Referer. Bu başlıkların eksikliği veya alışılmadık değerler — kırmızı bayraktır.
3. Davranışsal kalıplar
Gerçek bir kullanıcı her 2 saniyede bir mükemmel bir periyodiklikle istek yapmaz. Kaydırır, tıklar, duraklar. Eğer parser'ınız bir metronom gibi çalışıyorsa — bu şüphelidir.
4. IP adresi türü
Birçok platform, veri merkezi IP'lerini kara listeye alır. Eğer ucuz proxy'ler kullanıyorsanız, AWS veya Google Cloud ile, engellenme olasılığı daha yüksektir. Gerçek sağlayıcılardan gelen konut IP'leri daha az şüphe uyandırır.
Proxy döngüsü: limitleri aşmanın ana yolu
429 sorununu çözmenin ana yolu IP adreslerinin döngüsüdür. Tüm istekleri tek bir IP'den yapmak yerine, yükü birçok adres arasında dağıtırsınız. Her IP, az sayıda istek yapar ve limitleri aşmaz.
Proxy döngüsü türleri
| Döngü türü | Nasıl çalışır | Ne zaman kullanılmalı |
|---|---|---|
| İstek başına döngü | Her istek yeni bir IP ile gelir. Proxy sağlayıcısı adresi otomatik olarak değiştirir. | Hızlı veri toplamak gerektiğinde toplu tarama |
| Zamanlayıcıya göre döngü | IP her 5-30 dakikada bir değişir. Bir dizi istek için bir adres kullanırsınız. | Oturum gerektiren sitelerle çalışma (sepet, oturum açma) |
| Statik proxy havuzu | 100-1000 IP'den oluşan bir listeniz var. Script, her istek için rastgele bir adres seçer. | Döngü ve yük dağılımı üzerinde tam kontrol gerektiğinde |
Pratik örnek: Wildberries taraması
Diyelim ki 10.000 ürünün fiyatını taramanız gerekiyor. Wildberries, bir IP'den dakikada 60 isteği engelliyor. Çözüm:
- İstek başına döngüyü kullanın — her istek yeni bir IP ile gelir. Yaklaşık 167 farklı IP'ye ihtiyacınız var (10.000 istek / dakikada 60 = 167 dakika tek bir IP ile, ancak döngü ile bunu 10-15 dakikada yaparsınız).
- Gecikmeleri ayarlayın — döngü ile bile, saniyede 1000 istek yapmamalısınız. Optimal: farklı IP'lerle saniyede 5-10 istek.
- Rastgeleleştirme ekleyin — gecikmeler rastgele olmalıdır: istekler arasında 0.5 ile 2 saniye arasında değişmelidir.
Bu tür görevler için konut proxy'leri otomatik döngü ile mükemmel bir şekilde uygundur — milyonlarca IP'den oluşan havuzları vardır ve her istek için adresleri sizin müdahaleniz olmadan değiştirir.
İstekler arasındaki gecikmelerin ayarlanması
Proxy döngüsü ile bile, siteyi maksimum hızda isteklerle bombalamamalısınız. Modern koruma sistemleri sunucu üzerindeki genel yükü analiz eder ve DDoS benzeri bir etkinlik gördüklerinde tüm IP aralığını engelleyebilir.
Gecikme ayarlama kuralları
Temel kural: gerçek bir kullanıcıyı taklit edin
- Minimum gecikme: istekler arasında 0.5-1 saniye
- Tavsiye edilen: rastgele dağılım ile 1-3 saniye
- Karmaşık siteler için (pazar yerleri, sosyal medya): 2-5 saniye
- Hatalar durumunda üstel gecikme kullanın
Üstel gecikme (exponential backoff)
Eğer yine de 429 hatası aldıysanız, siteyi tekrar tekrar saldırmaya devam etmeyin. Üstel gecikme stratejisini kullanın:
- İlk deneme başarısız → 1 saniye bekleyin
- İkinci deneme başarısız → 2 saniye bekleyin
- Üçüncü deneme başarısız → 4 saniye bekleyin
- Dördüncü deneme başarısız → 8 saniye bekleyin
- Ve böyle devam edin, maksimuma kadar (örneğin, 60 saniye)
Bu strateji, sunucuya "soğuma" süresi tanır ve kalıcı yasaklama olasılığını azaltır. Birçok API (Google, Twitter) belgelerinde bu yaklaşımı önerir.
Farklı görevler için ayar örneği
| Görev | İstekler arasındaki gecikme | Açıklama |
|---|---|---|
| Wildberries taraması | 1-3 saniye | Proxy döngüsü ile 0.5-1 saniyeye kadar hızlandırılabilir |
| Ozon taraması | 2-4 saniye | Ozon, otomasyona daha duyarlıdır |
| Instagram API | 18 saniye | Limit 200 istek/saat = 18 saniyede 1 istek |
| Google Arama taraması | 5-10 saniye | Google hızlı bir şekilde yasaklıyor, uzun duraklamalar gerekiyor |
| Avito izleme | 3-6 saniye | Katı koruma, özellikle arama için |
User-Agent ve başlıklar: gerçek bir tarayıcıyı taklit etme
Proxy döngüsü ve gecikmeler, istek sıklığı sorununu çözer, ancak bu yeterli değildir. Siteler, isteklerinizi nasıl gönderdiğinizi analiz eder. Eğer başlıklar şüpheli görünüyorsa — engelleme kaçınılmazdır.
Tarayıcıyı taklit etmek için zorunlu başlıklar
Her istekte bulunması gereken minimum başlık seti:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0
User-Agent döngüsü
Tüm istekler için aynı User-Agent'ı kullanmayın. 10-20 güncel tarayıcı versiyonundan oluşan bir liste oluşturun ve bunları rastgele değiştirin:
- Chrome (Windows, macOS, Linux)
- Firefox (farklı versiyonlar)
- Safari (macOS, iOS)
- Edge (Windows)
Sık yapılan hata: Eski User-Agent'ların (örneğin, 2024'te Chrome 90) veya masaüstü siteleri için mobil User-Agent'ların kullanılması. Bu, otomasyonu hemen ortaya çıkarır.
Referer ve Origin
Birçok site, isteğin nereden geldiğini kontrol eder. Eğer bir ürün sayfasını tarıyorsanız, Referer başlığında katalog veya arama bağlantısı olmalıdır. API'yi tarıyorsanız — doğru Origin olmalıdır.
Wildberries taraması için bir örnek:
Referer: https://www.wildberries.ru/catalog/0/search.aspx?search=laptop
Origin: https://www.wildberries.ru
429'u aşmak için hangi proxy'leri seçmeli
Proxy türünün seçimi kritik öneme sahiptir. Ucuz veri merkezi proxy'leri genellikle kara listelerde bulunur ve düşük istek sıklığında bile 429 alırsınız.
Limitleri aşmak için proxy türlerinin karşılaştırılması
| Proxy türü | Avantajlar | Dezavantajlar | Hangi görevler için |
|---|---|---|---|
| Veri merkezleri | Yüksek hız, düşük fiyat | Sıklıkla yasaklanır, kolayca tespit edilir | Koruması olmayan basit siteler |
| Konut | Gerçek sağlayıcılardan IP'ler, tespit edilmesi zor, büyük adres havuzu | Daha pahalı, bazen daha yavaş | Pazar yerleri, sosyal medya, karmaşık siteler |
| Mobil | Mobil operatörlerden IP'ler, maksimum güven | Pahalı, sınırlı havuz | Instagram, TikTok, Facebook Reklamları |
Seçim önerileri
Pazar yerlerini taramak için (Wildberries, Ozon, Avito): İstek başına döngü ile konut proxy'leri kullanın. Havuz büyük olmalıdır — en az 10.000 IP. Bu, her IP'nin az sayıda istek yapmasını ve limitlere girmemesini garanti eder.
Sosyal medya API'leri ile çalışmak için: Mobil proxy'ler en iyi seçimdir. Instagram ve TikTok, mobil operatörlerin IP'lerine konut IP'lerinden daha fazla güveniyor. Bir mobil IP, 5-10 hesabı sorunsuz bir şekilde yönetebilir.
Rakip fiyatlarını izlemek için: Zamanlayıcıya göre döngü ile konut proxy'leri (her 10-15 dakikada bir). Bu, bir IP ile bir dizi istek yapmanıza olanak tanır, oturumu korur ancak limitleri aşmaz.
Basit görevler için (haberler, bloglar taraması): Veri merkezi proxy'leri, site ciddi bir korumaya sahip değilse uygun olabilir. Ancak, periyodik engellemelere hazırlıklı olun.
Gerçek vakalar: pazar yerleri ve API'ler taraması
Vaka 1: Wildberries'de fiyat izleme (günde 10.000 ürün)
Görev: Pazar yerinin satıcısı, 10.000 ürün için rakip fiyatlarını izliyor. Verileri günde 2 kez toplamak gerekiyor.
Sorun: Tek bir IP kullanıldığında 50-60 istektan sonra yasak alıyordu. 10.000 ürünün taranması, sürekli engellemelerle birkaç saat sürüyordu.
Çözüm:
- Konut proxy'leri ile 50.000 IP havuzuna ve istek başına döngüye bağlandım
- İstekler arasında 0.5 ile 2 saniye arasında rastgele gecikmeler ayarladım
- User-Agent döngüsü ekledim (20 farklı Chrome ve Firefox versiyonu)
- Doğru Referer ve Accept başlıklarını ayarladım
Sonuç: 10.000 ürünün taranması 15-20 dakika sürüyor ve tek bir engelleme olmuyor. Her IP maksimum 1-2 istek yapıyor, bu da otomasyon olarak tespit edilmesini imkansız kılıyor.
Vaka 2: Instagram otomasyonu (50 müşteri hesabı)
Görev: SMM ajansı, Instagram'da 50 müşteri hesabını yönetiyor. İçerik yayınlamak, yorumlara yanıt vermek ve istatistik toplamak gerekiyor.
Sorun: Instagram API'sinin uygulama başına 200 istek limiti var. 50 hesapla çalışırken limitler 10 dakika içinde tükeniyordu.
Çözüm:
- 10 farklı Instagram API uygulaması oluşturduk (her uygulamada 5 hesap)
- Her uygulama ayrı bir mobil proxy kullanıyor
- İstekler arasında 18 saniye gecikme ayarladık (200 istek/saat = 18 saniyede 1 istek)
- 429 hatası alındığında üstel gecikme ekledik
Sonuç: Tüm 50 hesap stabil bir şekilde çalışıyor. 429 hataları çok nadir (haftada 1-2 kez) meydana geliyor ve otomatik olarak tekrar denemelerle işleniyor.
Vaka 3: Avito taraması (tüm Rusya'daki ilanlar)
Görev: Gayrimenkul toplayıcısı, Avito'dan tüm şehirlerdeki ilanları veritabanı için topluyor.
Sorun: Avito, Rus siteleri arasında en katı korumalara sahip. Veri merkezi IP'leri ile bile 10-15 istekten sonra engellemeler başlıyordu.
Çözüm:
- Coğrafi konumlu konut proxy'lerine geçiş (tarama yapılan şehirden IP'ler)
- İstekler arasında 3-5 saniye gecikme artırma
- Basit HTTP istekleri yerine headless tarayıcı (Puppeteer) kullanma
- Kullanıcı davranışlarını taklit etme: kaydırma, tıklama, fare hareketleri
Sonuç: Günde 50.000+ ilan başarıyla tarandı. Engellemeler %95 oranında azaldı. Kalan %5, yeni IP ile tekrar denemelerle işleniyor.
Vaka 4: Rakiplerin API'lerini izleme (e-ticaret)
Görev: İnternet mağazası, 20 rakibin API'si üzerinden ürünlerin mevcudiyetini ve fiyatlarını izliyor.
Sorun: Rakiplerin çoğu API'si, kamuya açık limitlere sahiptir (saatte 100-500 istek). Aşılması durumunda 429 döner.
Çözüm:
- Önceliklere göre istek kuyruğu oluşturma (en önemli ürünler daha sık kontrol edilir)
- Yanıt başlıkları üzerinden limitleri izleme (X-RateLimit-Remaining)
- Limitin %80'ine ulaşıldığında otomatik duraklama
- Her rakip için birden fazla API anahtarı kullanma (mümkünse)
Sonuç: Sistem, istekleri asla limitleri aşmayacak şekilde otomatik olarak dağıtır. Veriler, engellemeler olmadan mümkün olan en yüksek sıklıkta güncellenir.
Tüm vakalardan alınan genel ders:
429 hatası, bütünsel bir şekilde çözülür: proxy döngüsü + doğru gecikmeler + gerçek davranış taklidi. Sadece bir yönteme güvenmek yeterli değildir. Milyonlarca IP ile bile, şüpheli başlıklarla saniyede 1000 istek yaparsanız engellenirsiniz.
Sonuç
429 Aşırı İstek hatası, sitelerin koruma mekanizmasıdır ve doğru yaklaşım ile aşılabilir. Sorunun çözümündeki ana ilkeler:
- IP adreslerinin döngüsü — yükü birçok proxy arasında dağıtın, böylece her adres minimum istek yapar
- Doğru gecikmeler — rastgele duraklamalar ile gerçek bir kullanıcıyı taklit edin, 1 ile 5 saniye arasında
- Doğru başlıklar — güncel User-Agent ve tam tarayıcı başlık setini kullanın
- Proxy türünün seçimi — karmaşık siteler için (pazar yerleri, sosyal medya) konut veya mobil proxy'ler kullanın
- Hata işleme — 429 hatası alındığında üstel gecikme uygulayın, siteye tekrar saldırmayın
Unutmayın: amaç, korumayı her ne pahasına olursa olsun aşmak değil, otomasyonunuzun mümkün olduğunca doğal görünmesini sağlamaktır. Modern koruma sistemleri giderek daha akıllı hale geliyor ve kaba kuvvet artık işe yaramıyor.
Eğer pazar yerlerini tarama, rakip izleme veya sosyal medyada otomasyon yapmayı planlıyorsanız, konut proxy'lerini denemenizi öneririz — büyük bir IP havuzu, otomatik döngü ve minimum engellenme riski sağlar. Instagram, TikTok ve diğer mobil platformlarla çalışmak için mobil proxy'ler daha uygundur, çünkü gerçek iletişim operatörlerinden IP'ler sunar.