429 Too Many Requests Hatası Nedir? Nedenleri ve Çözümü

429 Too Many Requests, bir sunucunun belirli bir zaman diliminde kabul ettiğinden daha fazla istek aldığında döndürdüğü HTTP durum kodudur. Yani sunucu size şunu söyler: “Çok hızlı geliyorsun, biraz yavaşla.” Hata, sunucunun çöktüğü anlamına gelmez. Tam tersine, sunucu kendini korumak için bilinçli olarak kapıyı kapatmıştır.

Bu hatayla iki farklı taraftan karşılaşabilirsiniz. Bir siteyi gezerken ekranınıza düşerse sorun genelde birkaç dakikada geçer. Ama kendi sitenizde görüyorsanız, altında yatan gerçek bir sebep vardır ve bulunması gerekir. Bu rehberde her iki durumu da ele alıyoruz: hatanın ne anlama geldiğini, hangi nedenlerden çıktığını, ziyaretçi ve site sahibi olarak nasıl çözüleceğini, WordPress ile API tarafındaki özel durumları ve Googlebot üzerinden SEO’ya etkisini adım adım anlatıyoruz.

429 Too Many Requests Hatası Ne Anlama Gelir?

429, HTTP protokolündeki 4xx ailesine aittir. Bu ailedeki kodlar, sorunun sunucuda değil istemci tarafında olduğunu belirtir. Yani “sunucu bozuldu” değil, “gönderdiğin istekte bir problem var” mesajıdır. 429’un özel anlamı ise nettir: izin verilen istek sayısını aştınız.

Arka planda çalışan mekanizmanın adı rate limiting (istek sınırlama) olarak geçer. Sunucu, her ziyaretçinin belirli bir sürede kaç istek gönderebileceğini sayar. Bu sayı aşıldığında yeni istekleri işlemeyi bırakır ve 429 döndürür. Böylece tek bir kullanıcı ya da bot, sunucunun tüm kaynaklarını tüketemez.

Bu Hatayı Hangi Mesajlarla Görürsünüz?

429 hatası her sunucuda aynı görünmez. Kullanılan yazılıma ve güvenlik katmanına göre metin değişir. Karşınıza şu varyasyonlardan biri çıkabilir:

• 429 Too Many Requests — en yaygın ve standart hâli.
• Error 429 — sade, çıplak sürüm.
• Too many requests, please try again later — kullanıcı dostu uyarı metni.
• HTTP 429 – Rate limit exceeded — genelde API yanıtlarında görülür.
• You have sent too many requests in a given amount of time — WordPress ve bazı güvenlik eklentilerinin dili.

Mesaj farklı olsa da anlam aynıdır. Hepsi tek bir şeyi anlatır: gönderilen istek sayısı, izin verilen eşiği geçmiştir.

Retry-After Başlığı Ne Söyler?

429 yanıtının en çok gözden kaçan ama en değerli parçası Retry-After başlığıdır. Sunucu bu başlıkla size ne kadar beklemeniz gerektiğini açıkça bildirir. Yani körlemesine denemek yerine, tam olarak ne zaman tekrar deneyeceğinizi öğrenirsiniz.

Bu başlık iki formatta gelebilir. Ya saniye cinsinden bir sayı verir (Retry-After: 120 gibi), ya da bir tarih belirtir. İlkinde 120 saniye beklemeniz gerekir. İkincisinde ise belirtilen zamana kadar istek göndermemeniz beklenir.

Başlığı görmek için tarayıcınızın geliştirici araçlarını açıp Network sekmesine bakmanız yeterlidir. İlgili isteğe tıklayıp yanıt başlıklarını (response headers) incelediğinizde değeri görürsünüz. Komut satırından kontrol etmek isterseniz şu satır işinizi görür:

curl -I https://ornek-site.com/sayfa

