429 Too Many Requests ve Rate Limit Hatası Nedir?

Bir oyun platformunda takas tekliflerine bakıyorsunuz, bir yapay zekâ sohbetine art arda soru yazıyorsunuz ya da vize randevusu için boş gün çıkar mı diye aynı sayfayı açıp duruyorsunuz. Sayfa birden değişiyor ve ekranda tek satır kalıyor: "429 Too Many Requests". Bazen mesaj Türkçedir ("Çok fazla istek gönderdin"), bazen bir uygulamanın içinde "Request failed with status code 429" diye çıkar, bazen de "rate limit exceeded" yazar. Hepsi aynı şeyi söyler: karşıdaki hizmet, sizden gelen istekleri saymış ve sayı sınırı geçmiştir.

Bu yazıda 429 kodunun ve rate limit (hız sınırı) kavramının ne olduğunu, sınırın neye göre sayıldığını, "ben hiçbir şey yapmadım" diyenlere neden çıktığını ve ne kadar beklemek gerektiğini anlatıyoruz. Yazının ilk yarısı hatayı ekranında gören kullanıcıya, ikinci yarısı API kullanan geliştiriciye ve veri toplayan ekiplere ayrıldı.

429 Too Many Requests ne demek?#

Tarayıcınız ya da bir uygulama bir sunucuya her bağlandığında, sunucu yanıtın başına üç haneli bir durum kodu koyar. 200 "tamam", 404 "böyle bir sayfa yok" demektir. 429 ise "isteğinizi anladım ama şu an işlemeyeceğim, çünkü kısa sürede çok fazla istek gönderdiniz" anlamına gelir. Kod RFC 6585'in 4. bölümünde tanımlanır. Aynı bölüm iki şeyi sunucuya bırakır: kullanıcının nasıl tanınacağını ve isteklerin nasıl sayılacağını. Yani 429'un arkasındaki kural her hizmette farklıdır; ortak olan yalnızca mesajdır.

Aynı hata, hizmetin arayüzüne göre farklı kılıklara girer:

Son satırın kendi yazısı var: ekrandaki her satırın anlamını, Ray ID kodunu ve site sahibinin yapabileceklerini Error 1015 Nedir? You Are Being Rate Limited Hatası Çözümü yazımızda anlattık.

Rate limit nedir, neden konur?#

Rate limit, bir hizmetin tek bir kullanıcıdan belirli bir sürede kabul ettiği istek sayısının üst sınırıdır. "Dakikada 60 istek", "saatte 5 giriş denemesi" ya da "günde 1.000 arama" gibi bir kuraldır. "Rate limit exceeded" bu sınırın aşıldığını, "rate limited" ise sınırlandırıldığınızı söyler. Türkçede hız sınırı ya da istek sınırı denir.

Hizmetler bu sınırı dört nedenle koyar:

• Kapasiteyi korumak. Sunucunun işleyebileceği istek sayısı sonludur. Tek bir kullanıcı ya da bozuk bir program bütün kapasiteyi tüketmemelidir.
• Hesap güvenliği. Giriş sayfalarındaki sınır bilerek düşük tutulur. Şifreyi tahmin etmeye çalışan biri binlerce deneme yapmak ister; "beş yanlış denemeden sonra bekle" kuralı bu saldırıyı anlamsız ölçüde yavaşlatır.
• Adil paylaşım. Ücretsiz ve ücretli planların kotaları farklıdır; sınır herkesin payını belirler.
• Maliyet. Her isteğin işlemci, bant genişliği ve bazen üçüncü taraf ücreti olarak bir karşılığı vardır.

Sınır neye göre sayılır?#

429 aldığınızda sorulacak ilk soru şudur: sayaç kimin adına tutuluyor? MDN'in 429 sayfası olası yöntemleri sıralar: sunucunun tamamı için, tek bir kaynak için, IP adresi başına, kullanıcı başına ya da uygulama başına. Hangi yöntemin kullanıldığı, neyin işe yarayıp neyin yaramayacağını belirler.

