Hata 429: Proxy dışında 6 neden.

Proxy değiştiriyorsunuz, yeni bir IP havuzu satın alıyorsunuz ama yine de 429 Too Many Requests hatası alıyorsunuz mu? Bu klasik bir durumdur: engellemelerin %70'i IP adresiyle değil, isteğin kendisiyle ilgilidir. Proxy değiştirmenize rağmen sitenin sizi neden engellediğine dair altı gerçek nedeni inceleyelim ve her durumda ne yapmanız gerektiğini gösterelim.

Hata 429 ne anlama geliyor ve neden proxy bir çözüm değil

HTTP kodu 429 Too Many Requests, resmi olarak "istek limiti aşıldı" anlamına gelir. Ancak pratikte, siteler — özellikle Wildberries, Ozon, Avito, Yandex.Market — bu kodu "biz sizi bot olarak düşünüyoruz" şeklinde evrensel bir sinyal olarak kullanıyor. Sebep istek sıklığı olabilir, ancak aynı olasılıkla başlıklar, tarayıcı parmak izi, çerez oturumu eksikliği veya IP'ye değil, hesabınıza bağlı limitler de olabilir.

Bu nedenle, proxy değişikliği genellikle işe yaramaz: sistem IP'yi değil, istek desenini (parmak izi, başlıklar, tıklama hızı) engelliyorsa, yeni bir IP adresinden birkaç dakika içinde yine aynı 429 hatasını alırsınız. Her bir nedeni ayrıntılı olarak inceleyelim ve yeni bir proxy havuzu satın almadan nasıl kontrol edip giderebileceğinizi gösterelim.

Önemli: proxy, gerekli bir araç olmaya devam ediyor — ama sadece sistemin bir parçası olarak, tek başına bir çözüm olarak değil. Yerleşik ve mobil IP'ler, IP itibarına göre kara listeye alınma olasılığını azaltır, ancak davranış veya başlıklar nedeniyle engellenmekten kurtarmaz.

Neden 1: Çok yüksek istek sıklığı

En belirgin ama en sık yanlış teşhis edilen neden. Birçok kişi "her istekte proxy değiştiriyorum — sıklık önemli değil" diye düşünüyor. Bu yanlış. Modern anti-bot sistemleri (örneğin, Wildberries ve Ozon'da Cloudflare seviyesinde veya kendi WAF çözümleri var) sadece bir IP'den gelen istek sıklığını değil, belirli bir API uç noktasına veya ürün sayfasına tüm kaynaklardan gelen toplam yükü ve davranışsal sinyalleri de analiz eder.

Eğer parser'ınız bir katalog bölümüne saniyede 50-100 istek yapıyorsa, sistem anormal bir trafik patlaması görüyor, kullandığınız farklı IP sayısından bağımsız olarak. Çözüm, proxy değişikliği değil, istekler arasında yapay gecikmeler (throttling) uygulamaktır: sabit bir aralık yerine 1-3 saniye rastgele gecikme, artı 429 alındığında üstel backoff (her engellemeden sonra bekleme süresini iki katına çıkarma).

import time, random

def safe_request(session, url):
    for attempt in range(5):
        response = session.get(url)
        if response.status_code == 429:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        return response
    return None

Eğer kodu olmayan bir hazır parser kullanıyorsanız (örneğin, bulut tabanlı fiyat izleme servisi), istekler arasındaki aralık ayarlarını kontrol edin — çoğu böyle araçta "tarama hızı" kaydırıcısı vardır. Hızı %30-40 oranında azaltmak, genellikle proxy değişikliği olmadan 429'u tamamen ortadan kaldırır.

Neden 2: Yanlış veya eksik başlıklar

Birçok parser, minimum başlık seti ile istek gönderir veya varsayılan kütüphane User-Agent'ını kullanır (örneğin, "python-requests/2.28.1"). Böyle bir başlık hemen botu ifşa eder — gerçek bir tarayıcı onlarca başlık gönderir: Accept, Accept-Language, Accept-Encoding, Sec-Fetch-*, Referer ve diğerleri belirli bir sırayla.

Wildberries ve Ozon, başlık setini gerçek Chrome veya Safari tarayıcısının beklenen "parmak izi" ile karşılaştırır. Eğer başlıklar çok azsa, yanlış sıradaysa veya User-Agent diğer parametrelerle (örneğin, Windows'ta Chrome olarak beyan edilmiş ama TLS parmak izi Python'a benziyorsa) uyuşmuyorsa — istek 429 ile engellenir, IP'den bağımsız olarak.

Başlık	Tipik hata	Çözüm
User-Agent	Eski bir versiyon veya açıkça kütüphane dizesi	Gerçek Chrome/Safari'den güncel UA, havuzdan döngü
Accept-Language	Eksik veya IP'nin coğrafi konumuyla uyuşmuyor	Rusya pazarları için ru-RU
Referer	Boş, oysa gerçek geçiş her zaman Referer ile olur	Önceki katalog sayfasını belirtin
Sec-Fetch-*	Tamamen yok (tarayıcı istemcisi değil)	Gerçek bir tarayıcıdan DevTools'tan tam seti kopyalayın

En kolay yol, gerçek bir tarayıcıda Network sekmesinden tam başlık setini kopyalamak, gerekli sayfayı manuel olarak açmak ve bu seti parser'da kullanmaktır — başlıkların sırasına dikkat ederek, eğer kütüphane bunu destekliyorsa (örneğin, curl_cffi veya açık sıralı httpx).

Neden 3: Oturum ve çerezlerin döngüsünün olmaması

Sıklıkla gözden kaçan bir hata: parser her istekte IP'yi değiştiriyor, ancak aynı çerez oturumunu kullanıyor veya hiç çerez saklamıyor. Gerçek bir kullanıcı, ilk ziyarette bir çerez seti alır (oturum tokenleri, cihaz kimlikleri, Cloudflare __cf_bm veya Ozon/WB'deki benzeri antibot koruma etiketleri) ve bunları sonraki tüm isteklerde oturum içinde kullanır.