Bir uygulama yazıyorsanız bu başlığı yok saymayın. Retry-After’a uyan bir istemci, sunucuyla kavga etmek yerine onunla anlaşır. Uymayan bir istemci ise limiti sürekli tetikler ve kalıcı olarak engellenebilir.

429 Hatasının En Yaygın Nedenleri

429 hatası tek bir sebepten çıkmaz. Kaynağı bulmak, çözümün yarısıdır. Aşağıdaki tablo, en sık karşılaşılan nedenleri belirtileri ve çözüm yönleriyle birlikte özetler.

Deneyimimiz: Müşteri projelerinde en sık rastladığımız kaynak, kaba kuvvet giriş denemeleridir. Site sahibi kendi sitesinden 429 aldığını söyler; loglara bakınca dünyanın öbür ucundan gelen yüzlerce wp-login.php denemesi çıkar. Yani hatayı sizin ziyaretçiniz değil, saldırgan tetiklemiştir.

Ziyaretçi Olarak 429 Hatasını Nasıl Çözersiniz?

Başkasının sitesinde 429 görüyorsanız işiniz kolaydır. Çoğu durumda sunucu sizi geçici olarak yavaşlatmıştır ve kısa sürede kapı yeniden açılır. Şu adımları sırayla deneyin:

• Birkaç dakika bekleyin. En basit ve en etkili çözüm budur. Retry-After başlığı varsa, orada yazan süre kadar bekleyin.
• Sayfayı üst üste yenilemeyin. Her yenileme yeni bir istek demektir ve sayacı sıfırlamak yerine besler.
• Tarayıcı önbelleğini ve çerezleri temizleyin. Bozuk bir oturum çerezi, arka planda tekrarlayan isteklere yol açabilir.
• Gizli sekmede deneyin. Böylece eklentilerin ve çerezlerin etkisini hızlıca elersiniz.
• Tarayıcı eklentilerini kapatın. Bazı eklentiler sayfa açıldığında arka planda çok sayıda istek gönderir.
• Ağ veya IP değiştirin. Mobil veriye geçmek çoğu zaman sorunu anında çözer, çünkü yeni bir IP ile gelirsiniz.
• DNS önbelleğini temizleyin. Windows’ta ipconfig /flushdns komutu bunu yapar.

Bu adımların hiçbiri işe yaramıyorsa ve hata saatlerce sürüyorsa, sorun büyük olasılıkla sizde değildir. O noktada yapılacak tek şey site sahibinin durumu çözmesini beklemektir.

Site Sahibi Olarak 429 Hatasını Nasıl Çözersiniz?

Kendi sitenizde 429 görüyorsanız, önce bir şeyi netleştirin: bu hata bir sonuçtur, sebep değil. Rastgele eklenti kapatmak yerine kaynağı bulun. Doğru sırayla ilerlerseniz çözüm genelde tek seferde gelir.

Önce Logları Okuyun ve Kaynağı Bulun

Teşhis koymadan tedavi olmaz. cPanel kullanıyorsanız “Ham Erişim Kayıtları” (Raw Access Logs) bölümünden log dosyalarını indirebilirsiniz. Sunucuya SSH ile bağlanabiliyorsanız işiniz daha da kolaydır. En çok istek gönderen IP adreslerini şu komutla listeleyebilirsiniz:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

Çıkan listede tek bir IP diğerlerinin kat kat üzerindeyse şüpheliniz bellidir. Aynı mantıkla en çok istenen sayfayı da bulabilirsiniz. Eğer liste başında wp-login.php veya xmlrpc.php varsa, karşınızda otomatik bir saldırı vardır.

WordPress Tarafında Yapılacaklar

WordPress siteleri 429 hatasını sıklıkla üç noktadan alır: giriş sayfası, XML-RPC ve zamanlanmış görevler. Üçünü de sırayla ele alalım.

Giriş sayfasını koruyun. Limit Login Attempts veya Wordfence gibi bir eklentiyle başarısız giriş denemelerini sınırlayın. Sadece siz giriş yapıyorsanız, sayfayı kendi IP’nize kilitlemek en temiz çözümdür:

<Files wp-login.php>
  Require ip 203.0.113.25
</Files>

XML-RPC’yi kapatın. Bu dosyayı aktif olarak kullanmıyorsanız açık bırakmanın anlamı yoktur. Saldırganların en sevdiği kapılardan biridir:

<Files xmlrpc.php>
  Require all denied
</Files>

wp-cron’u devre dışı bırakıp sunucu cron’una taşıyın. WordPress’in kendi zamanlayıcısı, her sayfa ziyaretinde tetiklenir. Trafik arttığında bu durum ciddi bir istek yüküne dönüşür. Önce wp-config.php dosyasına şu satırı ekleyin:

define('DISABLE_WP_CRON', true);

Ardından hosting panelinizden beş dakikada bir çalışacak gerçek bir cron görevi tanımlayın. Böylece görevler ziyaretçi trafiğinden bağımsız, kontrollü biçimde çalışır.

Eklenti ve temayı test edin. Hata belirli bir güncellemeden sonra başladıysa şüpheli bellidir. Tüm eklentileri kapatıp teker teker açarak sorunluyu bulun. Bu testi mümkünse canlı sitede değil, bir kopya (staging) ortamında yapın.

Sunucu Tarafında Rate Limit Ayarlayın

Nginx kullanıyorsanız istek sınırlamayı doğrudan yapılandırma dosyasından kurabilirsiniz. Aşağıdaki örnek, giriş sayfasına dakikada beş istek izni verir ve kısa süreli yığılmalara üç isteklik bir tolerans tanır:

limit_req_zone $binary_remote_addr zone=girisleri:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=girisleri burst=3 nodelay;
}

Apache tarafında ise iş biraz farklı yürür. .htaccess dosyası gerçek anlamda hız sınırlaması yapmaz; asıl koruma mod_evasive veya ModSecurity gibi sunucu düzeyi modüllerle sağlanır. Paylaşımlı hostingteyseniz bu modüller çoğunlukla sağlayıcı tarafından zaten yönetilir. O yüzden ayar isteğinizi destek ekibine iletmek en pratik yoldur.

Kaynak Yetersizse Paketi Yükseltin

Bazen ortada saldırı da hatalı eklenti de yoktur. Siteniz büyümüştür, o kadar. Paylaşımlı hosting paketlerinde eşzamanlı işlem ve giriş/çıkış limitleri bellidir. Trafiğiniz bu tavana dayandığında sunucu sizi frenlemeye başlar ve 429 sıklaşır.

Belirtisi oldukça tanıdıktır: hata özellikle yoğun saatlerde, kampanya günlerinde veya bir içeriğiniz yayıldığında ortaya çıkar. Böyle bir tabloda kalıcı çözüm ayar değil, kaynaktır. Kaynakları size özel ayrılan bir VDS sunucu ile bu tavanı tamamen kaldırabilirsiniz.

API Kullanırken 429 Hatası ve Exponential Backoff

Bir servisin API’sine bağlanıyorsanız 429 ile karşılaşmanız neredeyse kaçınılmazdır. Hemen her sağlayıcı, dakika veya saat başına bir istek limiti uygular. Limit aşıldığında ilk tepki genellikle yanlış olur: kodu hemen yeniden denemeye zorlamak. Bu, durumu daha da kötüleştirir.

Doğru yaklaşımın adı exponential backoff‘tur. Her başarısız denemede bekleme süresini katlayarak artırırsınız. Retry-After başlığı geliyorsa önce ona uyarsınız. Aşağıdaki örnek bu mantığı JavaScript ile uygular:

async function istekGonder(url, maxDeneme = 5) {
  for (let i = 0; i < maxDeneme; i++) {
    const yanit = await fetch(url);
    if (yanit.status !== 429) return yanit;

    const retryAfter = yanit.headers.get('Retry-After');
    const bekle = retryAfter
      ? Number(retryAfter) * 1000
      : Math.pow(2, i) * 1000;

    await new Promise(r => setTimeout(r, bekle));
  }
  throw new Error('İstek limiti aşıldı, deneme hakkı bitti.');
}

Kod tarafında alabileceğiniz iki önlem daha var. Birincisi önbellekleme: aynı veriyi tekrar tekrar istemek yerine sonucu bir süre saklayın. İkincisi toplu işlem: mümkünse tek tek değil, gruplar hâlinde istek gönderin. Bu ikisi birlikte istek sayınızı ciddi biçimde düşürür.

Cloudflare ve CDN Kaynaklı 429 Hataları

Bazen hata hiç sunucunuza ulaşmadan oluşur. Cloudflare gibi bir CDN veya güvenlik duvarı kullanıyorsanız, istek daha kenarda durdurulup 429 ile geri çevrilebilir. Bunun en belirgin işareti şudur: ziyaretçi hata aldığını söyler ama sunucu loglarında o isteğin izi yoktur.

Böyle bir durumda kontrol etmeniz gereken yer CDN panelidir. Rate Limiting kurallarınıza, WAF ayarlarınıza ve bot koruma seviyenize bakın. Kuralın eşiği gereğinden düşük ayarlanmışsa, normal ziyaretçileriniz bile takılabilir. Ayrıca kendi izleme araçlarınızı veya ödeme sağlayıcınızın bildirim adreslerini beyaz listeye almayı unutmayın.

429 Hatası SEO’yu Etkiler mi?

Evet, etkiler. Hem de çoğu site sahibinin tahmin ettiğinden daha fazla. Googlebot sitenizi tararken 429 yanıtı aldığında bunu bir sinyal olarak okur ve tarama hızını düşürür. Kısa süreli bir yavaşlama zararsızdır; Google zaten sunucunuzu yormamak için böyle davranır.

Asıl risk, durum uzadığında başlar. Google, 429 ve 503 gibi yanıtların günlerce sürmesi hâlinde ilgili adresleri taramayı bırakabilir ve zamanla dizinden düşürebilir. Yani birkaç saatlik bir aksaklık sorun değildir. Günlerce süren bir engelleme ise sıralamalarınızı doğrudan tehdit eder.

Bir başka tehlike de yanlış yapılandırılmış bot kurallarıdır. Agresif bir güvenlik ayarı, kötü niyetli botları engellerken Googlebot’u da yanlışlıkla kapıda bırakabilir. Bu yüzden Search Console’daki tarama istatistiklerini düzenli kontrol edin. Tarama isteklerinde ani bir düşüş görüyorsanız, sebebini 429 tarafında aramanız yerinde olur.

429, 503 ve Diğer Hata Kodları Arasındaki Farklar

429 sıklıkla başka hata kodlarıyla karıştırılır. Oysa her kodun anlattığı hikâye farklıdır. Aradaki farkı bilmek, teşhis süresini kısaltır.

Kısaca özetlemek gerekirse: 429 “yavaşla” der, 503 “şu an müsait değilim” der, 508 ise “paketinin sınırına dayandın” anlamına gelir. Üçü de kaynakla ilgilidir ama çözümleri birbirinden ayrışır.

429 Hatasını Önlemenin Yolları

Hatayı çözmek iyidir; tekrar etmesini engellemek daha iyidir. Aşağıdaki önlemler, 429’un kalıcı bir baş ağrısına dönüşmesini büyük ölçüde engeller:

• Giriş sayfasını sıkılaştırın. Deneme sınırı, güçlü parola ve iki adımlı doğrulama saldırı yüzeyini daraltır.
• Kullanmadığınız kapıları kapatın. XML-RPC ve gereksiz REST uçları açık kalmasın.
• Önbellekleme kullanın. Sayfa önbelleği, sunucuya ulaşan istek sayısını ciddi biçimde düşürür.
• Botları yönetin. robots.txt ile tarama hızını düzenleyin, zararlı botları güvenlik katmanında durdurun.
• Cron görevlerini denetleyin. Aynı anda çalışan ağır görevleri farklı saatlere yayın.
• Eklenti sayısını kontrol altında tutun. Her eklenti, arka planda ek istek anlamına gelebilir.
• İzleme kurun. Uptime ve hata izleme araçları, siz fark etmeden önce sizi uyarır.
• Kaynağınızı büyümenize göre planlayın. Trafiğiniz artıyorsa paketi zamanında yükseltin.

Deneyimimiz: Kurulumlarda gördüğümüz en pratik iki hamle, giriş sayfasını sıkılaştırmak ve sayfa önbelleği kurmaktır. Bu ikisi çoğu sitede 429 vakalarının büyük kısmını daha ortaya çıkmadan bitirir. Geriye kalan durumlar ise genelde gerçek bir kaynak ihtiyacına işaret eder.

Sıkça Sorulan Sorular

• 429 Too Many Requests hatası ne kadar sürer?
  Çoğu durumda birkaç dakika ile bir saat arasında kendiliğinden geçer. Süre, sunucunun rate limit ayarına bağlıdır. Yanıtta Retry-After başlığı varsa net süreyi orada görürsünüz. Saatlerce sürüyorsa altında çözülmemiş bir sebep vardır.
• 429 hatası virüs veya hack belirtisi midir?
  Doğrudan bir hack belirtisi değildir, ancak sinyal olabilir. Kaba kuvvet giriş denemeleri bu hatayı sıkça tetikler. Sitenizde tekrarlıyorsa logları inceleyip başarısız giriş denemelerini ve şüpheli IP’leri kontrol etmenizde fayda var.
• Sadece ben 429 alıyorum, diğerleri almıyor. Neden?
  Çünkü rate limit genelde IP bazlı çalışır. Sizin IP adresiniz limiti aşmış ya da engel listesine girmiş olabilir. Mobil veriye geçerek veya farklı bir ağdan bağlanarak bunu hızlıca test edebilirsiniz.
• WordPress’te 429 hatasını hangi eklenti çözer?
  Tek başına hatayı “çözen” bir eklenti yoktur; çünkü 429 bir sonuçtur. Ancak Wordfence ve Limit Login Attempts gibi güvenlik eklentileri, hatayı tetikleyen kaba kuvvet denemelerini engelleyerek asıl sebebi ortadan kaldırır.
• 429 hatası Google sıralamamı düşürür mü?
  Kısa süreli hatalar sıralamanızı etkilemez. Ancak günlerce süren 429 yanıtları Googlebot’un taramayı bırakmasına ve sayfaların dizinden düşmesine yol açabilir. Bu yüzden uzun süren vakaları öncelikli olarak çözmelisiniz.
• Hosting paketimi yükseltmek 429 hatasını çözer mi?
  Hata kaynak yetersizliğinden geliyorsa evet, kalıcı çözüm olur. Ama sebep hatalı bir eklenti ya da saldırıysa yükseltme yalnızca zaman kazandırır. O yüzden önce logdan kaynağı doğrulamak gerekir.

429 Too Many Requests, ilk bakışta korkutucu görünse de aslında sunucunuzun kendini savunma refleksidir. Ziyaretçiyseniz çoğu zaman biraz sabır yeterlidir. Site sahibiyseniz izlemeniz gereken yol nettir: önce logdan kaynağı bulun, sonra doğru katmanda müdahale edin. Giriş sayfasını sıkılaştırmak, önbellek kurmak ve botları yönetmek vakaların büyük kısmını çözer. Geriye kalan durumlarda ise mesele ayar değil, kaynaktır; o zaman da paketinizi büyümenize uygun hale getirmek en sağlıklı adım olur.