429 Too Many Requests Çözümü: Hız Sınırı ve Rotasyon

429 Too Many Requests çözümü, hedef sunucunun hangi ölçüye göre saydığını bulmakla başlar: sunucu belirli bir pencerede sizden beklediğinden fazla istek gördü ve kalanları reddetti. Kod, isteğin biçiminin bozuk olduğunu söylemez; aynı isteği daha yavaş ya da başka bir kimlikle gönderseydiniz kabul edilecekti. Bu yüzden 429, bir hata ayıklama sorunu olmaktan çok bir hız ve dağıtım sorunudur.

429 sıklıkla 403 ve 503 ile karıştırılır. 403, sunucunun sizi tanıyıp isteği reddettiğini anlatır; IP itibarı, parmak izi ya da coğrafi kısıt söz konusudur ve yavaşlamak tek başına çözmez. 503 ise sunucunun kendi tarafındaki yoğunluğu gösterir; sizin hızınızla ilgisi olmayabilir. Yalnız 429, sayacın sizin trafiğiniz için işlediğini açıkça söyler. Rotating proxy bu üç koddan en çok 429 üzerinde etkilidir, çünkü sayaç çoğu zaman IP başına tutulur ve çıkış IP’si değişince sayaç da sıfırdan başlar.

Bir 429 yanıtı aldığınızda gövdeden önce başlıklara bakın. Retry-After başlığı saniye cinsinden bir süre ya da bir tarih taşır; sunucu bu süre dolmadan gelen isteği yine reddeder. Bazı hedefler RateLimit-Limit, RateLimit-Remaining ve RateLimit-Reset ya da X-RateLimit öneki ile pencere büyüklüğünü ve kalan hakkı açıkça yazar. Bu değerleri loglamak, sınırın dakikada mı saatte mi işlediğini tahmin etmek yerine okumanızı sağlar.

Başlık yoksa pencereyi kendiniz ölçün. Tek bir sabit IP’den, bekleme koymadan art arda istek gönderin ve kaçıncı istekte 429 geldiğini, ardından ilk başarılı isteğe kadar kaç saniye geçtiğini not edin. İki ya da üç tekrar, çoğu hedefte pencereyi ve kotayı yeterli doğrulukla verir. Bu ölçümü küçük bir test turunda yapın; RotatingProxy kataloğundaki GB bazlı paketler süre sınırı taşımadığı için birkaç yüz isteklik test kotadan fark edilir bir pay almaz.

Ölçtüğünüz sayıyı istemcinize yazın. requests ve httpx tabanlı toplayıcılarda bu, isteklerin arasına koyduğunuz bekleme süresi ve eşzamanlı istek sayısı demektir; Scrapy’de ise DOWNLOAD_DELAY ve CONCURRENT_REQUESTS_PER_DOMAIN ayarlarıdır. Pencereyi bilmeden rotasyona geçmek, sorunu çözmek yerine daha çok IP üzerinde aynı sorunu yaymak anlamına gelir.

Aynı 429 kodu dört farklı sayaçtan gelebilir ve her birinin çözümü farklıdır. Hangisiyle karşı karşıya olduğunuzu üç kısa deneyle ayırt edersiniz. Birinci deney: aynı IP’den hızı yarıya indirin. Hata kesiliyorsa sayaç IP ya da oturum başına çalışıyordur. İkinci deney: hızı değiştirmeden çıkış IP’sini değiştirin. Hata kesiliyorsa sayaç IP başınadır ve rotasyon doğrudan işe yarar. Üçüncü deney: IP’yi değiştirdiğiniz halde ilk istekte bile 429 alıyorsanız sayaç IP’ye bakmıyordur; giriş yapılmış hesap, API anahtarı, çerez ya da tarayıcı parmak izi üzerinden sayıyordur.

Hesap ya da API anahtarı bazlı sınırda rotating proxy tek başına çözüm değildir; hangi IP’den gelirseniz gelin sayaç aynı anahtara yazılır. Burada yapılacak iş, isteği hedefin belgelediği kotaya sığdırmak ya da işi birden fazla yetkili anahtara bölmektir. Çerez bazlı sayaçta ise rotasyonla birlikte oturumu da yenilemek gerekir; IP değişirken aynı çerez taşınırsa sunucu sizi aynı ziyaretçi olarak saymaya devam eder.

Parmak izi bazlı sayaç, tarayıcı tabanlı toplayıcılarda görülür ve genellikle 429 yerine 403 ya da doğrulama sayfası üretir. Yine de bazı hedefler aynı tarayıcı profilinden gelen istekleri IP’den bağımsız sayar. Playwright ile çalışıyorsanız her IP değişiminde yeni bir tarayıcı bağlamı açmak sayaçları ayırır; bağlam ile IP’yi eşleştirmenin ayrıntılarını Scrapy ve Playwright rehberinde anlattık.

IP başına sayan bir hedefte istek başına rotasyon, trafiğinizi havuzdaki IP’lere dağıtır; her IP sayaçta yalnız birkaç istekle görünür ve pencere dolmaz. RotatingProxy kataloğundaki IPv4 datacenter ürünü istek başına ya da oturum bazlı rotasyon sunar; IPv4 residential ve mobile ürünlerde sticky ve rotating oturum seçenekleri vardır. 429 için doğru ayar çoğu zaman istek başına rotasyondur, çünkü amaç aynı IP’nin üst üste görünmemesidir.

