Too Many Requests Ne Demek? 429 Hatası ve Çözümü

Too Many Requests ne demek?

Gece vardiyasında bir API’nin neden yavaşladığını araştırırken ilk gördüğüm şey 429 değildi; 429’a dönüşen 200 yanıtlarıydı. İstemci, hata aldığı her denemeden sonra daha hızlı tekrar bağlanıyordu. Rate limit devreye girince uygulama kendisini korumaya çalışmış, istemci de farkında olmadan yükü artırmıştı.

Too Many Requests, bir istemcinin kısa süre içinde izin verilenden fazla istek gönderdiğini anlatır. HTTP 429 durum kodu, sunucunun isteği anladığını fakat geçici olarak işleyemediğini belirtir. Kaynak tarayıcı, API istemcisi, cron görevi veya ortak kullanılan bir IP adresinin kotayı doldurması olabilir.

Tarayıcıda ya da API yanıtında 429 Too Many Requests gördüğünüzde ilk işiniz sayfayı art arda yenilemek olmasın. Bu davranış, gerçekten bir istek sınırına takıldıysanız bekleme süresini uzatabilir. Önce yanıt başlıklarını, uygulama loglarını ve isteği üreten kaynağı kontrol edin.

429 hatası neden oluşur?

HTTP durum kodlarını tanımlayan standartlarda 429, istemcinin belirli bir süre içinde çok fazla istek gönderdiğini ifade eder. IETF’nin RFC 6585 belgesinde belirtildiği gibi sunucu, istemcinin tekrar ne zaman deneyebileceğini Retry-After başlığıyla bildirebilir. Bu başlık saniye cinsinden bir değer veya HTTP tarih formatı taşıyabilir; her sunucunun bu başlığı eklemesi zorunlu değildir.

Limitin neye göre hesaplandığı sağlayıcıya ve uygulamaya göre değişir. Sık karşılaşılan ölçütler şunlardır:

• Tek bir IP adresinden gelen istek sayısı
• Kullanıcı hesabı, API anahtarı veya oturum başına istek sayısı
• Belirli bir endpoint için saniye, dakika ya da saatlik kota
• Sunucunun eşzamanlı bağlantı veya çalışan işlem sınırı
• Paylaşımlı hosting ya da NAT arkasındaki kullanıcıların ortak kotası
• Şüpheli trafik algılayan WAF, CDN veya reverse proxy kuralları

Bu yüzden aynı sayfa bir bağlantıda açılırken başka bir bağlantıda 429 verebilir. Şirket ağı, mobil operatör veya ortak Wi-Fi arkasında çok sayıda kullanıcı aynı dış IP’yi paylaşabilir. Sunucu kullanıcıları ayrı ayrı tanımıyorsa bütün bu trafik tek istemci gibi görünür.

429 ile 403 ve 503 arasındaki fark nedir?

Bu kodlar bazen aynı hata sayfasında gösterildiği için karıştırılıyor. 429, doğrudan istek hızının veya kotanın aşıldığı duruma işaret eder. 403, sunucunun isteği anladığı fakat erişime izin vermediği anlamına gelir. 503 ise hizmetin geçici olarak hazır olmadığını ifade eder; yoğunluk sebep olabilir ama her 503 yanıtı rate limit anlamına gelmez.

429 yerine 502 görüyorsanız konu farklı olabilir. Bu ayrım için 502 Bad Gateway Hatası Nedir ve Nasıl Çözülür? başlıklı yazıdaki upstream kontrolleri daha uygun olur. HTTP kodunu yalnızca hata sayfasının başlığından değil, gerçek yanıt başlığından doğrulayın.

429 hatası nasıl kontrol edilir?

Tarayıcı ekranı sınırlı bilgi verir. Ben sunucu veya API tarafında önce curl ile yanıt başlıklarını alırım. -I seçeneği yalnızca HEAD isteği gönderir; bazı uygulamalar HEAD’i GET gibi ele almadığı için gerektiğinde -sS -D - -o /dev/null biçimini kullanmak daha güvenlidir.

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

Çıktıda özellikle şu alanları arayın:

HTTP/2 429
retry-after: 30
content-type: application/json
x-ratelimit-limit: 60
x-ratelimit-remaining: 0
x-ratelimit-reset: 1710000030

Buradaki retry-after: 30, sunucunun yaklaşık 30 saniye beklenmesini istediğini gösterir. x-ratelimit-* başlıkları standart HTTP başlıkları değildir; uygulama veya sağlayıcı tarafından eklenir. Bu alanları görmemeniz rate limit olmadığı anlamına gelmez.

