HTTP Error 429 (Too Many Requests) Nedir? Anlamı ve Çözümü

HTTP 429 Hatası Nedir?

HTTP 429 Too Many Requests, sunucunun hızınızı sınırladığı anlamına gelir: siz, IP adresiniz veya uygulamanız belirli bir süre içinde izin verilenden fazla istek gönderdi. Bu geçicidir. Sunucu çalışıyor; yalnızca şimdilik size yanıt vermemeyi seçiyor.

Kod, tam da bu durum için RFC 6585 ile (2012) eklendi ve yanıt, ne kadar beklemeniz gerektiğini söyleyen bir Retry-After başlığı taşıyabilir. Yoğun sitelerde gezinirken, API çağrılarında, toplu indirmelerde veya IP adresini çok kişinin paylaştığı bir VPN'de karşınıza çıkar.

Komşu kodlardan farklıdır: 401 oturum açmadığınız, 403 erişim izniniz olmadığı anlamına gelir; 429 ise iznin olduğu, ama fazla hızlı gittiğiniz anlamına gelir.

429 Hatası Nasıl Görünür?

Mesaj, yanıtı kimin verdiğine bağlıdır. İnsanların en çok aradıkları şunlar:

Sunucuda bir şeyin bozulduğu anlamına gelen 500 hatasının aksine, 429 HTTP'nin diliyle bir istemci hatasıdır: sunucu kendini çok fazla istekten koruyor.

Hız Sınırlama (Rate Limiting) Nasıl Çalışır?

Hız sınırlama, sunucuların bir istemcinin belirli bir zaman penceresinde kaç istek gönderebileceğini denetlemek için kullandığı bir tekniktir. Sınır aşıldığında sunucu genellikle 429 döndürür (bazıları bunun yerine 403 veya 503 verir).

Yaygın olarak kullanılan birkaç hız sınırlama algoritması vardır:

• Sabit Pencere (Fixed Window) — Sunucu, her zaman penceresi başına N isteğe izin verir (örn. dakikada 100 istek). Sayaç sabit aralıklarla sıfırlanır.
• Kayan Pencere (Sliding Window) — Sabit pencereye benzer, ancak zaman penceresi her istekle birlikte kayar. Bu yöntem pencere sınırlarındaki ani yoğunlukları önler.
• Token Kovası (Token Bucket) — Sunucu, sabit bir hızda yenilenen token'lar atar. Her istek bir token tüketir. Token'lar bittiğinde istekler reddedilir.
• Sızdıran Kova (Leaky Bucket) — İstekler, ani yoğunluk büyüklüğünden bağımsız olarak sabit bir hızda işlenir. Fazla istekler kuyruğa alınır veya düşürülür.

Birçok API sınırlarını yanıt başlıklarında duyurur. GitHub'da bunlar örneğin x-ratelimit-limit (saatte izin verilen istek), x-ratelimit-remaining, x-ratelimit-used ve x-ratelimit-reset (pencerenin ne zaman sıfırlanacağı, Unix saniyesi olarak) başlıklarıdır. Bir IETF taslağı aynı iş için standart RateLimit ve RateLimit-Policy başlıklarını önermektedir.

Bir hizmetin hangi algoritmayı ve hangi pencereyi kullandığını bilmek, istemcinizi sınırın içinde kalacak şekilde tasarlamanıza yardımcı olur.

HTTP 429 Hatasının Yaygın Nedenleri

Neden, hatayı kimin gördüğüne bağlıdır:

429 Hatası Nasıl Düzeltilir (Ziyaretçiler İçin)

Bir web sitesini gezerken 429 hatası görüyorsanız, deneyebileceğiniz çözümler aşağıda sıralanmıştır. En basit çözümden başlayarak ilerleyin.

1. Bekleyin ve Tekrar Deneyin

En basit çözüm beklemektir. 429 geçicidir: sunucu sizi engellemiyor, yalnızca yavaşlamanızı istiyor.

Süre, sitenin sınırına bağlıdır: bazıları bir dakika içinde sıfırlanır, bazıları saatlik veya günlüktür. Sayfa ya da API bir Retry-After başlığı gönderiyorsa, kesin bekleme süresi odur. Ardından sayfayı bir kez yükleyin.

Sürekli yenilemeyin: her yenileme bir istek daha demektir ve aynı sınıra sayılır.

2. Sitenin Çerezlerini Temizleyin