Sticky oturum tam tersini yapar: belirli bir süre boyunca aynı IP’de kalırsınız. Giriş gerektiren akışlarda ve sepet gibi çok adımlı işlemlerde bu zorunludur, ama o IP’nin sayacı yine dolar. Sticky oturumda 429 alıyorsanız çözüm, oturum başına istek sayısını hedefin penceresinin altında tutmak ve pencere dolmadan yeni oturuma geçmektir. Oturum süresi ile pencere süresi aynı hizadaysa, her oturum tam sınırda biter ve 429 hiç görünmez.

Rotasyonun işe yaramadığı iki durum vardır. İlki, yukarıda anlatılan hesap ve anahtar bazlı sayaçlardır. İkincisi, hedefin IP yerine alt ağı ya da ASN’yi sayması: aynı /24 bloğundan gelen istekleri tek kaynak sayan bir hedefte datacenter havuzunun bir bölümü aynı sayaca yazılabilir. Böyle hedeflerde residential ya da mobile havuzuna geçmek, IP’lerin farklı ev ve operatör ağlarından çıkması nedeniyle sayaçları ayırır. Hangi havuzun uygun olduğunu küçük bir test turuyla görürsünüz; hedef bazlı havuz seçimini kota rehberinde ayrıca ele aldık.

Üç ayar birlikte düşünülür. Eşzamanlılık, aynı anda kaç isteğin açık olduğunu söyler; bekleme, iki istek arasındaki boşluğu; yeniden deneme ise 429 geldiğinde ne yapılacağını. Rotasyon açıkken eşzamanlılığı IP sayısına göre değil, hedefin toplam toleransına göre ayarlayın: havuz büyük olsa bile hedef sunucu toplam trafiği de izleyebilir ve ani bir sıçrama, sayaç IP başına olsa dahi genel bir yavaşlatmaya yol açabilir.

Yeniden deneme mantığını 429’a özel kurun. Retry-After başlığı varsa o süre kadar bekleyin; yoksa birinci denemede bir, ikincide iki, üçüncüde dört saniye gibi katlanan bir bekleme uygulayın ve üç denemeden sonra isteği kuyruğa geri koyun. Rotasyonlu proxy’de her deneme zaten yeni bir IP’den çıkar; bekleme süresi hedefin genel toleransında yer açar. Katlanan beklemeye küçük bir rastgele pay eklemek, aynı anda hata alan worker’ların aynı saniyede tekrar vurmasını önler.

Bekleme süresini yanıttan öğrenin, sabit yazmayın. Her başarılı isteğin ardından kalan hak başlığını okuyup sıfıra yaklaştığında hızı kendiliğinden düşüren bir toplayıcı, sabit bekleme koyan toplayıcıdan hem daha hızlı hem daha az 429 alır. Başlık yoksa son bir dakikadaki 429 oranını hesaplayıp belirli bir eşiği aştığında eşzamanlılığı yarıya indiren basit bir geri bildirim döngüsü aynı işi görür. Python tarafındaki proxy ayarları ve oturum kullanımı için requests ve httpx rehberine bakabilirsiniz.

Sayılar varsayımdır; kendi ölçümünüzle değiştirin. Ölçüm sonucu hedefin IP başına dakikada 30 istek kabul ettiğini ve işinizin saatte 36.000 sayfa gerektirdiğini düşünelim. Saatte 36.000, dakikada 600 istek eder. Tek IP’den bu hız yirmi kat fazladır. İstek başına rotasyonla her istek farklı bir IP’den çıkarsa her IP dakikada bir ya da iki istekle görünür ve sınırın çok altında kalır; bu durumda darboğaz hedefin IP sayacı olmaktan çıkar, istemcinizin eşzamanlılığı ve hedefin toplam toleransı olur.

Sticky oturumla çalışmak zorundaysanız hesap değişir. Her oturumun on dakika sürdüğünü ve o sürede en fazla 300 istek atabileceğini bilirsiniz; dakikada 600 istek için aynı anda en az yirmi oturum gerekir. Oturum sayısını yirmi beşe çıkarmak her oturumu sınırın altında tutar ve 429 görmeden pencereyi doldurmazsınız. Bu hesabı yaparken yeniden denemelerin de istek olduğunu unutmayın; her 429, bütçeden bir istek yer ve GB bazlı pakette kotadan da düşer.

Çözümün tuttuğunu tek bir sayıyla görürsünüz: toplam istek içindeki 429 payı. Bu oranı hedef alan adı başına ayrı tutun; bir hedefte sıfıra inen oran başka bir hedefte yükseliyor olabilir. Loglarda her isteğin durum kodunu, kullanılan oturum kimliğini ve Retry-After değerini saklayın. Oran hedef başına birkaç yüzdeyi geçtiğinde eşzamanlılığı düşürün; sıfıra yakın seyrederken yavaş yavaş artırın. Bu döngü, hedefin sınırını bir kez ölçüp sonsuza kadar sabit kalmaktan daha dayanıklıdır, çünkü hedefler kurallarını haber vermeden değiştirir.

İkinci ölçü, 429 sonrası ilk başarılı yanıta kadar geçen süredir. Bu süre Retry-After değerinden sürekli uzunsa hedef pencereyi büyütmüş ya da sizi başka bir sayaca almış demektir; teşhis adımına geri dönüp sayacın hâlâ IP başına olup olmadığını yeniden test edin. Üçüncü ölçü, tekrar sayısıdır: üç denemede de 429 alan istek oranı artıyorsa rotasyon yeterli gelmiyordur ve havuz türünü değiştirme zamanı gelmiştir. Kimlik doğrulama hataları, zaman aşımı ve protokol uyumsuzluğu gibi 429 dışındaki bağlantı sorunlarını ayrı bir rehberde topladık.