İstemcinin gerçekte ne sıklıkta istek gönderdiğini de ölçün. Üretim API’sine kontrolsüz bir döngü çalıştırmak yerine düşük sayıda istekle ve açık bir beklemeyle ilerleyin:

for i in 1 2 3 4 5; do
  date -Is
  curl -sS -o /dev/null -w 'HTTP %{http_code}n' https://example.com/api/items
  sleep 2
done

Bu komut teşhis içindir; limitleri aşmak için kullanılmamalı. Yanıt kodları ve zaman damgaları, sorunun belirli bir istek yoğunluğuyla başlayıp başlamadığını gösterir. Ben bir müşteri API’sinde 429 satırlarını görünce önce sunucuyu suçlamıştım. Aynı dakikadaki User-Agent ve istek yollarını karşılaştırınca iki ayrı worker’ın aynı endpoint’i paralel biçimde taradığını gördüm. Sorun rate limit kuralında değil, istemcinin çalışma modelindeydi.

Sunucu loglarında hangi alanlara bakılır?

Web sunucusu, proxy ve uygulama farklı şeyler kaydedebilir. Nginx erişim loglarında durum kodu, istek yolu, istemci IP’si ve User-Agent birlikte incelenmelidir. Kullandığınız log formatı değişebilir; aşağıdaki komut tipik bir erişim logu için örnektir.

grep ' 429 ' /var/log/nginx/access.log | tail -n 20

Belirli bir IP’nin tekrarını görmek için:

awk '$9 == 429 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Bu satırdaki $9 alanı, standart combined log formatında HTTP durum kodudur. Kendi log_format tanımınız farklıysa sütun numarası değişir; bir log satırını açıp alanları saymadan komutu körlemesine kopyalamayın. Log okumadan servisi yeniden başlatmak, rate limit kuralını da uygulama davranışını da değiştirmez.

429 hatası alan kullanıcı ne yapmalı?

Bir ziyaretçi veya API tüketicisi olarak yapılacaklar basit görünür, fakat sıranın önemi var. Önce yanıtın geçici mi, sürekli mi olduğunu ayırın.

1. Bekleyin: Yanıtta Retry-After varsa belirtilen süre dolmadan tekrar denemeyin.
2. İstek sayısını azaltın: Sayfayı sürekli yenilemeyin, paralel API çağrılarını düşürün.
3. İstemciyi kontrol edin: Tarayıcı eklentileri, mobil uygulamalar, script’ler ve arka planda çalışan senkronizasyon görevleri istek üretebilir.
4. Kimlik bilgisini doğrulayın: Başarısız kimlik doğrulama denemeleri bazı sistemlerde rate limit sayacını artırabilir.
5. Yanıt başlıklarını kaydedin: Destek talebine URL, zaman, durum kodu ve varsa istek kimliğini ekleyin.
6. VPN’i hemen çözüm sanmayın: Yeni IP adresi de limitli olabilir; sağlayıcının güvenlik kurallarına da takılabilirsiniz.

API kullanan bir uygulamada yeniden deneme davranışı özellikle önemlidir. Sabit aralıklarla tekrar tekrar denemek yerine exponential backoff kullanılır. İlk bekleme kısa tutulur, sonraki denemelerde süre artırılır ve aynı anda çalışan isteklerin hepsi birlikte tekrar gönderilmez.

import random
import time

import requests

url = "https://example.com/api/items"
delay = 1

for attempt in range(5):
    response = requests.get(url, timeout=10)

    if response.status_code != 429:
        response.raise_for_status()
        data = response.json()
        break

    retry_after = response.headers.get("Retry-After")
    wait = int(retry_after) if retry_after and retry_after.isdigit() else delay
    time.sleep(wait + random.uniform(0, 0.5))
    delay = min(delay * 2, 60)

Bu örnekte Retry-After sayısal olduğunda ona uyulur, başlık yoksa bekleme katlanarak artırılır. Gerçek uygulamada HTTP tarih biçimini, güvenli üst sınırı ve idempotent olmayan istekleri ayrıca ele alın. Bir ödeme isteğini yanıt alınamadı diye otomatik tekrar göndermek çift işlem üretebilir; yeniden deneme politikası endpoint’in davranışına göre yazılmalıdır.

Sunucu yöneticisi 429 sorununu nasıl çözer?

Yönetici tarafındaki amaç limiti kaldırmak değil, meşru trafiği korurken kontrolsüz istemciyi sınırlamaktır. Önce 429’u hangi katmanın ürettiğini bulun: CDN, WAF, Nginx, uygulama framework’ü, API gateway veya doğrudan upstream servis.

Nginx ile istek hızını sınırlama

