Bir web sitesi veya API, kısa süre içerisinde çok sayıda istek aldığında bazı bağlantıları geçici olarak reddedebilir. Tarayıcıda, uygulama günlüklerinde veya API yanıtlarında görülen 429 Too Many Requests hatası, genellikle bu tür bir istek sınırlandırmasının sonucudur.
Ancak 429 hatasının ortaya çıkması, sunucunun mutlaka aşırı yüklendiği anlamına gelmez. Web sunucusu, CDN, güvenlik duvarı veya uygulama tarafından tanımlanan bir rate limiting kuralı, sistem kaynakları yeterli olsa bile isteği reddedebilir.
Bu nedenle çözüm, yalnızca beklemek veya istek sınırını yükseltmek değildir. Öncelikle 429 yanıtını hangi bileşenin oluşturduğu, hangi istemcilerin etkilendiği ve sınırlamanın neden devreye girdiği belirlenmelidir.
429 Too Many Requests Hatası Nedir?
429 Too Many Requests, HTTP protokolünde istemcinin belirli bir zaman aralığında fazla sayıda istek gönderdiğini belirten durum kodudur.
Bu kod, RFC 6585 standardının 4. bölümünde tanımlanmıştır. Sunucu, istemcinin isteği ne zaman yeniden deneyebileceğini bildirmek amacıyla Retry-After yanıt başlığını da gönderebilir.
Örneğin bir API, belirli bir kullanıcı hesabına dakikada 100 istek hakkı tanımlayabilir. Bu sınır aşıldığında ek istekler geçici olarak reddedilebilir.
Buradaki 100 istek değeri yalnızca örnektir. Gerçek sınırlar uygulamaya, servis sağlayıcısına, hesap türüne ve kullanılan güvenlik politikalarına göre değişir.
429 yanıtı farklı katmanlarda üretilebilir:
- Web sunucusu: Nginx veya Apache üzerinde tanımlanan sınırlandırmalar.
- CDN ve WAF: İstek yoğunluğunu veya belirli davranışları izleyen güvenlik kuralları.
- Uygulama: Kullanıcı, oturum, API anahtarı veya abonelik bazlı kotalar.
- API ağ geçidi: Birden fazla servise yönlendirilen isteklerin merkezi kontrolü.
429 hatası bir 4xx durum kodudur. Ancak her zaman hatalı HTTP sözdizimi veya geçersiz parametre anlamına gelmez. İstek yapısal olarak doğru olsa bile belirlenen kullanım sınırını aşmış olabilir.
Rate Limiting Nedir ve Nasıl Çalışır?
Rate limiting, bir istemcinin belirli bir zaman aralığında gerçekleştirebileceği işlem veya istek miktarını kontrol eden mekanizmadır.
Bu mekanizma özellikle API hizmetlerinde, oturum açma ekranlarında, arama uç noktalarında ve yoğun istek alan web uygulamalarında kullanılır.
Temel amaçlar arasında kaynak tüketimini kontrol etmek, kötüye kullanımı sınırlamak ve farklı kullanıcılar arasında hizmet kapasitesini dengeli dağıtmak bulunur.
IP adresine göre sınırlama
IP bazlı rate limiting, aynı kaynak IP adresinden gelen istekleri sayar.
Örneğin aynı IP adresinden kısa sürede çok sayıda oturum açma isteği gelirse güvenlik sistemi ek istekleri reddedebilir.
Ancak bir IP adresi her zaman tek bir kullanıcıyı temsil etmez. Kurumsal ağlar, mobil operatörlerin CGNAT altyapıları ve bazı proxy hizmetleri nedeniyle çok sayıda kullanıcı aynı genel IP adresini paylaşabilir.
Bu durumda IP bazlı kural, kötü amaçlı trafik bulunmasa bile meşru kullanıcıları etkileyebilir.
Kullanıcı veya API anahtarına göre sınırlama
Kimlik doğrulaması yapılan uygulamalarda sınırlar kullanıcı hesabına, API anahtarına veya belirli bir erişim belirtecine göre uygulanabilir.
Bu yaklaşım, aynı IP adresini paylaşan kullanıcıların birbirinden ayrılmasına yardımcı olur.
Bununla birlikte API anahtarının istemci tarafında açık edilmesi veya farklı sistemlerde kontrolsüz paylaşılması, beklenmedik kota tüketimine neden olabilir.
Uç nokta bazlı sınırlama
Bütün API uç noktalarının aynı maliyete sahip olması beklenmez.
Basit bir durum kontrolü ile büyük bir rapor oluşturan sorgu farklı miktarda işlemci, bellek ve veritabanı kaynağı tüketebilir.
Bu nedenle uygulamalar belirli uç noktalara ayrı limitler uygulayabilir.
Örneğin arama, raporlama ve oturum açma işlemleri için farklı eşikler belirlenebilir.
429 Hatası Neden Oluşur?
429 hatasının birden fazla olası nedeni vardır. Hatanın hangi koşullarda ortaya çıktığı, teşhis sürecinde önemli ipuçları sağlar.
Çok sık API isteği gönderilmesi
Bir uygulama, API yanıtını beklemeden aynı isteği tekrar tekrar gönderiyor olabilir.
Özellikle kısa aralıklı sorgulama döngüleri, hatalı yeniden deneme mekanizmaları veya paralel çalışan işçiler API kotalarını hızla tüketebilir.
Otomasyon veya bot trafiği
Arama motoru tarayıcıları, izleme sistemleri, veri toplama araçları ve otomatik test yazılımları kısa sürede yüksek istek hacmi oluşturabilir.
Ancak bütün otomasyon trafiği zararlı değildir. İsteklerin kaynağı ve amacı incelenmeden tüm botların engellenmesi doğru bir yaklaşım olmaz.
Yanlış yapılandırılmış CDN veya WAF kuralı
Bir CDN üzerinde tanımlanan rate limiting kuralı, normal kullanıcı davranışlarını da sınırlıyor olabilir.
Örneğin sayfa açılırken çok sayıda API isteği gönderen bir uygulamada, gereğinden düşük eşik nedeniyle kullanıcılar 429 yanıtlarıyla karşılaşabilir.
Paylaşılan IP adresleri
Aynı genel IP adresinden gelen farklı kullanıcıların istekleri tek sayaçta toplanıyorsa, bir kullanıcının yoğun trafiği diğerlerini etkileyebilir.
Bu durum özellikle büyük kurumsal ağlarda veya NAT kullanılan ortamlarda dikkate alınmalıdır.
Hatalı yeniden deneme döngüsü
429 yanıtı alan bir istemci, beklemeden aynı isteği tekrar gönderirse sorun büyüyebilir.
Birden fazla istemcinin aynı anda yeniden deneme yapması, sistem üzerinde ek yük oluşturabilir.
Bu nedenle 429 hatasına verilen otomatik tepki, hatanın kendisi kadar önemlidir.
429 Hatası ile Diğer HTTP Hataları Arasındaki Fark
429 hatasını doğru çözmek için benzer görünen durum kodlarından ayırmak gerekir.
| HTTP kodu | Anlamı | Tipik neden |
|---|---|---|
| 400 Bad Request | İstek geçersiz veya işlenemiyor | Hatalı istek biçimi |
| 403 Forbidden | Erişim reddedildi | Yetki veya güvenlik politikası |
| 429 Too Many Requests | İstek sınırı aşıldı | Rate limiting veya kota |
| 500 Internal Server Error | Sunucu isteği işlerken hata oluştu | Uygulama veya sunucu hatası |
| 503 Service Unavailable | Hizmet geçici olarak kullanılamıyor | Bakım, aşırı yük veya başka geçici durum |
Örneğin 400 Bad Request hatası genellikle isteğin yapısı veya içeriğiyle ilişkilidir. 429 ise geçerli bir isteğin belirlenen kullanım sınırına takılmasıyla oluşabilir.
503 Service Unavailable hatası ile 429 arasındaki ayrım da önemlidir. 503 genel hizmet kullanılabilirliğiyle ilişkiliyken 429 istemciye uygulanan istek sınırlamasını ifade eder.
Ancak kullanılan yazılımın varsayılan davranışı nedeniyle rate limiting sonucunda 503 dönmesi de mümkündür. Bu nedenle yalnızca HTTP koduna bakarak kök neden kesinleştirilmemelidir.
Retry-After Başlığı Nedir?
Retry-After, sunucunun istemciye yeniden istek göndermeden önce ne kadar beklemesi gerektiğini bildirebildiği HTTP yanıt başlığıdır.
Örnek:
HTTP/1.1 429 Too Many Requests
Retry-After: 60Bu örnekte istemciye 60 saniye beklemesi önerilir.
Retry-After değeri saniye cinsinden bir gecikme veya HTTP tarih biçiminde olabilir.
Ancak her 429 yanıtında bu başlığın bulunması zorunlu değildir. Bazı uygulamalar kendi kota başlıklarını veya JSON hata alanlarını kullanır.
Başlığın bulunmadığı durumlarda istemci, servis sağlayıcısının dokümantasyonuna ve kontrollü yeniden deneme politikasına göre davranmalıdır.
Exponential Backoff Nedir?
Exponential backoff, başarısız isteklerden sonra yeniden deneme aralığının kademeli olarak artırılmasıdır.
Örneğin bir istemci ilk başarısızlıktan sonra kısa süre bekleyip sonraki başarısızlıklarda daha uzun aralıklar kullanabilir.
Bu yaklaşım, aynı isteğin sürekli tekrarlanmasını önlemeye yardımcı olur.
Birden fazla istemcinin aynı anda yeniden deneme yapmasını azaltmak için rastgele gecikme anlamına gelen jitter da kullanılabilir.
Bununla birlikte bütün HTTP işlemleri güvenli şekilde tekrar edilemez.
Ödeme oluşturma, sipariş kaydetme veya başka yan etki oluşturan işlemler, sunucu tarafında idempotency desteği bulunmadan otomatik olarak yeniden gönderilmemelidir.
429 Hatası Kullanıcı Tarafında Nasıl Çözülür?
Bir web sitesini ziyaret ederken 429 hatası görülüyorsa ilk aşamada sunucu yapılandırmasına müdahale etmek gerekmez.
1. Kısa süre bekleyin
Hata geçici rate limiting nedeniyle oluşmuş olabilir.
Yanıtta Retry-After bilgisi bulunuyorsa belirtilen süreye uyulmalıdır.
2. Sayfayı sürekli yenilemeyin
Arka arkaya yenileme yapmak yeni HTTP istekleri oluşturur.
Bu davranış, rate limiting sayacının yeniden dolmasına ve erişim süresinin uzamasına neden olabilir.
3. Tarayıcı eklentilerini kontrol edin
Bazı tarayıcı eklentileri veya otomasyon araçları arka planda ek istekler gönderebilir.
Sorun yalnızca belirli tarayıcı profilinde görülüyorsa eklentiler kontrollü biçimde incelenebilir.
4. Farklı ağdan test edin
Farklı ağdan erişim mümkünken aynı ağdan sürekli 429 alınıyorsa IP bazlı sınırlama olasılığı değerlendirilebilir.
Ancak bu testin sonucu tek başına kesin kanıt değildir. Oturum, hesap ve CDN kuralları da farklı davranışlara neden olabilir.
5. Site yöneticisine bilgi verin
Hata uzun süre devam ediyorsa zaman, istenen URL ve mümkünse HTTP durum kodu site yöneticisine iletilmelidir.
API anahtarları, oturum çerezleri ve kimlik doğrulama belirteçleri destek taleplerinde açık biçimde paylaşılmamalıdır.
curl ile HTTP 429 Hatası Nasıl Kontrol Edilir?
Sunucu veya uygulama yöneticileri gerçek HTTP yanıtını curl aracılığıyla inceleyebilir.
Örneğin:
curl -I https://example.com/Bu komut HEAD isteği gönderir ve yanıt başlıklarını görüntüler.
Ancak bazı uygulamalar HEAD ve GET isteklerine farklı yanıt verebilir.
GET isteğinin yanıt başlıklarını incelemek için:
curl -sS -D - -o /dev/null https://example.com/Bu komut, yanıt başlıklarını gösterirken gövdeyi çıktı olarak yazdırmaz.
İncelenmesi gereken bilgiler arasında HTTP durum kodu, Retry-After, varsa rate limit başlıkları ve CDN tarafından eklenen tanılama bilgileri bulunur.
Tek bir GET isteği bile uygulama tarafından işlem olarak sayılabileceğinden testler kontrollü yapılmalıdır. Özellikle ücretli veya yan etkili API uç noktalarında rastgele deneme yapılmamalıdır.
Cloudflare 429 Hatası Nasıl Çözülür?
Cloudflare kullanılan bir web sitesinde 429 yanıtı, Cloudflare’ın rate limiting kurallarından veya kaynak sunucudan gelebilir.
Cloudflare’ın 429 hata dokümantasyonu bu durumun istek sınırlarının aşılmasıyla ilişkisini açıklar.
Ancak yanıtın Cloudflare üzerinden gelmesi, 429 kararının mutlaka Cloudflare tarafından verildiğini göstermez.
Rate limiting kurallarını inceleyin
Cloudflare yönetim panelinde ilgili alan adının güvenlik ve WAF yapılandırması kontrol edilmelidir.
Özellikle şu noktalar değerlendirilmelidir:
- Hangi URL veya HTTP metodunun kuralla eşleştiği
- Hangi istemcilerin etkilendiği
- Sayaçların IP, oturum veya başka bir özellik üzerinden tutulduğu
- Uygulanan eşik ve değerlendirme süresi
- Kuralın engelleme, meydan okuma veya başka bir eylem uygulayıp uygulamadığı
Cloudflare’ın rate limiting parametreleri belgesi bu ayarların teknik kapsamını açıklar.
Güvenlik olaylarını inceleyin
İlgili zaman aralığındaki güvenlik olayları ve rate limiting analitikleri incelenmelidir.
Hata yalnızca belirli bir URL’de oluşuyorsa kural kapsamı gereğinden geniş olabilir.
Örneğin yalnızca oturum açma uç noktasını sınırlamak amaçlanırken bütün web sitesine uygulanan bir kural, normal sayfa ziyaretlerini de etkileyebilir.
Rate limit kuralını tamamen kapatmak doğru mu?
Genellikle ilk çözüm olmamalıdır.
Bir kural yanlış pozitif üretiyorsa kapsamı daraltmak, eşik değerini gözden geçirmek veya doğrulanmış meşru trafiğe uygun istisna tanımlamak daha kontrollü olabilir.
Güvenlik kuralının tamamen kaldırılması, başlangıçta önlenmek istenen kötüye kullanım riskini yeniden ortaya çıkarabilir.
Nginx Üzerinde 429 Hatası Nasıl Yönetilir?
Nginx, ngx_http_limit_req_module aracılığıyla HTTP istek hızını sınırlandırabilir.
Bu modül, belirlenen anahtara göre isteklerin işlenme hızını kontrol eder.
Nginx’in resmî limit_req modülü dokümantasyonu yapılandırma yönergelerini ve çalışma biçimini açıklar.
Nginx rate limiting örneği
Aşağıdaki örnek, ilgili modülün bulunduğu ve yapılandırma yetkisi olan Nginx ortamları içindir:
http {
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;
server {
location /api/ {
limit_req zone=api_limit burst=10 nodelay;
limit_req_status 429;
proxy_pass http://backend;
}
}
}Bu örnekte backend, önceden tanımlanmış ve erişilebilir bir upstream hedefini temsil eder. Yapılandırma doğrudan kullanılmadan önce gerçek uygulama mimarisine uyarlanmalıdır.
Yönergelerin anlamları:
limit_req_zone, isteklerin hangi anahtara göre sayılacağını ve paylaşımlı bellek alanını tanımlar.$binary_remote_addr, istemci IP adresini anahtar olarak kullanır.rate=5r/s, ortalama istek işleme hızını saniyede beş istek olarak belirler.burst=10, kısa süreli istek artışlarının nasıl ele alınacağını etkiler.nodelay, izin verilen ani artış kapsamındaki isteklerin bekletilmeden işlenmesini sağlar.limit_req_status 429, sınır aşıldığında döndürülecek durum kodunu 429 olarak ayarlar.
Bu değerler yalnızca yapılandırma örneğidir. Üretim ortamına uygun eşikler, gerçek trafik ve uygulama davranışı incelenmeden belirlenmemelidir.
Önemli: Nginx limit_req modülünün varsayılan ret durum kodu 503’tür. 429 yanıtı isteniyorsa limit_req_status 429 gibi açık bir yapılandırma gerekir.
Reverse proxy arkasında IP adresi nasıl değerlendirilir?
Nginx bir CDN veya yük dengeleyicinin arkasında çalışıyorsa $remote_addr doğrudan son kullanıcı IP adresi yerine proxy adresini temsil edebilir.
Bu durumda bütün kullanıcıların istekleri tek anahtarda toplanabilir.
Gerçek istemci IP adresinin doğru belirlenmesi için güvenilir proxy listeleri ve uygun gerçek IP yapılandırması kullanılmalıdır.
İstemcinin kontrol edebildiği herhangi bir X-Forwarded-For değerine koşulsuz güvenmek güvenlik riski oluşturur.
Nginx yapılandırmasını güvenli şekilde test edin
Yapılandırma değişikliği yapılmadan önce mevcut dosyaların yedeği alınmalıdır.
Ardından sözdizimi kontrolü:
sudo nginx -tKomut başarılı sonuç verirse uygun bakım prosedürü kapsamında yapılandırma yeniden yüklenebilir:
sudo systemctl reload nginxBu ikinci komut canlı servisin yapılandırmasını yeniden yükler. Üretim ortamında yetkili yönetici tarafından uygulanmalıdır.
Değişiklikten sonra erişim günlükleri, hata kayıtları ve uygulama işlevleri kontrol edilmelidir.
Dry Run ile kuralı önceden değerlendirme
Desteklenen Nginx sürümlerinde limit_req_dry_run kullanılabilir.
limit_req_dry_run on;Bu mod, rate limiting hesaplamalarının gerçek istekleri engellemeden değerlendirilmesine yardımcı olur.
Özellikle yeni bir kuralın normal kullanıcı trafiğini ne ölçüde etkileyeceğini anlamak için yararlıdır.
Test sonrasında kuralın üretim ortamında nasıl uygulanacağına bilinçli olarak karar verilmelidir.
API İstemcilerinde 429 Hatası Nasıl Önlenir?
429 hatasının kalıcı çözümü çoğu zaman yalnızca sunucu tarafında değildir.
API istemcisinin istekleri nasıl planladığı da değerlendirilmelidir.
Gereksiz tekrarları azaltın
Aynı veriyi kısa aralıklarla tekrar istemek yerine uygun durumlarda önbellekleme kullanılabilir.
Örneğin sık değişmeyen bir kaynak için her sayfa açılışında yeni API isteği göndermek gereksiz olabilir.
İstekleri sıraya alın
Birden fazla arka plan çalışanı aynı API anahtarını kullanıyorsa toplam istek sayısı merkezi olarak kontrol edilmelidir.
Aksi halde her çalışan kendi sınırının altında kalsa bile ortak API kotası aşılabilir.
Retry-After değerine uyun
429 yanıtında Retry-After varsa istemci yeniden deneme zamanını buna göre planlamalıdır.
Başlık bulunmadığında sınırsız tekrar döngüsü yerine üst sınırı belirlenmiş exponential backoff kullanılabilir.
İdempotency gerektiren işlemlere dikkat edin
Veri okuma amaçlı bir GET isteğiyle ödeme oluşturan POST isteği aynı şekilde ele alınmamalıdır.
Yan etkili işlemlerde tekrar gönderim, yinelenen işlem oluşturabilir.
Bu nedenle API sağlayıcısının idempotency mekanizması ve yeniden deneme kuralları kontrol edilmelidir.
API kotasını izleyin
Uygulama mümkünse toplam istek sayısını, 429 oranını, bekleme sürelerini ve en çok kota tüketen uç noktaları izlemelidir.
Böylece sorun kullanıcıları etkilemeden önce olağan dışı istek davranışları tespit edilebilir.
WordPress Sitelerinde 429 Hatası
WordPress sitelerinde 429 hatası farklı kaynaklardan oluşabilir.
Örneğin bir güvenlik eklentisi, CDN kuralı veya hosting altyapısındaki istek sınırı belirli URL’leri etkileyebilir.
WordPress REST API üzerinden çok sayıda istek gönderen eklentiler veya harici entegrasyonlar da rate limiting ile karşılaşabilir.
Bu durumda ilk adım bütün eklentileri kapatmak değildir.
Öncelikle hatanın hangi URL’de oluştuğu, hangi eklentinin ilgili isteği yaptığı ve yanıtın hangi katmandan geldiği araştırılmalıdır.
Özellikle wp-json uç noktalarında görülen 429 yanıtları, REST API trafiğinin sıklığı ve güvenlik kuralları açısından incelenmelidir.
Bir eklentinin gereksiz yere çok sık istek gönderdiği doğrulanırsa ilgili eklentinin ayarları veya güncelleme durumu kontrol edilebilir.
429 Hatası ile DDoS Koruması Arasındaki İlişki
Rate limiting, uygulama katmanındaki bazı kötüye kullanım davranışlarını sınırlamak için kullanılabilir.
Örneğin kısa süre içinde çok sayıda oturum açma isteği gönderen bir istemci, güvenlik kuralıyla geçici olarak engellenebilir.
Ancak 429 yanıtı tek başına DDoS saldırısının kanıtı değildir.
Normal kullanıcıların aynı IP adresini paylaşması veya hatalı bir uygulamanın fazla istek göndermesi de aynı sonucu oluşturabilir.
Hostider’ın Layer 7 DDoS ve WAF koruması, HTTP trafiğinin güvenlik açısından değerlendirilmesiyle ilgili ayrı bir hizmet alanıdır.
Rate limiting, WAF ve DDoS koruması birbiriyle ilişkili olsa da aynı mekanizmalar değildir.
Rate limiting istek sıklığını kontrol ederken WAF belirli HTTP isteklerini güvenlik kurallarına göre değerlendirebilir. DDoS koruması ise saldırı trafiğinin etkilerini azaltmaya yönelik daha geniş bir savunma mimarisi gerektirebilir.
429 Hatasını Günlük Kayıtlarıyla Teşhis Etme
Sunucu yöneticisinin yanıtlaması gereken temel soru, 429 yanıtını hangi bileşenin oluşturduğudur.
İstek zinciri örneğin şu şekilde olabilir:
Tarayıcı → CDN → Nginx → Uygulama → API servisi
Bu zincirin herhangi bir katmanında sınırlama uygulanabilir.
Nginx erişim kayıtlarını inceleme
Linux üzerinde Nginx kullanılan bazı sistemlerde erişim kayıtları /var/log/nginx/access.log dosyasında bulunur.
Örneğin:
sudo grep ' 429 ' /var/log/nginx/access.logBu komut, varsayılan birleşik günlük biçimine benzer formatlarda 429 kayıtlarını aramak için kullanılabilir.
Ancak özel log formatlarında sonuç vermeyebilir. Ayrıca tüm sistemlerde günlük dosyası aynı konumda bulunmaz.
Kayıtlarda isteğin zamanı, istemci IP adresi, URL, HTTP metodu ve varsa upstream durum kodu incelenmelidir.
Uygulama günlüklerini karşılaştırma
429 yanıtı Nginx kayıtlarında görünürken uygulama kayıtlarında aynı istek yoksa, istek uygulamaya ulaşmadan engellenmiş olabilir.
Buna karşılık uygulama günlüklerinde 429 yanıtı üretiliyorsa sınırlama uygulama veya API katmanında gerçekleşiyor olabilir.
Ancak proxy ve uygulama kayıtlarının farklı zaman dilimlerinde tutulması eşleştirmeyi zorlaştırabilir.
Bu nedenle mümkünse istek kimlikleri ve tutarlı zaman damgaları kullanılmalıdır.
429 Hatasını Çözerken Yapılmaması Gerekenler
Yanlış müdahaleler rate limiting sorununu geçici olarak gizlerken güvenlik risklerini artırabilir.
Özellikle nedenini belirlemeden bütün rate limit kurallarını kapatmak, API istemcilerini sürekli yeniden denemeye zorlamak, CDN güvenlik kurallarını topluca devre dışı bırakmak veya yalnızca hata kodunu değiştirmek kalıcı çözüm değildir.
Benzer şekilde yönlendirme döngüsü hatası ile 429 aynı sorun değildir. Tekrarlanan yönlendirmeler istek sayısını artırabilse de HTTP yönlendirme hatasının kök nedeni ayrı incelenmelidir.
Doğru yaklaşım, önce sınırlamayı uygulayan katmanı bulmak, ardından kuralın kapsamını ve gerçek trafik davranışını değerlendirmektir.
429 Hatası İçin Güvenli Geri Dönüş Planı
Üretim ortamında rate limiting yapılandırması değiştirilmeden önce mevcut kurallar kaydedilmelidir.
Nginx üzerinde yapılan değişikliklerde önceki çalışan yapılandırma korunmalı, sözdizimi testi yapılmalı ve değişiklik sonrasında günlükler izlenmelidir.
Yeni bir kural normal kullanıcıları etkiliyorsa önceki eşik veya kural kapsamına dönülebilir.
CDN üzerinde yapılan değişikliklerde de önceki kural tanımları ve güvenlik eylemleri kayıt altına alınmalıdır.
Ancak güvenlik kuralını geri almak, bütün istemcilerin anında erişim kazanacağını garanti etmez. Uygulama düzeyindeki sayaçlar, başka güvenlik katmanları veya servis sağlayıcısının kota politikaları etkisini sürdürebilir.
Sıkça Sorulan Sorular
429 hatası kalıcı mıdır?
Çoğu rate limiting uygulamasında sınırlama geçicidir. Ancak hatalı istemci davranışı devam ediyorsa 429 yanıtı tekrar oluşabilir.
429 hatası sunucunun çöktüğünü mü gösterir?
Hayır. Sunucu çalışır durumda olsa bile istek sınırı nedeniyle 429 döndürebilir.
429 hatasında IP değiştirmek çözüm müdür?
IP değişikliği bazı IP bazlı sınırlamalarda farklı sonuç oluşturabilir. Ancak bu, kök nedeni çözmez ve hizmet sağlayıcısının kullanım sınırlarını aşmak için uygulanmamalıdır.
Cloudflare 429 hatası her zaman Cloudflare kaynaklı mıdır?
Hayır. Kaynak sunucu veya uygulama tarafından üretilen 429 yanıtı da Cloudflare üzerinden istemciye iletilebilir.
Nginx varsayılan olarak 429 mu döndürür?
Hayır. Nginx limit_req modülünün varsayılan ret kodu 503’tür. 429 için uygun limit_req_status yapılandırması gerekir.
429 hatası SEO’yu etkiler mi?
Arama motoru tarayıcıları önemli sayfalara sürekli 429 yanıtı alıyorsa tarama ve erişilebilirlik sorunları oluşabilir. Ancak tek bir 429 yanıtından doğrudan sıralama kaybı sonucu çıkarılamaz.
Sonuç
429 Too Many Requests, web uygulamalarında istek hızını ve kaynak kullanımını kontrol etmek için kullanılan sınırlama mekanizmalarının üretebildiği HTTP durum kodudur.
Hatanın çözümü, yalnızca daha yüksek istek sınırı tanımlamak değildir. API istemcisinin davranışı, CDN kuralları, web sunucusu yapılandırması ve uygulama düzeyindeki kotalar birlikte değerlendirilmelidir.
Özellikle Retry-After başlığına uyulması, kontrollü yeniden deneme mekanizmalarının kullanılması ve Nginx veya CDN kurallarının gerçek trafik verilerine göre ayarlanması önemlidir.
Kalıcı ve güvenli çözüm, meşru trafiği gereksiz yere engellemeden kötüye kullanımı sınırlayan, izlenebilir ve gerektiğinde geri alınabilir bir rate limiting mimarisi oluşturmaktır.
