HTTP 429 Too Many Requests Hatası Nedir? Nedenleri ve Kalıcı Çözüm Yöntemleri

Bir web sitesi normal çalışırken aniden “429 Too Many Requests” hatası göstermeye başlayabilir. Sayfa yenilendiğinde sorun bazen kendiliğinden kaybolur, bazen de birkaç dakika boyunca devam eder. Özellikle API kullanan uygulamalarda bu hata, arka planda çalışan işlemleri durdurabilir veya kullanıcıların belirli özelliklere erişmesini engelleyebilir.

İlk bakışta sunucu arızası gibi görünse de HTTP 429 çoğu zaman farklı bir durumu anlatır: Sunucu veya aradaki bir güvenlik katmanı, belirli bir istemciden gelen isteklerin sıklığını sınırlandırmıştır.

Bu mekanizma web uygulamalarını aşırı yükten, otomatik isteklerden ve kötüye kullanımdan korumak için kullanılır. Ancak yanlış yapılandırılmış bir sınırlandırma kuralı, normal ziyaretçileri ve meşru API istemcilerini de etkileyebilir.

Sorunu çözmek için yalnızca beklemek veya sayfayı yeniden yüklemek yeterli değildir. Hatanın hangi sistem tarafından üretildiğini, hangi sınırın aşıldığını ve isteklerin neden beklenenden fazla olduğunu belirlemek gerekir.

HTTP 429 Too Many Requests Nedir?

HTTP 429 Too Many Requests, bir istemcinin belirli bir zaman aralığında çok fazla istek gönderdiğini belirten HTTP durum kodudur.

MDN’in HTTP 429 açıklamasına göre bu durum, istemcinin istek hızını azaltması gerektiğini ifade eder.

Örneğin bir API, kullanıcı başına dakikada 100 isteğe izin veriyor olabilir. Aynı kullanıcı bu süre içinde 150 istek gönderdiğinde sistem sonraki isteklerden bazılarını 429 yanıtıyla reddedebilir.

Ancak HTTP standardı bütün servisler için ortak bir istek sınırı belirlemez. Bu değer uygulamanın, API sağlayıcısının veya güvenlik sisteminin politikasına göre değişir.

Bir sınırlandırma kuralı şu özelliklerden birine veya birkaçına dayanabilir:

• İstemcinin IP adresi
• Kullanıcı hesabı veya API anahtarı
• Belirli bir URL veya API endpoint’i
• İsteklerin gerçekleştiği zaman aralığı
• Uygulamanın belirlediği kaynak tüketimi veya kullanım kotası

Bu nedenle aynı web sitesinde bir kullanıcı sorunsuz işlem yaparken başka bir kullanıcı 429 hatasıyla karşılaşabilir.

HTTP 429, tek başına sunucunun çöktüğü anlamına gelmez. Çoğu durumda isteklerin kabul edilmesini düzenleyen bir kontrol mekanizması devreye girmiştir.

Rate Limiting Nasıl Çalışır?

Rate limiting, belirli bir kaynağa gönderilebilecek isteklerin sıklığını veya miktarını sınırlayan bir mekanizmadır.

Örneğin giriş sayfasına saniyede yüzlerce istek gönderen otomatik bir sistem, hem sunucu kaynaklarını tüketebilir hem de parola denemeleri gibi güvenlik riskleri oluşturabilir.

Rate limiting sayesinde bu tür davranışlar belirlenen kurallar doğrultusunda sınırlandırılabilir.

Fakat bütün rate limiting sistemleri aynı algoritmayı kullanmaz.

Fixed Window

Fixed Window yaklaşımında istekler sabit zaman aralıkları içinde sayılır.

Örneğin her dakika için 100 istek sınırı belirlenebilir. Yeni zaman aralığı başladığında sayaç sıfırlanır.

Uygulaması basittir ancak zaman pencerelerinin sınırında ani istek yoğunlukları oluşabilir.

Sliding Window

Sliding Window yaklaşımında istekler kayan bir zaman aralığı üzerinden değerlendirilir.

Bu yöntem, sabit zaman pencerelerinin sınırlarında oluşabilecek ani yoğunlukları daha dengeli yönetmeye yardımcı olabilir.