Nginx dokümantasyonundaki limit_req_zone ve limit_req direktifleri, paylaşımlı bir bellek alanı ve istek oranı tanımlamak için kullanılır. Genel bir API alanı için basit bir örnek:

http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

    server {
        location /api/ {
            limit_req zone=api_limit burst=20 nodelay;
            proxy_pass http://backend;
        }
    }
}

$binary_remote_addr IP adresini daha az bellekle anahtar olarak tutar. rate=10r/s ortalama hızı belirler; burst=20 kısa süreli birikmiş isteklere alan açar. nodelay kullanıldığında burst içindeki istekler bekletilmek yerine hemen işlenir. Burst alanı da aşıldığında Nginx 429 döndürebilir. Bu değerleri kopyalayıp bütün siteye uygulamak doğru değildir.

Giriş endpoint’i, arama endpoint’i ve statik dosyalar aynı davranışa sahip değildir. Girişte düşük bir hız ve ayrı bir limit gerekebilir. Statik dosyaları aynı rate limit alanına koyarsanız tek bir sayfa yüklemesi bile gereksiz sayaç tüketebilir.

Değişiklikten sonra Nginx yapılandırmasını test edin:

sudo nginx -t
sudo systemctl reload nginx

reload, çalışan bağlantıları çoğu durumda kesmeden yeni yapılandırmayı yükler. Test başarısızsa reload gerçekleşmez; bu yüzden önce nginx -t çalıştırmak küçük ama değerli bir alışkanlık. Production prompt’larımın kırmızı olmasının bir sebebi de bu tür değişikliklerde yanlış makineye dokunma korkusudur.

Uygulama tarafında limit ve kuyruk tasarımı

Rate limit’i yalnızca web sunucusuna bırakmak her zaman yeterli olmaz. API anahtarı, kullanıcı hesabı ve endpoint bazında sayaç tutmak için uygulama katmanında Redis gibi paylaşımlı bir depolama kullanılabilir. Birden fazla uygulama sunucusu varsa her makinenin belleğinde ayrı sayaç tutmak tutarsız sonuç verir; kullanıcı bir sunucuda limite takılırken diğerinde takılmayabilir.

Uzun süren işleri HTTP isteğinin içinde tamamlamaya çalışmak da 429 ve timeout problemlerini artırır. Dosya işleme, rapor üretme veya toplu veri aktarma gibi işleri kuyruğa alıp istemciye bir iş kimliği döndürmek daha kontrollüdür. İstemci işi sorgulayacaksa bu sorgunun da makul aralıklarla yapılması gerekir. Yoksa kuyruk çözülürken status endpoint’i yeni darboğaz olur.

IP bazlı limitin sakıncaları

IP adresi pratik bir anahtardır ama kullanıcı kimliği değildir. IPv4 NAT, kurumsal ağlar, mobil operatörler ve IPv6 geçişleri aynı hesabın farklı görünmesine veya farklı kullanıcıların tek IP gibi algılanmasına yol açabilir. Güvenilir bir kimlik doğrulama katmanınız varsa kullanıcı veya API anahtarı bazlı limiti, IP bazlı korumayla birlikte değerlendirin.

Proxy arkasındaki gerçek istemci IP’sini almak için X-Forwarded-For başlığına körü körüne güvenmeyin. Bu başlık yalnızca güvendiğiniz proxy tarafından set ediliyorsa kullanılmalı; aksi halde istemci kendi sahte IP’sini gönderip limiti aşabilir. Proxy katmanlarını ayırmak için Proxy Nedir? Proxy Sunucu Ne İşe Yarar? yazısına bakabilirsiniz.

Rate limit değerleri nasıl belirlenir?

Tek bir doğru sayı yoktur. Limit; endpoint’in iş maliyeti, beklenen trafik, istemci davranışı ve backend kapasitesi ölçülerek belirlenir. Ana sayfa için kabul edilebilir bir istek oranı, pahalı bir arama sorgusu veya giriş denemesi için uygun olmayabilir.

Başlangıçta şu verileri toplayın:

• Endpoint başına dakika ve saniye bazında istek sayısı
• Yanıt süreleri ve hata oranları
• CPU, bellek, disk I/O ve veritabanı bağlantı sayısı
• İsteklerin kullanıcı, API anahtarı ve IP dağılımı
• Yoğun saatlerdeki normal trafik ile ani sıçramalar

Limitin istemciye açıkça bildirilmesi de gerekir. Belgede kota birimi, pencere süresi, 429 davranışı ve Retry-After kullanımı yazsın. Yanıt gövdesi JSON ise makine tarafından okunabilir bir hata kodu sağlayın:

{
  "error": "rate_limited",
  "message": "Too many requests",
  "retry_after": 30
}

İstemci bu alanı okuyup kontrollü biçimde bekleyebilir. Gerçek tarih ve saniye bilgisinin hangi başlıkta taşındığını dokümante edin; farklı servislerde aynı isimlerin farklı anlamlara gelmesi entegrasyonu zorlaştırır.

429 hatası DDoS anlamına mı gelir?

Hayır. 429, normal bir istemcinin aşırı hızlı çalışmasından da doğabilir; tek başına saldırı kanıtı değildir. Bir DDoS olayında çok sayıda kaynak, farklı URL’ler veya bağlantı tüketimi görülebilir. 429 ise çoğunlukla bir katmanın belirlediği istek politikasının devreye girdiğini söyler.

Yine de 429 kayıtları trafik incelemesi için yararlıdır. Aynı zaman aralığında CPU, bağlantı sayısı, upstream bekleme süresi ve ağ trafiğini karşılaştırın. Çok sayıda farklı IP aynı endpoint’i olağandışı hızda çağırıyorsa CDN veya upstream filtreleme, bot doğrulama ve endpoint tasarımı birlikte değerlendirilmelidir. Sunucuyu refleks olarak yeniden başlatmak sayaçları sıfırlasa bile kaynağı ortadan kaldırmaz.

Rate limiting, DDoS korumasının tamamı değildir. Büyük hacimli saldırılarda trafik sunucuya ulaşmadan önce filtrelenmelidir; küçük ve uygulama katmanındaki kötüye kullanımlarda ise endpoint bazlı limit, kimlik doğrulama ve kuyruklama işe yarayabilir.

İstemci tarafında sık yapılan hatalar

• Her hatada anında tekrar denemek: Retry-After değerini yok saymak yükü artırır.
• Paralel istek sayısını sınırsız bırakmak: Promise veya worker havuzu kontrol edilmezse kısa sürede kota tükenir.
• Cache kullanmamak: Değişmeyen veriyi her sayfa açılışında yeniden istemek gereksizdir.
• Sayfalama yerine bütün veriyi çekmek: Büyük kataloglar için pagination veya delta senkronizasyonu tercih edilmelidir.
• Başarısız istekleri loglamamak: İstemci tarafında zaman damgası ve yanıt kodu yoksa kaynağı bulmak zorlaşır.
• Hız limiti kaldırılınca sorunun bittiğini sanmak: Backend kapasitesi değişmediyse 429’un yerini 5xx hataları alabilir.

Özellikle JavaScript tarafında görünmez polling döngülerini kontrol edin. Sekme arka plana geçtiğinde de çalışan timer’lar, iki kez başlatılmış WebSocket yeniden bağlanma kodları ve başarısız isteklerde sınırsız retry sık rastladığım nedenler arasında.

Sık Sorulan Sorular

Too Many Requests hatası ne kadar sürer?

Sabit bir süre yoktur. Sunucu Retry-After başlığı veriyorsa belirtilen süreyi esas alın; başlık yoksa sağlayıcının kota penceresini ve dokümantasyonunu kontrol edin.

429 hatasını sayfayı yenileyerek düzeltebilir miyim?

Genellikle hayır. Her yenileme yeni bir istek gönderdiği için limit süresini uzatabilir. Bir süre bekleyin, arka plandaki otomasyonları durdurun ve farklı bir ağa geçmeden önce sağlayıcıdaki kota durumunu doğrulayın.

API için 429 aldığımda ne yapmalıyım?

Retry-After ve sağlayıcının rate limit başlıklarını okuyun. Exponential backoff, jitter, kontrollü paralellik ve endpoint’e uygun cache kullanın; idempotent olmayan istekleri otomatik tekrar göndermeyin.

Nginx 429 hatasını nasıl kapatabilirim?

Önce hangi limit_req kuralının yanıtı ürettiğini ve neden devreye girdiğini bulun. Limiti tamamen kaldırmak yerine doğru endpoint, istemci anahtarı ve burst değerini belirlemek daha güvenlidir; değişiklikten önce nginx -t ile yapılandırmayı doğrulayın.

Ben 429 gördüğümde artık ilk olarak bekleme süresine değil, isteği kimin ve hangi sıklıkta ürettiğine bakıyorum. Çünkü doğru limit çoğu zaman sunucuda değil, istemcinin kontrolsüz döngüsünde saklıdır.

Kaynaklar

• IETF RFC 6585 – Additional HTTP Status Codes — rfc-editor.org
• NGINX – Request Rate Limiting — nginx.org
• MDN – 429 Too Many Requests — developer.mozilla.org