Bunun etkisi nadirdir, ancak bazı siteler istekleri oturum çerezi başına sayar. Diğer her yerden çıkış yapmadan yeni bir oturum almak için yalnızca o sitenin çerezlerini temizleyin:

• Chrome / Edge: chrome://settings/content/all adresini açın (Edge: edge://settings/content/all), siteyi arayın ve verilerini silin
• Firefox: Adres çubuğundaki asma kilide tıklayın → Çerezleri ve site verilerini temizle…
• Safari: Safari → Ayarlar → Gizlilik → Web Sitesi Verilerini Yönet → siteyi bulun → Kaldır

Temizleme işleminden sonra siteyi tekrar ziyaret etmeden önce tarayıcıyı kapatıp yeniden açın.

3. VPN veya Proxy Bağlantısını Kesin

VPN veya proxy kullanıyorsanız IP adresinizi yüzlerce başka kullanıcıyla paylaşıyor olabilirsiniz. Bu kullanıcıların toplam istekleri sunucunun sınırını aştığında, o IP'deki herkes hız sınırına takılır.

VPN bağlantınızı kesip siteye normal internet bağlantınızla erişmeyi deneyin. 429 hatası ortadan kalkarsa sorun VPN'in IP'sindedir.

VPN'e ihtiyacınız varsa farklı bir sunucu konumuna geçin: o adresi daha az kişi paylaşıyor olabilir.

4. Tarayıcı Eklentilerini Devre Dışı Bırakın

Bazı eklentiler, ziyaret ettiğiniz sitelere arka planda istek gönderir: fiyat takip araçları, SEO araçları ve otomatik yenileme eklentileri toplamda bir hız sınırına ulaşabilir. (Reklam engelleyiciler genellikle tersini yapar ve istekleri azaltır.)

Test etmek için siteyi çoğu eklentinin kapalı olduğu bir gizli pencerede açın. Gizli pencere çerezsiz de başlar; yani 429 kaybolursa bir eklenti veya oturuma dayalı bir sınır söz konusudur.

Sorunlu eklentiyi bulmak için eklentileri tek tek devre dışı bırakın. Chrome'da chrome://extensions/ adresine gidip bunları ayrı ayrı kapatın.

5. IP Adresinizin Paylaşılıp Paylaşılmadığını Kontrol Edin

Pek çok kişi tek bir genel IP adresini paylaşabilir: bir ofis ya da okul ağı, bir mobil operatörün ağı (CGNAT) veya bir VPN sunucusu. Onların istekleri sizinkilerle aynı sınıra sayılır.

Böyle bir ağdaysanız siteyi kendi ev bağlantınızdan veya mobil veriyle yüklemek, sorunun paylaşılan adreste olup olmadığını gösterir. Sınır kendi adresinizdeyse, aşmak için ağ değiştirmek yerine sıfırlanmasını bekleyin. Mevcut genel IP'nizi IP Adresim Nedir ile kontrol edebilirsiniz.

429 Hatası Nasıl Düzeltilir (Geliştiriciler İçin)

Kodunuz 429 alıyorsa, API'nin izin verdiğinden daha hızlı istek gönderiyordur. Şu sırayla ilerleyin: Retry-After'ı okuyun, jitter'lı geri çekilmeyle yeniden deneyin, sonra gönderdiğiniz istek sayısını azaltın.

1. Üstel Geri Çekilme (Exponential Backoff) Uygulayın

Üstel geri çekilme standart yeniden deneme stratejisidir: 429'dan hemen sonra yeniden denemek yerine bekleme süresini her seferinde iki katına çıkarırsınız (1 saniye, 2, 4, 8…) ve birçok istemcinin aynı anda yeniden denememesi için jitter, yani rastgele bir ek gecikme eklersiniz.

Bu sürüm, sunucu geçerli bir Retry-After gönderirse onu (iki biçiminden biriyle) kullanır, aksi halde jitter'lı geri çekilmeye döner ve birkaç denemeden sonra vazgeçer. (Başka bir sitenin API'sini çağıran bir tarayıcıda, Retry-After yalnızca API onu Access-Control-Expose-Headers ile açığa çıkarırsa okunabilir.)

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Retry-After Başlığına Uyun

Bir sunucu 429 ile birlikte Retry-After gönderdiğinde, ne kadar bekleyeceğinizi tam olarak söyler. RFC 9110 iki biçime izin verir: saniye cinsinden bir sayı veya bir HTTP tarihi.