Ancak kullanılan veri yapısına göre hesaplama ve depolama maliyeti değişebilir.

Token Bucket

Token Bucket modelinde belirli hızda yenilenen token’lar kullanılır. Her istek belirli miktarda token tüketir.

Yeterli token bulunduğunda kısa süreli trafik artışlarına izin verilebilir. Token’lar tükendiğinde ise yeni istekler bekletilebilir veya reddedilebilir.

Bu yöntem, sürekli istek hızını kontrol ederken belirli miktarda ani trafiğe tolerans tanımak için kullanılabilir.

Hangi algoritmanın tercih edileceği uygulamanın trafik davranışına ve korunmak istenen kaynağa bağlıdır.

HTTP 429 Hatasının Yaygın Nedenleri

429 hatası tek bir yazılım probleminden kaynaklanmaz. İstek sınırı farklı katmanlarda uygulanabilir.

API isteklerinin fazla olması

En sık karşılaşılan nedenlerden biri, uygulamanın API sağlayıcısının belirlediği kullanım sınırını aşmasıdır.

Örneğin bir raporlama uygulaması her sayfa açılışında aynı API’ye çok sayıda istek gönderiyorsa kısa sürede kullanım kotasına ulaşabilir.

Bu durum özellikle gereksiz polling, hatalı döngüler ve paralel istek sayısının kontrol edilmediği uygulamalarda görülür.

Güvenlik duvarı ve CDN kuralları

CDN veya WAF sistemleri, belirli IP adreslerinden gelen istekleri sınırlandırabilir.

Bu kurallar çoğu zaman bot trafiğini ve kötüye kullanım girişimlerini azaltmak için kullanılır.

Ancak aynı IP adresini paylaşan çok sayıda kullanıcının bulunduğu ağlarda, yalnızca IP tabanlı sınırlandırmalar istenmeyen sonuçlar doğurabilir.

WordPress eklentileri

WordPress sitelerinde bazı güvenlik, giriş koruması veya trafik kontrolü eklentileri istek sınırlandırması uygulayabilir.

Ayrıca bir eklentinin harici API’ye gereğinden fazla istek göndermesi, o API’den 429 yanıtı alınmasına neden olabilir.

Burada iki farklı senaryo vardır: WordPress sitesinin ziyaretçiye 429 döndürmesi ve WordPress’in başka bir servisten 429 alması.

Sorun giderme yöntemi bu ayrımdan etkilenir.

Hatalı istemci kodu

Bir JavaScript uygulamasında aynı isteğin tekrar tekrar gönderilmesi, beklenenden fazla trafik oluşturabilir.

Örneğin her render işleminde yeniden çalışan bir istek fonksiyonu, yanlış yapılandırılmış zamanlayıcı veya kontrolsüz retry mekanizması bu soruna yol açabilir.

Özellikle 429 yanıtını aldıktan sonra hiçbir bekleme olmadan aynı isteği yeniden gönderen uygulamalar, sorunu daha da büyütebilir.

HTTP 429 Hatası Nasıl Teşhis Edilir?

429 hatasını çözmenin ilk adımı, yanıtın hangi sistemden geldiğini belirlemektir.

Tarayıcıda görülen hata sayfası her zaman yeterli bilgi sunmaz. Bu nedenle HTTP yanıt başlıklarının incelenmesi gerekir.

Tarayıcı geliştirici araçlarıyla kontrol

Chrome, Firefox veya Edge gibi modern tarayıcılarda geliştirici araçları açılarak Network sekmesine geçilebilir.

Hata oluşturan istek seçildiğinde yanıt durum kodu ve başlıklar görüntülenebilir.

Burada özellikle 429, Retry-After ve varsa servise özgü rate limit başlıkları incelenmelidir.

Bazı servisler kalan istek hakkını veya sınırın ne zaman sıfırlanacağını gösteren ek başlıklar döndürebilir.

Ancak bu başlıkların her serviste bulunması zorunlu değildir. Adları ve anlamları sağlayıcıya göre değişebilir.

curl ile HTTP yanıtını incelemek

Komut satırında bir URL’nin yanıt başlıklarını incelemek için:

curl -I https://example.com/

curl -I https://example.com/