Hizmetlerin çoğu bu sayaçlardan birkaçını aynı anda tutar. GitHub iyi bir örnektir, çünkü kuralını açıkça yazar: REST API hız sınırı belgesine göre kimliksiz istekler saatte 60 ile sınırlıdır ve bu sayaç kullanıcıya değil, isteğin geldiği IP adresine bağlıdır. Kimlik doğrulaması yapan kullanıcının sınırı saatte 5.000 istektir ve hesaba bağlıdır.

Rate limit nasıl çalışır?#

Ayrıntılar hizmete göre değişse de akış aynıdır:

1. Hizmet bir kural yazar. Kural üç parçadır: kimin sayılacağı (IP, hesap, anahtar), süre ve eşik.
2. Gelen her istek bir sayaca yazılır. Sunucu isteği işlemeden önce hangi sayaca ait olduğuna bakar ve o sayacı bir artırır.
3. Eşik geçilince istek işlenmeden reddedilir. Sunucu sayfayı hazırlamak yerine kısa bir 429 yanıtı gönderir.
4. Sunucu isterse ne kadar beklemeniz gerektiğini söyler. Bunu Retry-After adlı yanıt başlığıyla yapar. Başlık zorunlu değildir, her site göndermez.
5. Süre ilerledikçe sayaç boşalır. Pencere kapanır ya da kovaya yeni jeton düşer, erişim kendiliğinden açılır.
6. Israr edenin cezası büyüyebilir. Bazı hizmetler 429'a rağmen aynı tempoyla devam eden istemciyi daha uzun süre, daha sert bir kodla engeller. GitHub belgesi bunu açıkça yazar: sınırlandırılmışken istek göndermeye devam etmek, entegrasyonunuzun yasaklanmasıyla sonuçlanabilir.

İkinci adım için bir not: bir sayfa açmak tek bir istek değildir. Tarayıcı görselleri, betikleri ve arka plan sorgularını ayrı ayrı ister; tek tıklamayla sunucuya onlarca istek gidebilir.

Hiçbir şey yapmadım, 429 neden bana çıktı?#

Türkçe arama önerilerinde bu hatanın yanında en çok Steam, Roblox, ChatGPT, Outlook ve vize randevu siteleri çıkıyor. Ortak yanları şu: kullanıcı buralarda farkında olmadan çok istek üretir.

• Oyun platformlarında market ve takas sayfaları. Fiyat listesi, envanter ve teklif sayfaları her açılışta arka planda çok sayıda sorgu gönderir. Fiyat takibi yapan bir tarayıcı eklentisi sınırı dakikalar içinde doldurabilir. Hesabınıza bağladığınız üçüncü taraf araçlar da sizin adınıza istek gönderir.
• Yapay zekâ sohbetleri. Her mesaj pahalı bir işlemdir, bu yüzden sınır hem toplam mesaj sayısına hem de mesajların sıklığına konur. Aynı hesabı birkaç kişinin paylaşması ya da yanıtı art arda yeniden ürettirmek sınıra en hızlı götüren yoldur.
• E-posta hesapları. Yanlış şifreyle yapılan giriş denemeleri, eski şifreyle bağlanmaya çalışan unutulmuş bir telefon ya da bir e-posta programı sayacı sizin yerinize doldurur.
• Randevu ve bilet siteleri. Burada isteği üreten doğrudan kullanıcının kendisidir: boş yer çıkar mı diye birkaç saniyede bir yenilenen sayfa.

Bunların hiçbiri size uymuyorsa geriye paylaşılan IP adresi kalır. Sayaç IP'ye bağlıysa aynı adresten internete çıkan herkes (ofisteki bütün bilgisayarlar, mobil veride aynı genel adresin arkasındaki aboneler) tek kişi gibi sayılır: sayacı başkası doldurur, 429'u siz görürsünüz. Mekanizmayı ve kendi bağlantınızda nasıl anlayacağınızı CGNAT Nedir, Nasıl Anlaşılır? CGNAT Havuzundan Çıkma yazımızda anlattık. Ücretsiz VPN ve proxy hizmetlerinde aynı çıkış adresini çok daha kalabalık bir grup kullanır; ayrıntısı Ücretsiz Proxy ve Web Proxy Siteleri Güvenli mi? yazımızda.

429 hatası ne kadar sürer? Yenilemek neden işe yaramaz?#