Eğer çerez olmadan istek gönderiyorsanız, "ısınmış" bir sayfadan alınan çerezler olmadan, anti-bot sistemi "sıfır" bir oturum görüyor — bu hemen şüpheli görünür, özellikle API uç noktalarına doğrudan erişim sağlarken, ana sayfayı atlayarak. Çözüm, tam bir senaryoyu taklit etmektir: önce ana sayfayı veya kategori sayfasını yüklemek, çerezleri almak, 1-2 saniye beklemek ve yalnızca sonra gerekli API veya ürün kartına erişmek, istekler zinciri boyunca çerezleri aynı oturumda saklamaktır.

import requests

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Accept-Language": "ru-RU,ru;q=0.9"
})

# Oturum ısınması
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# Artık çerezlerle ana istek
response = session.get(target_url)

Eğer Dolphin Anty veya AdsPower gibi anti-detect tarayıcı kullanıyorsanız, ürün kartlarını manuel olarak veya yerleşik otomasyonla izlemek için, profilin oturumlar arasında çerezleri sakladığından ve her seferinde "temiz bir sayfadan" başlamadığından emin olun — bu da sistemin şüphelenmesine neden olur.

Neden 4: Bot benzeri davranış

Mükemmel başlıklar ve çerezlerle bile, parser davranışsal kalıplarla kendini ifşa edebilir: ürünlere erişimde katı bir sıralama (ID'ye göre artan), istekler arasında milisaniye cinsinden aynı aralık, normal bir tarayıcının otomatik olarak yüklediği statik kaynaklara (resimler, CSS, JS) "çöp" isteklerinin olmaması.

Gelişmiş koruma sistemleri Wildberries ve Ozon, sadece HTTP isteklerini değil, aynı zamanda sayfada JavaScript'in çalışıp çalışmadığını (headless tespit yoluyla), "fare" hareketinin olup olmadığını, kaydırma olup olmadığını da analiz eder. Eğer temiz HTTP istekleri yapıyorsanız ve JS'nin çalıştırılması bekleniyorsa (örneğin, anti-bot javascript-challenge), bu script çalıştırılmadan yapılan istek otomatik olarak 429 veya 403 alır.

Çözüm, ölçeğe bağlıdır: küçük hacimler için fare hareketlerini ve rastgele gecikmeleri taklit eden headless tarayıcı (Playwright, Puppeteer) kullanmak uygundur. Endüstriyel ölçekte veri çekimi için — ürünlerin dolaşım sırasını rastgeleleştirmek, ikincil kaynaklara "gürültü" istekleri eklemek, zaman aralıklarını normal dağılıma göre değişken hale getirmek, sabit bir adım yerine.

Neden 5: TLS/JA3 parmak izi ve HTTP/2

Bu, derin teknik bilgiye sahip olmayan %90'lık bir kesimin bilmediği en "gizli" teknik neden. Her TLS istemcisi (requests kütüphanesi, curl, urllib) HTTPS bağlantısı kurarken benzersiz bir parmak izi bırakır — desteklenen şifreler, protokol sürümleri, TLS uzantıları seti. Bu parmak izi JA3/JA4 parmak izi olarak adlandırılır.

Cloudflare, Akamai ve büyük pazar yerlerinin kendi çözümleri gibi anti-bot sistemleri, JA3 parmak izini bilinen botlar ve kütüphaneler veritabanıyla karşılaştırır. Standart Python requests veya Node.js https modülü, gerçek Chrome'dan tamamen farklı, kolayca tespit edilebilen bir parmak izine sahiptir. Mükemmel başlıklar ve çerezlerle bile, istek TLS-handshake seviyesinde engellenir, sunucu HTTP başlıklarını görmeden önce.

Ayrıca birçok pazar yeri belirli parametrelerle HTTP/2 gerektirir (SETTINGS çerçevelerinin sırası, akışların önceliklendirilmesi) — HTTP/1.1 tabanlı kütüphaneler bu bağlamda otomatik olarak belirginleşir. Çözüm, gerçek bir tarayıcı parmak izini taklit eden kütüphaneler kullanmaktır: curl_cffi (Chrome TLS parmak izini taklit eder), tls-client veya "gerçek" parmak izi veren tam teşekküllü headless tarayıcılar.

pip install curl_cffi

Örnek: curl_cffi.requests.get(url, impersonate="chrome120") — kütüphane otomatik olarak gerçek Chrome 120'ye eşit bir TLS parmak izi ekler.

Neden 6: Hesap veya API anahtarı seviyesinde limit

Eğer resmi veya yarı resmi bir pazar yeri API'si üzerinden çalışıyorsanız (örneğin, Wildberries satıcı API'si veya Ozon Satıcı API'si), 429 IP'ye değil, satıcı hesabınıza veya API token'ınıza bağlı olabilir. Bu durumda proxy değiştirmenin hiçbir anlamı yoktur — limit, sunucu tarafında sizin hesap kimliğinize bağlı olarak saklanır ve bu hesaptan gelen her IP aynı sınırlamayı alır.

Bu durum, aynı anda rakiplerin fiyatlarını izleyen ve API'den stokları çeken satıcılar için tipiktir — her iki istek akışı toplam hesap limitine eklenir. Çözüm, yükü zamanla dağıtmak, resmi API kotalarını daha ekonomik kullanmak (her dakika değişmeyen verileri önbelleğe almak) ve rakiplerin fiyatlarını izlemek için ayrı bir yetkilendirilmemiş istek akışı kullanmaktır, bu da satıcı hesabına bağlı değildir.

Bunu kontrol etmek basittir: eğer 429, temiz yeni bir IP ile ve önceki oturumlardan hiçbir çerez olmadan bile devam ediyorsa, ancak yan sekmede kişisel hesabınıza giriş yaptıysanız — muhtemelen limit hesapla ilgilidir.

Gerçek nedeni nasıl teşhis edersiniz

Altyapınızı değiştirmeden önce, aşağıdaki algoritmaya göre bir teşhis yapın. Öncelikle, normal bir tarayıcıda sayfayı manuel olarak açın ve canlı bir davranışla 429'un ortaya çıkmadığından emin olun — bu, sorunun parser tarafında olduğunu ve bölgesel bir engelleme olmadığını doğrular.

Daha sonra, parser'ınızın başlıklarını gerçek bir tarayıcının başlıklarıyla DevTools üzerinden karşılaştırın (Network sekmesi → Copy as cURL). Eğer fark minimumsa, TLS parmak izini tls.peet.ws gibi hizmetler aracılığıyla kontrol edin — kütüphanenizle bir istek gönderin ve JA3 hash'ini referans tarayıcı ile karşılaştırın. Eğer istek TLS-handshake aşamasında düşüyorsa (bağlantı HTTP yanıtı alınmadan kopuyorsa) — sebep parmak izindedir, sıklıkta veya başlıklarda değil.

Daha sonra, limitin IP'ye mi yoksa hesaba mı bağlı olduğunu kontrol edin: yeni temiz bir IP'den yetkilendirme olmadan bir istek yapın. Eğer 429 kaybolursa — sorun önceki IP'nin itibarında veya bu adresten gelen sıklıkta olabilir. Eğer 429 devam ederse — sebebi başlıklarda, TLS'de veya davranışta arayın, proxy'de değil.

Proxy değiştirmeden 429'u gidermek için kontrol listesi

İstekler arasında sabit bir aralık yerine 1-4 saniye rastgele gecikmeler ekleyin.
Gerçek bir tarayıcının tam başlık setini kopyalayın, Sec-Fetch-* ve Accept-Language dahil.
Aynı oturum içinde çerezleri saklayın ve iletin, ana sayfayı ısıtarak başlayın.
Kütüphanenizin TLS parmak izini kontrol edin — temiz bir HTTP istemcisi yerine curl_cffi veya headless tarayıcı kullanın.
Sayfaların dolaşım sırasını rastgeleleştirin ve statik kaynaklara "gürültü" istekleri ekleyin.
API hesabı yükünü ve anonim fiyat izleme yükünü farklı akışlara ayırın.
429 alındığında anında tekrar isteği değil, üstel backoff uygulayın.
Yukarıdaki tüm maddeleri kontrol ettikten sonra — proxy değiştirin veya IP havuzunu genişletin.

Ne zaman proxyye ihtiyaç var ve hangilerini seçmelisiniz

Tüm altı nedeni giderdikten sonra, proxy hala altyapının önemli bir unsuru olmaya devam ediyor — ama artık bir ölçeklendirme aracı olarak, engellemelerle başa çıkmanın tek yolu değil. Göreviniz, Wildberries ve Ozon'da binlerce ürün kartını farklı "sanal kullanıcılar" ile paralel olarak izlemekse, iyi bir itibar ile bir IP havuzuna ihtiyacınız var, böylece tek bir adreste engelleme geçmişi birikmez.

Toplu fiyat izleme ve pazar yeri katalogları için en iyi seçenek yerleşik proxylerdir — gerçek ev sağlayıcılarının IP'lerini kullanırlar, bu nedenle anti-bot sistemleri istekleri normal alıcıların trafiği olarak algılar, veri merkezinin trafiği olarak değil. Bu kritik bir noktadır, çünkü Wildberries ve Ozon, veri merkezi IP'lerinin aralıklarını kara listeye almıştır.

Eğer görev mobil versiyonun kontrolü, pazar yeri uygulaması üzerinden çalışma veya TikTok Ads ve Facebook Ads'de şehir bazında reklam testleri ile ilgiliyse, mobil proxyler geçerlidir — bunların çoğu koruma sisteminde en yüksek güven düzeyine sahiptir, çünkü IP'ler gerçek mobil operatörlere aittir.

Daha az hassas görevler için — örneğin, küçük hacimlerde yetkilendirme gerektirmeyen açık katalogların parse edilmesi — veri merkezi proxyleri kullanılabilir: bunlar çok daha ucuz ve hızlıdır, ancak başlıkların ve TLS parmak izinin daha dikkatli bir şekilde ayarlanmasını gerektirir, çünkü kendileri daha yüksek bir şüphe altına girme riski taşır.

Proxy türü	Ne zaman 429'u çözer	Ne zaman yardımcı olmaz
Yerleşik	IP zaten itibar nedeniyle kara listede	TLS parmak izi veya başlıklar nedeniyle engelleme
Mobil	Hassas senaryolar için IP'nin maksimum güvenilirliğine ihtiyaç var	Limit hesaba bağlı, IP'ye değil
Veri merkezi	Yetkilendirme gerektirmeyen açık sayfaların basit parse edilmesi	İtibar kontrolü ile sıkı anti-bot sistemleri

Sonuç

Parse işlemi sırasında Hata 429, genellikle "proxy değiştir" butonuyla çözülmez. Çoğu durumda, sorun istek sıklığında, eksik başlıklarda, çerez oturumu eksikliğinde, tespit edilebilir TLS parmak izinde, davranışsal kalıplarda veya IP adresine değil, hesaba bağlı limitlerde yatmaktadır. Bu makaledeki altı maddeden her birini kontrol etmeden, proxy havuzunu genişletmek için bütçenizi harcamadan önce teşhis yapın.

Teknik kısım doğru ayarlandığında — başlıklar gerçek bir tarayıcıya uyduğunda, TLS parmak izi kütüphaneyi ifşa etmediğinde ve istekler kullanıcı davranışını taklit ettiğinde — proxy gerçekten etkili bir ölçeklendirme aracı haline gelir. Wildberries ve Ozon'da endüstriyel ölçekte fiyat izleme için yerleşik proxyleri kullanmanızı öneririz: bunlar maliyet ve anti-bot sistemleri güven düzeyi arasında en iyi dengeyi sağlar.