Bu komut HEAD isteği gönderir. Bazı uygulamalar HEAD ve GET isteklerini farklı değerlendirebildiğinden sonuç her zaman tarayıcıdaki davranışla aynı olmayabilir.

GET isteğiyle yanıt başlıklarını görüntülemek için:

curl -sS -D - -o /dev/null https://example.com/

curl -sS -D - -o /dev/null https://example.com/

Bu komut yanıt başlıklarını terminale yazar ve yanıt gövdesini kaydetmez.

example.com yerine yalnızca inceleme yetkisi bulunan hedef adres kullanılmalıdır.

Test sırasında aynı URL’ye kısa sürede yüzlerce istek göndermek doğru bir yöntem değildir. Böyle bir davranış yeni sınırlandırmaları tetikleyebilir.

Log kayıtlarını karşılaştırmak

Sunucuya erişim varsa web sunucusu, uygulama ve güvenlik katmanlarının logları incelenebilir.

Önemli olan yalnızca 429 kodunun görülmesi değil, hangi kuralın veya bileşenin bu yanıtı oluşturduğunun belirlenmesidir.

Örneğin CDN katmanında engellenen bir istek, kaynak web sunucusuna hiç ulaşmamış olabilir.

Bu durumda yalnızca Nginx veya Apache erişim loglarını incelemek sorunun kaynağını ortaya çıkarmayabilir.

Retry-After Başlığı Nedir?

HTTP 429 yanıtlarında karşılaşılabilecek en önemli başlıklardan biri Retry-After değeridir.

Bu başlık, istemcinin yeni bir istekte bulunmadan önce ne kadar beklemesi gerektiğini belirtir.

MDN Retry-After dokümantasyonunda açıklandığı üzere değer saniye cinsinden süre veya HTTP tarih biçiminde olabilir.

Örneğin:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Bu yanıt, istemcinin yeniden denemeden önce 60 saniye beklemesi gerektiğini bildirir.

Tarih biçimindeki bir örnek ise şöyledir:

Retry-After: Fri, 06 Nov 2026 12:00:00 GMT

Retry-After: Fri, 06 Nov 2026 12:00:00 GMT

Bu örnekte bekleme süresi sabit bir saniye sayısı yerine belirli bir UTC tarih ve saatiyle ifade edilir.

Ancak her 429 yanıtında Retry-After bulunması zorunlu değildir.

Başlık yoksa istemcinin sınırsız sayıda ve hemen yeniden deneme yapması doğru değildir. Uygun bir bekleme ve tekrar deneme politikası uygulanmalıdır.

Exponential Backoff ile 429 Hatası Nasıl Yönetilir?

API istemcilerinde 429 hatasının kalıcı sorunlara dönüşmesini önlemek için tekrar deneme stratejisi önemlidir.

En yaygın yaklaşımlardan biri exponential backoff yöntemidir.

Bu yöntemde başarısız denemeler arasında bekleme süresi kademeli olarak artırılır.

Örneğin bekleme süreleri şu şekilde ilerleyebilir:

Bu değerler yalnızca örnektir. Gerçek bekleme süresi API sağlayıcısının sınırlarına, Retry-After değerine ve uygulamanın ihtiyaçlarına göre belirlenmelidir.

Jitter neden önemli?

Çok sayıda istemci aynı anda 429 yanıtı alırsa hepsinin aynı süre bekleyip yeniden istek göndermesi yeni bir trafik dalgası oluşturabilir.

Jitter, bekleme süresine kontrollü rastgelelik ekleyerek istemcilerin yeniden denemelerini zamana yayar.

Bu yaklaşım özellikle dağıtık sistemlerde ve yüksek eşzamanlılıkla çalışan uygulamalarda yararlıdır.

Ancak rastgele bekleme tek başına yeterli değildir. Maksimum deneme sayısı, toplam bekleme süresi ve isteğin güvenle tekrar edilip edilemeyeceği de değerlendirilmelidir.

Her API isteği otomatik tekrar edilmeli mi?

Hayır.

GET gibi genellikle güvenli kabul edilen okuma istekleriyle, veri oluşturan veya ödeme başlatan POST istekleri aynı şekilde ele alınmamalıdır.

Bir POST isteğinin tekrar gönderilmesi bazı durumlarda aynı işlemin birden fazla kez gerçekleştirilmesine neden olabilir.