Tek bir cevap yok, çünkü süreyi standart değil hizmetin kendisi belirler. Saniyelik bir pencere birkaç saniyede, saatlik bir kota bir saat içinde, günlük bir kota ertesi gün açılır. MDN'in örnek yanıtında Retry-After: 3600 yazar, yani bir saat.

Yenilemek işe yaramaz, çünkü F5 sunucu açısından yeni bir istektir: ya doğrudan reddedilir ya da sayaca eklenip bekleme süresini uzatabilir. Kayan pencere kullanan bir hizmette (aşağıda anlatıyoruz) sürekli deneyen kullanıcının sayacı hiç boşalmaz.

Süreyi tahmin etmek yerine okuyabilirsiniz: tarayıcıda F12 ile geliştirici araçlarını açın, Ağ (Network) sekmesinde sayfayı bir kez yenileyin ve 429 satırına tıklayın. Yanıt başlıkları arasında Retry-After varsa karşısındaki sayı, saniye cinsinden bekleme süresidir.

Ziyaretçiyseniz ne yapmalısınız?#

1. Durun. Sekmeyi kapatın, uygulamadan çıkın ve birkaç dakika hiçbir şey denemeyin.
2. Sizin yerinize istek gönderenleri kapatın. Aynı sitenin açık kalan diğer sekmeleri, otomatik yenileme ve fiyat takip eklentileri, arka planda çalışan masaüstü uygulaması, hesabınıza bağlı üçüncü taraf araçlar.
3. Hata giriş ekranındaysa şifre denemeyi bırakın. Her yanlış deneme bekleme süresini uzatabilir. Emin değilseniz bekledikten sonra "şifremi unuttum" yolunu kullanın. Eski şifreyi denemeye devam eden bir cihaz varsa onu güncelleyin.
4. Bir kez deneyin. Açıldıysa sorun bitmiştir. Açılmadıysa bekleme süresini uzatın: on dakika, yarım saat, birkaç saat.
5. Bağlantının payını ölçün. VPN ya da ücretsiz proxy açıksa kapatın, sonra telefonunuzun mobil verisiyle deneyin. Orada açılıyor, ofis ya da ev ağında açılmıyorsa sayaç paylaştığınız adrese aittir. İki bağlantıda da aynı hatayı alıyorsanız sayaç hesabınıza bağlıdır ve beklemekten başka yol yoktur.
6. Hata normal kullanımda her gün çıkıyorsa hizmetin desteğine yazın. Ne yaparken ve hangi mesajla karşılaştığınızı belirtin.

Çerezleri silmek, tarayıcı değiştirmek ya da modemi kapatıp açmak bu listede yok, çünkü sayaç çoğu zaman bunların değiştirmediği bir şeye (hesabınıza ya da paylaşılan adrese) bağlıdır. Google aramalarında çıkan benzer uyarının kendine özgü nedenlerini Google Olağandışı Trafik Hatası Nedir, Nasıl Çözülür? yazımızda ele aldık.

Rate limit algoritmaları: sabit pencere, kayan pencere ve token bucket#

Buradan sonrası geliştiriciler için. "Dakikada 10 istek" kuralı, sayacın nasıl tutulduğuna göre üç farklı biçimde davranır.

Kayan pencerenin yaklaşık hesabını Cloudflare kendi hız sınırlayıcısını anlattığı yazıda bir örnekle gösterir: sınır dakikada 50 istek, önceki dakikada 42 istek gelmiş, içinde bulunulan dakikanın 15. saniyesinde 18 istek sayılmış. Tahmin 42 × (45/60) + 18 = 49,5 olur, yani sınırın hemen altı. Token bucket'ı Stripe kendi hız sınırlayıcılarını anlattığı yazıda özetler: her kullanıcının bir kovası vardır, her istek bir jeton alır, kovaya yavaş yavaş yeni jeton damlar.

Farkı görmenin en kısa yolu aynı trafiği üçüne de vermektir. Aşağıdaki Python betiği ağ bağlantısı kullanmaz; yalnızca zaman damgalarını üç sayaca sorar.

LIMIT = 10      # pencere başına izin verilen istek
WINDOW = 60     # pencere uzunluğu (saniye)