Retry-After: 60 60 saniye bekleyin demektir. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT o ana kadar bekleyin demektir. Kendi geri çekilme mantığınızdan önce bunu kontrol edin: sunucu bunu kodunuzdan daha iyi bilir.

Python'da iki biçimi de ele alın ve sonsuza dek özyineleme yapmak yerine birkaç denemeden sonra durun:

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

3. API Yanıtlarını Önbelleğe Alın

Uygulamanız aynı API çağrısını birden fazla kez yapıyorsa, her seferinde API'ye istek göndermek yerine yanıtı önbelleğe alın. Bu yöntem istek sayınızı önemli ölçüde azaltır.

Sık erişilen veriler için bellek içi önbellek (Redis veya basit bir Map gibi) kullanın. Verinin ne sıklıkta değiştiğine göre makul bir TTL (yaşam süresi) belirleyin.

Örneğin, bir alan adının DNS kayıtlarını sorguluyorsanız, sonuçlar muhtemelen sonraki 5 dakika içinde değişmeyecektir — bunları önbelleğe alın.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) return cached.data;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. Yoklama Yerine Webhook Kullanın

Bir API'yi değişiklik var mı diye sürekli yokluyorsanız (örneğin her 10 saniyede sipariş durumunu kontrol etmek), hizmet destekliyorsa webhook'lara geçin.

Webhook'larda sunucu, bir şey değiştiğinde uygulamanıza güncellemeyi kendisi gönderir; sürekli yoklamaya gerek kalmaz. Bu, API çağrılarınızı saatte binlerceden yalnızca bir avuca düşürebilir.

Çoğu modern API (Stripe, GitHub, Twilio, Shopify) webhook destekler. Webhook yapılandırması için API belgelerine bakın.

5. Daha Yüksek Hız Sınırları Talep Edin

Gerçekten daha fazla API çağrısına ihtiyacınız varsa hizmet sağlayıcıyla iletişime geçin. Birçok API, ücretli planlar veya doğrulanmış uygulamalar için daha yüksek hız sınırları sunar.

Daha yüksek sınır isterken kullanım senaryonuzu açıklayın ve beklediğiniz istek hacmine dair tahminleri paylaşın. Aralarında Google'ınkilerin de bulunduğu birçok API'nin yüksek sınırlar için bir formu veya ücretli bir planı vardır.

Bazı API'ler ayrıca tek bir istekte birden fazla kaynağı almanızı sağlayan toplu (bulk) uç noktalar sunar ve toplam çağrı sayısını azaltır.

429 Hatası Nasıl Düzeltilir (Site Sahipleri İçin)

Ziyaretçileriniz veya API kullanıcılarınız 429 hatası alıyorsa sorun sunucu yapılandırmanızdadır. Sorunu teşhis etmenin ve düzeltmenin yolları aşağıdadır.

1. Hız Sınırlarınızı Ayarlayın

Gerçek kullanıcılar 429 alıyorsa önce hangi katmanın ilk yanıt verdiğini bulun: CDN veya WAF'ınız, web sunucunuz ya da uygulamanız. Sonra o katmanın sınırlarını ayarlayın.

nginx'te işi limit_req yapar. Varsayılan olarak 503 döndürdüğünü unutmayın: istemciler sunucunun çöktüğünü sanmak yerine yavaşlamaları gerektiğini bilsin diye limit_req_status 429; ekleyin:

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

burst parametresi kısa yoğunlukların 429 almadan geçmesini sağlar; onsuz, çok sayıda istek yapan normal bir sayfa yüklemesi bile sınıra takılabilir.

Apache'de yerleşik bir istek hızı sınırlayıcı yoktur: mod_ratelimit bant genişliğini sınırlar, istek sayısını değil, üçüncü taraf mod_evasive ise 403 döndürür. 429 için ters proxy, WAF veya uygulamanızı kullanın. Node.js'te express-rate-limit varsayılan olarak 429 döndürür.

2. Güvenilir IP'leri Beyaz Listeye Alın

Belirli istemciler (izleme hizmetleri, ödeme işlemcileri, kendi mikro servisleriniz) hız sınırına takılıyorsa IP adreslerini beyaz listeye alın.