Bu nedenle özellikle ödeme, sipariş ve veri oluşturma işlemlerinde idempotency key veya benzeri tekrar güvenliği mekanizmaları kullanılmalıdır.

429 yanıtı alınması, bütün istek türlerinin otomatik ve sınırsız tekrar edilebileceği anlamına gelmez.

JavaScript Fetch ile 429 Hatasını Yönetmek

JavaScript Fetch API kullanan uygulamalarda 429 yanıtı özel olarak ele alınabilir.

Önemli bir ayrıntı, Fetch API’nin HTTP 429 gibi hata durum kodlarında normal şartlarda Promise’i otomatik olarak reddetmemesidir.

Yanıtın status veya ok alanı kontrol edilmelidir.

Basit bir örnek:

async function fetchWithRetry(url) {
  const maxAttempts = 3;

  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const response = await fetch(url);

    if (response.status !== 429) {
      return response;
    }

    if (attempt === maxAttempts - 1) {
      return response;
    }

    const delay = 1000 * (2 ** attempt);

    await new Promise(resolve =>
      setTimeout(resolve, delay)
    );
  }
}

async function fetchWithRetry(url) {
  const maxAttempts = 3;

  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const response = await fetch(url);

    if (response.status !== 429) {
      return response;
    }

    if (attempt === maxAttempts - 1) {
      return response;
    }

    const delay = 1000 * (2 ** attempt);

    await new Promise(resolve =>
      setTimeout(resolve, delay)
    );
  }
}

Bu örnek yalnızca GET davranışıyla kullanılan basit bir istemci mantığını gösterir.

Kod, üç denemeyle sınırlıdır ve 429 yanıtı alındığında bekleme süresini artırır.

Ancak üretim ortamı için eksiksiz bir retry sistemi değildir.

Örneğin Retry-After başlığını yorumlamaz, rastgele jitter eklemez, ağ hatalarını ayrı ele almaz ve istek iptali için AbortSignal kullanmaz.

Ayrıca uygulamanın kendi toplam zaman aşımı politikasıyla birlikte değerlendirilmelidir.

Bu nedenle örnek doğrudan kritik üretim uygulamalarına kopyalanmak yerine, ilgili API’nin kullanım politikalarına göre geliştirilmelidir.

WordPress’te 429 Too Many Requests Hatası Nasıl Çözülür?

WordPress sitelerinde 429 hatasıyla karşılaşıldığında ilk olarak hatanın hangi işlem sırasında oluştuğu belirlenmelidir.

Hata yalnızca yönetim paneline girişte mi görülüyor? REST API isteklerinde mi ortaya çıkıyor? Yoksa bütün ziyaretçiler aynı sorunu mu yaşıyor?

Bu sorular olası nedenleri daraltır.

Güvenlik eklentilerini kontrol etmek

Bazı WordPress güvenlik eklentileri başarısız giriş denemelerini veya belirli URL’lere gelen yoğun istekleri sınırlandırabilir.

Bu durumda eklentinin güvenlik olayları ve rate limiting ayarları incelenmelidir.

Sorun bir güncellemeden sonra başladıysa son yapılandırma değişiklikleri karşılaştırılabilir.

Ancak güvenlik mekanizmasını tamamen kapatmak yerine yanlış pozitif üreten kuralın belirlenmesi daha doğru yaklaşımdır.

REST API isteklerini incelemek

WordPress REST API kullanan temalar veya eklentiler beklenenden fazla istek gönderebilir.

Tarayıcı Network panelinde aynı endpoint’e tekrar eden çağrılar bulunuyorsa bunların hangi JavaScript bileşeninden kaynaklandığı araştırılmalıdır.

Özellikle başarısız bir isteğin kontrolsüz biçimde yeniden gönderilmesi, rate limit sorununu sürekli hale getirebilir.

CDN ve WAF yapılandırmasını kontrol etmek

WordPress sitesi CDN veya WAF arkasında çalışıyorsa hata kaynak sunucudan önceki katmanda oluşabilir.

Bu durumda ilgili güvenlik olayları, kural kimlikleri ve istek kayıtları incelenmelidir.

Meşru bir WordPress endpoint’i yanlışlıkla sınırlandırılıyorsa yalnızca o davranışı kapsayan dar bir kural düzeltmesi yapılabilir.