class FixedWindow:
    def __init__(self):
        self.window_id, self.count = None, 0

    def allow(self, now):
        window_id = int(now // WINDOW)
        if window_id != self.window_id:          # yeni pencere: sayaç sıfırlanır
            self.window_id, self.count = window_id, 0
        if self.count >= LIMIT:
            return False
        self.count += 1
        return True


class SlidingWindow:
    def __init__(self):
        self.window_id, self.count, self.previous = None, 0, 0

    def allow(self, now):
        window_id = int(now // WINDOW)
        if window_id != self.window_id:
            # bir önceki pencere boş geçtiyse devreden sayı sıfırdır
            self.previous = self.count if window_id - 1 == self.window_id else 0
            self.window_id, self.count = window_id, 0
        elapsed = now % WINDOW
        # önceki pencerenin sayısı, kalan payı oranında hesaba katılır
        estimate = self.previous * (WINDOW - elapsed) / WINDOW + self.count
        if estimate >= LIMIT:
            return False
        self.count += 1
        return True


class TokenBucket:
    def __init__(self):
        self.tokens, self.updated = float(LIMIT), 0.0

    def allow(self, now):
        # geçen süre kadar jeton eklenir, kova kapasiteyi aşamaz
        self.tokens = min(LIMIT, self.tokens + (now - self.updated) * LIMIT / WINDOW)
        self.updated = now
        if self.tokens < 1:
            return False
        self.tokens -= 1
        return True


def run(name, timestamps):
    print(name)
    for limiter in (FixedWindow(), SlidingWindow(), TokenBucket()):
        accepted = sum(limiter.allow(t) for t in timestamps)
        print(f"  {type(limiter).__name__:<14} {accepted}/{len(timestamps)} kabul")


# Senaryo 1: pencere sınırının iki yanında iki patlama (59. ve 61. saniye)
run("Sınırda patlama", [59.0] * 10 + [61.0] * 10)
# Senaryo 2: iki dakika boyunca 7,5 saniyede bir istek (dakikada 8)
run("Sabit tempo", [i * 7.5 for i in range(16)])

Çıktı:

Sınırda patlama
  FixedWindow    20/20 kabul
  SlidingWindow  11/20 kabul
  TokenBucket    10/20 kabul
Sabit tempo
  FixedWindow    16/16 kabul
  SlidingWindow  16/16 kabul
  TokenBucket    16/16 kabul

İlk senaryoda sabit pencere "dakikada 10" kuralına rağmen iki saniyede 20 isteği geçirdi, çünkü sayaç 60. saniyede sıfırlandı. Kayan pencere önceki dakikanın yükünü hatırladı ve ikinci patlamadan tek bir isteği kabul etti (hesap yaklaşık olduğu için tam 10'da durmadı). Token bucket jetonlarını ilk patlamada harcadı ve ikincisinin tamamını reddetti. İkinci senaryo istemci için asıl dersi verir: sınırın altında ve düzenli giden trafik hiçbir algoritmada 429 görmez. Sınıra takılan şey ortalama değil, yığılmadır.

Aynı token bucket mantığını istemci tarafında, kendi isteklerinizi frenlemek için kullanan bir örnek LLM'e Güvenli Web Erişimi: Hız Sınırı ve İzinler yazımızda var.

API kullanıyorsanız: sınır başlıklardan nasıl okunur?#

İyi belgelenmiş API'ler sınırı sürpriz olmaktan çıkarır: her yanıtta kotanızın ne kadarının kaldığını başlıklarla bildirir. GitHub'ın kota uç noktası bunu denemek için uygundur, çünkü bu uç noktaya yapılan çağrılar birincil kotanızdan düşmez:

curl -s -o /dev/null -D - https://api.github.com/rate_limit | grep -i -E "^HTTP|^x-ratelimit"

Kimliksiz bir çağrıda yanıt şuna benzer:

HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 53
X-RateLimit-Used: 7
X-RateLimit-Resource: core
X-RateLimit-Reset: 1789799592

Limit penceredeki toplam hakkı, Remaining kalanı, Reset sayacın sıfırlanacağı anı (Unix zamanı, saniye) verir. Buradaki 60 sayısı IP adresinize aittir; aynı ofisten aynı komutu çalıştıran iş arkadaşınız da aynı sayaçtan harcar. Bu başlıkları okuyan bir program sınıra yaklaşırken kendiliğinden yavaşlayabilir.

Dikkat edilecek üç nokta var:

• Başlık adları standart değildir. X-RateLimit-* yaygın bir alışkanlıktır, ama Reset kimi API'de Unix zamanı, kimi API'de kalan saniyedir. IETF bu dağınıklık için RateLimit ve RateLimit-Policy başlıklarını tanımlayan bir taslak üzerinde çalışıyor; bu yazı yazılırken metin henüz RFC olmamıştı.
• Sınır her zaman 429 ile gelmez. GitHub aynı belgede sınır aşıldığında 403 ya da 429 dönebileceğini yazar. Yalnız koda değil, başlıklara ve gövdedeki mesaja da bakın.
• Hız sınırı ile kota ayrı şeylerdir. Dakikalık hız sınırı beklemeyle açılır; aylık kota ya da biten bakiye plan ve ödeme tarafında çözülür. İkisi aynı kodla gelebilir, farkı gövdedeki mesaj söyler.

429 aldıktan sonrası için kural kısadır. Retry-After varsa ona uyun; yoksa üstel geri çekilme uygulayın (1, 2, 4, 8 saniye, her birine rastgele bir pay ekleyerek), denemelere üst sınır koyun ve beklemeyi o hizmete giden bütün isteklerinize uygulayın. Retry-After'ın iki biçimini ve bu kararları uygulayan denenmiş Python örneğini Scraping'de HTTP Hata Kodları: 403, 407, 429 ve 503 yazımızda verdik; aynı kodu burada tekrar etmiyoruz. Eşzamanlılığın 429 oranına etkisi Concurrency ve Parallelism: Scraping Hızını Ne Belirler? yazımızda.

Rate limit IP değiştirerek aşılır mı?#

Çoğu durumda hayır. Sayaç hesaba, oturuma ya da API anahtarına bağlıysa IP adresi zaten hesaba katılmıyordur: yeni adresten gelen istek aynı hesabın sayacına yazılır.

Sayaç IP'ye bağlı olduğunda bile IP değiştirmek sorunu çözmez, yerini değiştirir. Sınırın derdi kimliğiniz değil, hizmete bindirdiğiniz yüktür. Aynı tempoyu başka adreslere bölmek sunucuyu aynı ölçüde yorar; bunu fark eden hizmet kuralı davranışa göre yazar ve engel 429'dan daha kalıcı bir biçime döner. X-Forwarded-For başlığına sahte adres yazmak ya da her istekte User-Agent değiştirmek de aynı sınıfa girer: düzgün yapılandırılmış bir sunucu istemcinin yazdığı adrese güvenmez, tutarsız başlıklar ise otomatik trafiğin görünür bir işaretidir. Sitelerin bu işaretleri nasıl okuduğunu Bot Tespiti Nasıl Yapılır? Anti-Bot Sistemlerinin Mantığı yazımızda anlattık.

IP rotasyonunun meşru bir yeri vardır, ama o yer "429 aldıktan sonra" değildir. İzinli ve büyük hacimli bir veri toplama işinde önce toplam tempo sitenin kaldırabileceği, robots.txt ve kullanım şartlarıyla uyumlu bir düzeye indirilir; sonra bu trafik adreslere dağıtılır. Hıza uymanın pratik yolları Web Scraping'de Engellenmeden Veri Toplama Yöntemleri yazımızda. Rotasyonun nasıl işlediği IP Rotasyonu Nedir ve Nasıl Çalışır? yazımızda, ürün tarafı rotating proxy sayfamızda.

Kimler hız sınırıyla iş gereği uğraşır?#

• Fiyat ve stok izleyen ekipler. Her gün binlerce ürün sayfası okuyan bir iş, tempoyu siteye göre ayarlamazsa 429 oranı hızla artar: fiyat izleme çözümü.
• Katalog ve pazar verisi toplayanlar. Her site için ayrı bir hız bütçesi tutulur: veri kazıma çözümü.
• IP izin listesi isteyen API'lere bağlananlar. Kota o adrese ya da anahtara yazılır: API için Statik IP: IP Yetkilendirme Hatası Nasıl Çözülür?.
• Otomasyon kuranlar. Aynı dakikada yüzlerce çağrı başlatan iş akışı ilk çalıştırmada sınıra takılır; bekleme ayarları n8n ile Web Scraping: HTTP Request ve Proxy Ayarları yazımızda.
• Kalabalık bir ağdan çalışan operasyon ekipleri. Onlarca çalışan aynı panele tek ofis adresinden bağlanıyorsa IP bazlı sayaç ekibin toplamını görür. Burada aranan şey sınırı aşmak değil, sayacı yalnız kendi kullanımınıza bağlamaktır: ISP Proxy bir internet servis sağlayıcısına kayıtlı, başkasıyla paylaşılmayan sabit bir adres verir.

Sık yapılan hatalar#

• 429 ekranında yenilemeye devam etmek. Her yenileme sayaca yazılır.
• Giriş sınırında şifre denemeyi sürdürmek. Bekleme süresi uzar, bazı hizmetlerde hesap geçici olarak kilitlenir.
• Sınırın IP'ye bağlı olduğunu varsaymak. Sayaç hesaba ya da anahtara bağlıysa ağ değiştirmek boşa giden zamandır.
• Geliştirici tarafında beklemeden yeniden denemek. 429'a anında verilen yanıt yeni bir 429'dur.
• Aynı API anahtarını birçok programda kullanıp sınırı tek tek programlarda aramak. Sayaç anahtara aittir; toplamı görmeden teşhis konmaz.

Karar rehberi#

Sıkça sorulan sorular#

429 Too Many Requests kalıcı bir engel mi?#

Hayır. 429 süreye bağlı bir sayaçtan gelir ve sayaç boşaldığında erişim kendiliğinden açılır. Hesabınıza bir işlem yapılmaz.

"Too many requests" virüs ya da internet arızası anlamına gelir mi?#

Gelmez. Mesaj, bağlandığınız hizmetin sunucusundan gelir ve yalnızca istek sayısıyla ilgilidir. Başka siteler normal açılıyorsa internetinizde sorun yoktur.

Modemi kapatıp açmak 429 hatasını çözer mi?#

Güvenilir bir yol değildir. Modem yeniden bağlanınca IP adresi bazı aboneliklerde değişir, bazılarında değişmez; sayaç hesaba bağlıysa zaten fark etmez. IP adresinin hangi koşullarda değiştiğini IP Adresi Nasıl Değiştirilir? Telefon, PC ve Modem yazımızda anlattık.

Rate limit ile IP banı aynı şey mi?#

Değil. Rate limit süreye bağlı bir sayaçtır: herkese uygulanır ve bekleyince açılır. IP banı belirli bir adrese verilmiş, uzun süreli bir karardır ve genellikle 403 ile kendini gösterir. Sınırı sürekli zorlayan bir adres zamanla ikinci gruba geçebilir.

Retry-After başlığı yoksa ne kadar beklemeliyim?#

Kullanıcıysanız birkaç dakikayla başlayın ve her başarısız denemede süreyi uzatın. Program yazıyorsanız üstel geri çekilme uygulayın ve deneme sayısına üst sınır koyun.

Proxy kullanmak 429 hatasını çözer mi?#

Sınırı kendi tempo ya da davranışınız dolduruyorsa hayır: aynı tempo yeni adresin sayacını da doldurur, hesaba bağlı sayaç ise adresi hiç görmez. Proxy'nin fark yarattığı durum, sayacı sizin değil adresi paylaştığınız başkalarının doldurmasıdır. O zaman yalnız size ait sabit bir adres, sayacı kendi kullanımınıza indirir.

Özet#

429 Too Many Requests, bir hizmetin hız sınırına (rate limit) takıldığınızı söyleyen geçici bir yanıttır. Sınır IP adresine, hesaba, oturuma, API anahtarına ya da tek bir uç noktaya göre sayılabilir; neyin işe yarayacağını bu belirler. Kullanıcı için çözüm durmak, arka planda istek gönderenleri kapatmak ve beklemektir. Geliştirici için çözüm kota başlıklarını okumak, Retry-After'a uymak ve tempoyu düşürmektir. Sınır IP döndürerek aşılmaz; rotasyon yalnızca baştan planlanmış, siteye saygılı bir yükü dağıtmak içindir. İşiniz için uygun adres türlerini proxy hizmetlerimizde bulabilirsiniz.