nginx'te geo ve map, güvenilir adreslere boş bir anahtar verir ve nginx boş anahtarlı istekleri saymaz. Bu, önceki örnekteki limit_req_zone satırının yerine geçer:

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

Arama motoru tarayıcılarına yanlışlıkla hız sınırı uygulamayın: Google 429'u sunucu hatası sayar ve taramayı yavaşlatır (Google Search Central). Gerçek Googlebot ve Bingbot isteklerini, o adın ileri sorgusuyla doğrulanan bir PTR Sorgulama ile doğrulayın ya da tarayıcıların yayımlanmış IP aralıklarını muaf tutun.

3. WAF ve CDN Ayarlarını Kontrol Edin

Cloudflare, AWS WAF, Sucuri veya başka bir güvenlik hizmeti kullanıyorsanız, istek sunucunuza ulaşmadan önce onların hız sınırlama kuralları yanıt verebilir.

Cloudflare, bir hız sınırlama kuralı tetiklendiğinde ziyaretçilere "Error 1015: You are being rate limited" gösterir. Kuralı panelin güvenlik kurallarında bulun, olaylarına bakın ve eşiği yükseltin ya da kapsamını daraltın.

AWS WAF'ın hız tabanlı kuralları, istekleri IP (veya başka bir anahtar) başına 1, 2, 5 veya 10 dakikalık bir pencerede sayar; asgari sınır 10'dur. Engellenen isteğe varsayılan olarak 403 verilir; istemciler yavaşlamaları gerektiğini bilsin diye özel bir 429 yanıtı tanımlayın.

Herhangi bir şeyi değiştirmeden önce gerçek ziyaretçileri botlardan ayırmak için CDN'in analizlerine bakın.

4. Sunucu Performansını Optimize Edin

Bazı hizmetler yük altındayken emniyet supabı olarak daha sıkı hız sınırı uygular. Sunucu performansını iyileştirmek, sınırları güvenle yükseltmenizi sağlar.

Temel optimizasyonlar: arka uç yükünü azaltmak için yanıt önbelleğini etkinleştirin, statik dosyalar için bir CDN kullanın, Redis veya Memcached ile veritabanı sorgu önbelleği ekleyin, veritabanı bağlantıları için bağlantı havuzu (connection pooling) kullanın ve trafik gerektiriyorsa yük dengeleme ile yatay ölçekleyin.

Önbellek başlıklarınızın doğru ayarlandığını doğrulamak için HTTP Başlık Kontrolü aracımızı kullanın.

429 ile Diğer HTTP Hataları Arasındaki Fark

429 hatasını diğer HTTP durum kodlarıyla karıştırmak kolaydır. Aralarındaki farklar şöyledir:

Temel ayrım: 429 kasıtlı ve geçicidir: sunucu şimdilik sizi geri çevirmeyi seçiyor. 5xx kodlarının çoğu sunucuda bir şeyin başarısız olduğunu gösterir; ancak 503 planlı bir bakım da olabilir, nginx'te ise bir hız sınırı.

429 Hataları Nasıl Önlenir?

Önlem almak, tedavi etmekten iyidir. 429 hatalarını en başından önlemek için en iyi uygulamalar şunlardır:

• API belgelerini okuyun — Kod yazmadan önce hız sınırlarını bilin. Çoğu servis sınırlarını açıkça yayınlar.
• Kullanımınızı izleyin — Sınıra ne kadar yakın olduğunuzu öğrenmek için X-RateLimit-Remaining başlıklarını takip edin.
• İstekleri toplu gönderin — Tekil çağrılar yapmak yerine mümkün olduğunda toplu (bulk) uç noktaları kullanın.
• İstekleri dağıtın — Ani yoğunluklar göndermek yerine API çağrılarını zaman içinde eşit olarak yayın.
• API anahtarları kullanın — Kimlik doğrulanmış istekler genellikle anonim olanlardan daha yüksek hız sınırları alır.
• Devre kesici (circuit breaker) uygulayın — Tekrarlanan 429 hataları alıyorsanız bir bekleme süresi boyunca istek göndermeyi tamamen durdurun.
• Hız sınırı simülatörleriyle test edin — Hata işlemenizin çalıştığından emin olmak için geliştirme ortamında 429 yanıtlarını simüle edin.
• 429 yanıtlarını kaydedin — İstek kalıplarınızı optimize etmek için hız sınırlamanın ne zaman ve nerede gerçekleştiğini izleyin.