Bütün güvenlik kurallarını devre dışı bırakmak veya geniş IP aralıklarını koşulsuz olarak muaf tutmak gereksiz risk oluşturur.

Cloudflare Kullanırken 429 Hatası Neden Görülür?

Cloudflare kullanılan bir sitede 429 yanıtı birden fazla kaynaktan gelebilir.

Yanıt Cloudflare’ın uyguladığı bir rate limiting kuralından kaynaklanabileceği gibi, kaynak sunucu tarafından oluşturulup Cloudflare üzerinden iletilmiş de olabilir.

Bu nedenle yalnızca sayfada Cloudflare ile ilişkili bir başlık veya görsel bulunması, hatanın kesin olarak Cloudflare tarafından üretildiğini kanıtlamaz.

İnceleme sırasında ilgili isteğin zaman damgası, URL’si, kaynak IP bilgisi ve varsa güvenlik olayı kayıtları karşılaştırılmalıdır.

Rate limiting kuralının eşik değeri, değerlendirme süresi, eşleşme koşulları ve uygulanacak aksiyon birlikte incelenmelidir.

Örneğin giriş sayfasına uygulanan sıkı bir kural, genel içerik sayfalarına uygulanan kuralla aynı şekilde değerlendirilmemelidir.

Ayrıca CDN üzerinden gelen trafiğin kaynak sunucuda doğru istemci IP’siyle ilişkilendirilmesi önemlidir. Yanlış proxy IP yapılandırmaları, birbirinden bağımsız kullanıcıların aynı istemci gibi değerlendirilmesine neden olabilir.

HTTP 429 ile HTTP 503 Arasındaki Fark

HTTP 429 ve HTTP 503 hataları bazen benzer kullanıcı deneyimleri oluşturabilir. Ancak anlamları farklıdır.

HTTP 503 Service Unavailable, sunucunun geçici olarak isteği işleyemediğini belirtir.

Örneğin bakım çalışması sırasında 503 yanıtı verilmesi uygun olabilir.

Buna karşılık belirli bir istemci çok fazla istek gönderdiği için sınırlandırılıyorsa 429 daha anlamlıdır.

Her iki durumda da Retry-After başlığı kullanılabilir. Ancak hata kodunun farklı olması, sorunun teşhisinde ve çözümünde önemli bir ayrımdır.

HTTP 429 Hatası Kalıcı Olarak Nasıl Önlenir?

429 hatasını tamamen ortadan kaldırmak her zaman doğru hedef değildir. Çünkü rate limiting çoğu sistemde gerekli bir güvenlik ve kaynak yönetimi mekanizmasıdır.

Asıl amaç, meşru trafiği gereksiz yere engellemeden aşırı istekleri kontrol etmektir.

İstekleri önbelleğe almak

Aynı veriye sık sık erişen uygulamalarda uygun önbellekleme stratejileri API isteklerini azaltabilir.

Örneğin nadiren değişen bir yapılandırma verisinin her sayfa açılışında yeniden çekilmesi yerine belirli süre önbellekte tutulması değerlendirilebilir.

Ancak kişisel veya hassas verilerin yanlışlıkla ortak önbellekte paylaşılmaması gerekir.

Polling sıklığını azaltmak

Bir uygulamanın her saniye aynı endpoint’e istek göndermesi her zaman gerekli değildir.

Verinin değişme sıklığına göre polling aralığı düzenlenebilir.

Uygun senaryolarda WebSocket veya Server-Sent Events gibi olay tabanlı iletişim yöntemleri de değerlendirilebilir.

Paralel istek sayısını sınırlandırmak

Çok sayıda API isteğini aynı anda göndermek kısa süreli trafik patlamaları oluşturabilir.

İstek kuyruğu ve concurrency limit kullanmak, bu yoğunluğu daha kontrollü hale getirebilir.

Bu yaklaşım özellikle toplu veri işleme ve arka plan görevlerinde önemlidir.

Kullanıcı ve IP sınırlarını dengeli tasarlamak

Yalnızca IP adresine dayalı sınırlandırmalar bazı ağlarda sorun oluşturabilir.

Kurumsal ağlar, mobil operatörler ve NAT kullanılan ortamlarda çok sayıda kullanıcı aynı genel IP adresini paylaşabilir.

Bu nedenle mümkün olduğunda kullanıcı kimliği, API anahtarı ve endpoint türü gibi ek bağlamlar dikkate alınmalıdır.

Rate limit olaylarını izlemek

429 yanıtlarının hangi URL’lerde, hangi saatlerde ve hangi istemci gruplarında yoğunlaştığı izlenmelidir.

Özellikle yeni bir sürüm dağıtımından sonra 429 sayısında ani artış görülmesi, uygulamanın istek davranışında değişiklik olduğuna işaret edebilir.

Ancak tek başına 429 sayısının artması sistemin yanlış çalıştığını kanıtlamaz. Meşru trafik ile kötüye kullanım girişimleri ayrı değerlendirilmelidir.

HTTP 429 Hatasında Yapılmaması Gerekenler

Hata giderme sürecinde bazı kısa yollar sorunu çözmek yerine büyütebilir.

Örneğin 429 yanıtı alındığında isteği anında tekrar göndermek, rate limit süresinin uzamasına veya ek güvenlik önlemlerinin devreye girmesine neden olabilir.

Benzer şekilde bütün WAF kurallarını kapatmak, hatayı geçici olarak ortadan kaldırsa bile uygulamayı gereksiz saldırı trafiğine açık hale getirebilir.

API anahtarını sürekli değiştirmek veya farklı IP adresleri üzerinden sınırlandırmayı aşmaya çalışmak da sürdürülebilir bir çözüm değildir. Üstelik servis sağlayıcısının kullanım koşullarını ihlal edebilir.

Doğru yöntem, sınırlandırmanın neden uygulandığını anlamak ve istek davranışını ya da ilgili kuralı kontrollü biçimde düzeltmektir.

HTTP 429 Hatasını Çözmek İçin Pratik Kontrol Sırası

Sorunla karşılaşıldığında aşağıdaki sıra, gereksiz değişiklikleri azaltmaya yardımcı olur:

1. Hatanın hangi URL veya API endpoint’inde oluştuğunu belirleyin.
2. Yanıt başlıklarında Retry-After ve varsa rate limit bilgilerini inceleyin.
3. Hatanın uygulama, kaynak sunucu, CDN veya WAF tarafından üretildiğini araştırın.
4. Aynı isteğin gereksiz yere tekrar gönderilip gönderilmediğini kontrol edin.
5. API sağlayıcısının kullanım sınırlarını ve istemcinin retry davranışını karşılaştırın.
6. WordPress veya başka bir CMS kullanılıyorsa güvenlik eklentileri ve arka plan isteklerini inceleyin.
7. Yapılandırma değişikliklerini önce kontrollü ortamda test edin ve geri alma planı hazırlayın.
8. Düzeltmeden sonra 429 yanıtlarının sıklığını ve normal kullanıcı trafiğini izleyin.

Bu yaklaşım, yalnızca hatayı geçici olarak ortadan kaldırmak yerine aynı sorunun tekrar oluşmasını önlemeye odaklanır.

Sonuç: 429 Hatası Çoğu Zaman Bir Uyarıdır

HTTP 429 Too Many Requests, web uygulamalarında istek hızının belirlenen sınırları aştığını gösteren önemli bir sinyaldir.

Bu hata bazen gerçekten aşırı trafik oluşturan bir istemciden, bazen yanlış yapılandırılmış bir güvenlik kuralından, bazen de gereksiz tekrar istekleri gönderen uygulama kodundan kaynaklanabilir.

Kalıcı çözüm için yanıt başlıklarının, logların ve uygulamanın istek davranışının birlikte değerlendirilmesi gerekir.

Özellikle Retry-After desteği, kontrollü exponential backoff, uygun önbellekleme ve doğru rate limiting kuralları, hem API istemcilerinin hem de web servislerinin daha öngörülebilir çalışmasına yardımcı olur.

429 hatasının kendisi her zaman ortadan kaldırılması gereken bir kusur değildir. Doğru yapılandırılmış bir sistemde bu yanıt, kaynakları korurken istemcilere daha kontrollü davranmaları gerektiğini bildiren sağlıklı bir mekanizmanın parçası olabilir.