429 Çok Fazla İstek Hatası Nasıl Çözülür

429 Too Many Requests hatası, RFC 6585’te tanımlanan ve bir istemcinin sunucu veya aracı proxy tarafından uygulanan hız sınırını aştığını bildiren bir HTTP durum kodudur. Sunucu, hız sınırlama penceresi sıfırlanana kadar daha fazla isteği reddeder ve isteğe bağlı olarak istemcinin ne kadar beklemesi gerektiğini belirten bir Retry-After başlığı döndürür.

Sunucu tarafı kapasite hatasını yansıtan 503 Service Unavailable hatasının aksine, 429 kasıtlı, politika odaklı bir reddedir. Bu ayrımı anlamak kritik önem taşır: çözüm her zaman altyapıyı ölçeklendirmekle ilgili değildir — çok fazla istek gönderen *kimin* olduğunu, *neden* gönderdiğini belirlemek ve ardından yığının doğru katmanında davranışı düzeltmekle ilgilidir.

429 Hatasına Gerçekte Ne Sebep Olur

Hata birden fazla katmanda ortaya çıkar ve bunları birbirine karıştırmak yanlış teşhise yol açar. Temel neden dört kategoriden birine girer:

• Sunucu tarafı hız sınırlama — Web sunucuları (Apache, Nginx), ters proxy’ler (HAProxy, Varnish) veya CDN edge düğümleri (Cloudflare, Fastly) IP başına veya token başına istek eşikleri uygular.
• Uygulama katmanı kısıtlama — WordPress eklentileri, özel ara yazılımlar veya API ağ geçitleri, web sunucusundan bağımsız olarak kendi sınırlarını uygular.
• Üçüncü taraf API kota tükenmesi — Uygulamanız harici bir API’yi (Google Maps, Stripe, OpenAI) sağlayıcının kotasının izin verdiğinden daha hızlı çağırır ve 429 son kullanıcıya geri yayılır.
• Kötü amaçlı veya kontrolsüz otomatik trafik — Kaba kuvvet giriş denemeleri, agresif tarayıcılar, yanlış yapılandırılmış izleme betikleri veya kötü yazılmış gezginler istek bütçelerini doldurur.

Sıkça gözden kaçan bir uç durum: komşu bir kiracının trafik artışının paylaşılan bağlantı havuzlarını tükettiği paylaşımlı barındırma ortamları; bu durum, kendi kodunuz düzgün çalışıyor olsa bile uygulamanızın yukarı akış yük dengeleyicisinden 429 yanıtları almasına neden olur. Bir Paylaşımlı Web Barındırma planındaysanız ve kendi trafiğinizde karşılık gelen bir artış olmaksızın aralıklı 429 patlamaları görüyorsanız, test edilecek ilk hipotez budur.

Adım 1: Aşırı İsteklerin Kaynağını Belirleyin

Kaynağını belirlemeden 429’u düzeltmek tahmin yürütmektir. Verilerle başlayın.

Apache Erişim Günlüklerini Okuma

grep " 429 " /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Bu komut her 429 yanıtını çıkarır, IP adresi başına oluşumları sayar ve sıralar. Dakikalar içinde binlerce kez görünen bir IP ya bir bot, yanlış yapılandırılmış bir betik ya da bir saldırgandır.

Nginx Erişim Günlüklerini Okuma

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

İstek Yollarıyla İlişkilendirme

grep " 429 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Çıktıda /wp-login.php veya /xmlrpc.php baskınsa, kaba kuvvet veya kimlik bilgisi doldurma saldırısıyla karşı karşıyasınız demektir. /api/v1/search gibi bir API uç noktası listenin başındaysa, suçlu muhtemelen yanlış yapılandırılmış bir istemci veya tarayıcıdır.

Kalıpları Ortaya Çıkarmak için fail2ban Kullanımı

fail2ban-client status
fail2ban-client status nginx-req-limit

fail2ban, nginx-req-limit jail ile yapılandırılmışsa, hız sınırı ihlalleri nedeniyle hangi IP’lerin yasaklandığını tam olarak gösterir ve önemli miktarda günlük ayrıştırma süresinden tasarruf sağlar.

Adım 2: Web Sunucusu Düzeyinde Hız Sınırlamayı Yapılandırın

Apache: mod_ratelimit ve mod_evasive Kullanımı

Çevrimiçinde yaygın olarak dolaşan .htaccess kod parçacığı, uygun bir 429 yerine 403 döndürmek için mod_rewrite kullanır. DoS azaltma için mod_evasive kullanan daha anlamsal açıdan doğru ve operasyonel olarak sağlam bir yaklaşım tercih edilmelidir.

Debian/Ubuntu’da mod_evasive kurun ve yapılandırın:

apt install libapache2-mod-evasive
a2enmod evasive

Ardından Apache sanal ana bilgisayarınıza veya genel yapılandırmanıza ekleyin:

<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10
    DOSEmailNotify      admin@yourdomain.com
    DOSLogDir           /var/log/mod_evasive
</IfModule>

Bu, aynı sayfaya saniyede 5’ten fazla veya tüm siteye saniyede 50’den fazla isyan gönderen herhangi bir IP’yi 10 saniyelik soğuma süresi için engeller.

Apache’de mod_rewrite ile .htaccess aracılığıyla uygun bir 429 yanıtı için özel bir hata belgesi gerekir:

ErrorDocument 429 "Too Many Requests"

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} ^.*(SemrushBot|AhrefsBot|MJ12bot|DotBot).*$ [NC]
    RewriteRule .* - [R=429,L]
</IfModule>

Nginx: Uygun Patlama İşlemiyle limit_req_zone

Nginx’in ngx_http_limit_req_module‘i mevcut en etkili hız sınırlama araçlarından biridir. Sıkça yanlış yapılandırılan temel parametreler burst ve nodelay‘dir.

/etc/nginx/nginx.conf veya özel bir dahil etme dosyasında:

http {
    # Zone keyed by client IP, 10MB shared memory, 10 requests/second baseline
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

    # Return 429 instead of the default 503
    limit_req_status 429;

    server {
        location /api/ {
            limit_req zone=api_limit burst=20 nodelay;
        }

        location /wp-login.php {
            limit_req zone=login_limit burst=3 nodelay;
        }
    }
}

Kritik nüans: limit_req_status 429 olmadan, Nginx varsayılan olarak hız sınırlı istekler için 503 döndürür. Bunu 429 olarak ayarlamak anlamsal açıdan doğrudur ve istemcilerin uygun Retry-After geri çekilme mantığı uygulamasına olanak tanır.

nodelay ile bayrak yok karşılaştırması:

• nodelay olmadan: fazla istekler kuyruğa alınır ve eklenen gecikmeyle sunulur, çalışan bağlantıları tüketir.
• nodelay ile: patlama sınırını aşan fazla istekler hemen 429 ile reddedilir, kaynakları daha hızlı serbest bırakır. Giriş uç noktaları ve genel API’ler için nodelay kullanın.

Retry-After Başlığı Ekleme

RFC 6585’e uyan istemciler bir Retry-After başlığını dikkate alır. Nginx’te bunu hata yanıtına ekleyin:

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    add_header Retry-After 60 always;
}

Adım 3: WordPress Eklenti Çakışmalarını Teşhis Edin ve Düzeltin

WordPress, kendi kendine neden olunan 429 hatalarının yaygın bir kaynağıdır. Her sayfa yüklemesinde harici API’leri sorgulayan eklentiler — anahtar kelime verisi çeken SEO araçları, ana sunucuya çağrı yapan analitik eklentileri veya ödeme ağ geçitlerini sorgulayan WooCommerce uzantıları — hız sınırlarını hızla tüketebilir.

Sistematik izolasyon prosedürü:

1. Tüm eklentileri WordPress kontrol paneli aracılığıyla veya kontrol paneline erişilemiyorsa WP-CLI aracılığıyla devre dışı bırakın:

wp plugin deactivate --all

1. Eklentileri tek tek yeniden etkinleştirin, her etkinleştirmeden sonra test edin:

wp plugin activate plugin-slug

1. Yeniden etkinleştirirken ayrı bir terminalde erişim günlüğünü izleyin:

tail -f /var/log/nginx/access.log | grep " 429 "

1. Sorunlu eklenti belirlendikten sonra, kalıcı olarak devre dışı bırakmadan önce API yoklama aralıkları veya istek sıklığı seçenekleri için ayarlarını kontrol edin.

Yaygın suçlular: Jetpack (istatistik ve senkronizasyon modülleri), Yoast SEO (MyYoast’a bağlıyken), WooCommerce Subscriptions ve geçici önbelleğe alma olmadan döngü içinde WordPress’in yerleşik wp_remote_get()‘ını kullanan herhangi bir eklenti.

Doğru çözüm neredeyse hiçbir zaman eklentiyi kaldırmak değildir — WordPress geçicilerini kullanarak API yanıtlarının önbelleğe alındığından emin olmaktır:

$cached = get_transient( 'my_api_response' );
if ( false === $cached ) {
    $response = wp_remote_get( 'https://api.example.com/data' );
    set_transient( 'my_api_response', $response, HOUR_IN_SECONDS );
    $cached = $response;
}

Adım 4: Uygulama Kodunda API İstek Kısıtlamasını Uygulayın

Uygulamanız üçüncü taraf bir API’ye istek gönderen *istemci* olduğunda, hız sınırlarına uymak sizin sorumluluğunuzdadır. 429 yanıtlarını reaktif olarak yakalamaya güvenmek kötü mühendisliktir — proaktif kısıtlama uygulayın.

p-throttle ile Node.js

import pThrottle from 'p-throttle';

const throttle = pThrottle({
    limit: 10,       // max 10 calls
    interval: 1000   // per 1000ms (1 second)
});

const throttledFetch = throttle(async (url) => {
    const response = await fetch(url);
    return response.json();
});

Üstel Geri Çekilme için tenacity ile Python

API patlama sınırları uyguluyorsa kısıtlama tek başına yetersizdir. Kısıtlamayı 429 yanıtlarında üstel geri çekilmeyle birleştirin:

import requests
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception

def is_rate_limited(exception):
    return (
        isinstance(exception, requests.HTTPError)
        and exception.response.status_code == 429
    )

@retry(
    retry=retry_if_exception(is_rate_limited),
    wait=wait_exponential(multiplier=1, min=2, max=60),
    stop=stop_after_attempt(5)
)
def call_api(url):
    response = requests.get(url)
    response.raise_for_status()
    return response.json()

Bu, 60 saniye ile sınırlı üstel geri çekilmeyle (2s, 4s, 8s, 16s, 32s) 5 kez yeniden dener — API sağlayıcısının altyapısına saygı gösterirken zarif bir şekilde kurtaran bir kalıp.

Retry-After Başlığına Uymak

API bir Retry-After başlığı döndürüyorsa, sabit bir geri çekilme yerine bunu kullanın:

def call_with_retry_after(url):
    response = requests.get(url)
    if response.status_code == 429:
        retry_after = int(response.headers.get("Retry-After", 5))
        time.sleep(retry_after)
        return call_with_retry_after(url)
    response.raise_for_status()
    return response.json()

Adım 5: Botları Birden Fazla Katmanda Engelleyin ve Yönetin

Botlar kendilerini nadiren dürüstçe tanıtır, ancak kullanıcı aracısı dizelerinde, istek kalıplarında ve başlık anomalilerinde parmak izleri bırakırlar.

Nginx’te Bilinen Kötü Botları Engelleme

map $http_user_agent $bad_bot {
    default         0;
    ~*SemrushBot    1;
    ~*AhrefsBot     1;
    ~*MJ12bot       1;
    ~*DotBot        1;
    ~*PetalBot      1;
    ~*serpstatbot   1;
}

server {
    if ($bad_bot) {
        return 429;
    }
}

robots.txt Aracılığıyla Tarama Hızını Yönetme

User-agent: Googlebot
Crawl-delay: 2

User-agent: *
Crawl-delay: 10

Crawl-delay‘ın tüm tarayıcılar tarafından dikkate alınmadığını, ancak niyeti bildirdiğini ve Bing, Yandex ile çoğu iyi davranışlı bot tarafından saygı gördüğünü unutmayın.

Web Uygulama Güvenlik Duvarı (WAF) Entegrasyonu

CDN edge’inde çalışan bir WAF (Cloudflare, AWS WAF, Sucuri), trafik kaynak sunucunuza ulaşmadan önce hız sınırlarını uygulayabilir ve yükü önemli ölçüde azaltır. Cloudflare’in Hız Sınırlama kuralları, örneğin, kaynak sunucu yapılandırmanızda herhangi bir değişiklik yapmadan bir eşiği aşan IP’leri sorgulamak veya engellemek üzere yapılandırılabilir — yüksek trafikli siteler için önemli bir operasyonel avantaj.

Adım 6: WordPress’te Güvenlik Eklentisi Ayarlarını Düzenleyin

Wordfence kullanıyorsanız, hız sınırlama eşikleri genellikle muhafazakâr olarak ayarlanmıştır ve özellikle yoğun AJAX kullanımı veya oturum açmış kullanıcı etkinliği olan sitelerde meşru kullanıcılar için yanlış pozitifleri tetikleyebilir.

Wordfence > Firewall > All Firewall Options > Rate Limiting bölümüne gidin ve şunları gözden geçirin:

• Google’ın tarayıcılarına nasıl davranmalıyız — SEO etkisini önlemek için “Doğrulanmış Google tarayıcıları hız sınırlamasına tabi değildir” olarak ayarlayın.
• Herhangi birinin istekleri aşarsa — eşiği varsayılandan artırın (örneğin, içerik ağırlıklı sitelerde oturum açmış kullanıcılar için dakikada 240’tan 480’e).
• Bir tarayıcının sayfa görüntülemeleri aşarsa — gerçek tarama bütçesi gereksinimlerinize göre ayarlayın.

Ayarladıktan sonra, meşru kullanıcıların artık engellenmediğini doğrulamak için 24-48 saat boyunca Wordfence Canlı Trafik görünümünü izleyin.

Adım 7: İstemci Tarafı Önbelleğini Temizleyin ve Tarayıcı Düzeyindeki Sorunları Teşhis Edin

Tarayıcıda önbelleğe alınmış bir 429 yanıtı, yanıt Cache-Control: max-age başlıkları içeriyorsa (bir sunucu yanlış yapılandırması) nadir de olsa mümkündür. Standart 429 yanıtları önbelleğe alınmamalıdır.

Chrome:

Settings > Privacy and Security > Clear browsing data

Önbelleğe alınmış görüntüler ve dosyalar ile Çerezler ve diğer site verileri‘ni seçin, ardından temizleyin.

Tarayıcıya özgü davranışı dışlamak için curl kullanarak yanıt başlıklarını doğrudan doğrulayın:

curl -I -X GET https://yourdomain.com/problematic-endpoint

Yanıtta Cache-Control, Retry-After ve X-RateLimit-* başlıklarını arayın. Bu başlıklar, sınırı hangi katmanın uyguladığını ve istemcinin ne zaman yeniden deneyebileceğini tam olarak ortaya koyar.

Karşılaştırma: Katmana Göre Hız Sınırlama Yaklaşımları

Barındırma Sağlayıcınızla Ne Zaman İletişime Geçilmeli

Aşağıdaki durumlarda barındırma sağlayıcınıza başvurun:

• 429, kontrol etmediğiniz bir yukarı akış yük dengeleyicisinden veya ters proxy’den kaynaklanıyorsa.
• Günlük analizi, uygulamanızın beklenen istek hacimleri dahilinde olduğunu gösteriyor ancak hata devam ediyorsa.
• Planlı bir trafik artışı (ürün lansmanı, pazarlama kampanyası) sırasında geçici bir hız sınırı muafiyetine ihtiyaç duyuyorsanız.
• Hata yalnızca belirli coğrafi bölgelerde görünüyorsa, bu CDN veya anycast yönlendirme sorunlarına işaret edebilir.

Bir VPS Barındırma planında çalışırken, sunucu yapılandırma dosyalarına doğrudan erişiminiz vardır ve yukarıda açıklanan tüm Nginx ve Apache değişikliklerini bir destek talebi açmadan uygulayabilirsiniz. Dedicated Sunucular gibi yönetilen altyapılarda, sağlayıcınızın destek ekibi uygulama katmanı yapılandırmasının ötesine geçen çekirdek düzeyinde bağlantı izleme ve donanım güvenlik duvarı kurallarında yardımcı olabilir.

Yığınınız bir kontrol paneli içeriyorsa, cPanel ile VPS, derin komut satırı uzmanlığı olmayan ekipler için yapılandırmayı basitleştiren bir GUI aracılığıyla ModSecurity ve Apache hız sınırlama ayarlarını sunar.

API Uç Noktalarını SSL ile Güvence Altına Alma

Sıkça gözden kaçan bir faktör: şifrelenmemiş HTTP uç noktaları, kaba kuvvet kaynaklı 429 hatalarını tetikleyen yeniden oynatma saldırılarına ve kimlik bilgisi doldurmaya karşı daha savunmasızdır. Geçerli bir SSL Sertifikası ile HTTPS’yi zorunlu kılmak, kimlik doğrulama tokenlarının ve oturum çerezlerinin otomatik araçlar tarafından ele geçirilip yeniden oynatılamamasını sağlar; böylece hız sınırını tetikleyen trafik kategorilerinden biri kaynağında azaltılmış olur.

Teknik Karar Matrisi: Doğru Çözümü Seçme

Teşhisinizi doğru çözüme yönlendirmek için bu kontrol listesini kullanın:

• /wp-login.php veya /xmlrpc.php üzerinde 429 — Bu yollar için Nginx limit_req‘ı güçlendirin, gerekli değilse xmlrpc.php‘ı tamamen engelleyin, Wordfence kaba kuvvet korumasını etkinleştirin.
• Kendi uygulama kodunuzdan API uç noktalarında 429 — Retry-After başlığı ayrıştırmasıyla üstel geri çekilme uygulayın; giden çağrı sıklığını azaltmak için geçici/Redis önbelleğe alma ekleyin.
• Paylaşımlı barındırmada tüm kullanıcıları aralıklı olarak etkileyen 429 — Yalıtılmış kaynaklar ve yapılandırılabilir hız sınırları için VPS’e geçin.
• Uygulamanızın tükettiği üçüncü taraf API’den 429 — Çağrı sıklığını denetleyin, istek kuyruğu uygulayın, yanıtları agresif biçimde önbelleğe alın ve kota artışlarını görüşmek için API sağlayıcısıyla iletişime geçin.
• Belirli bir bot veya tarayıcının neden olduğu 429 — Kullanıcı aracısına göre WAF veya Nginx map düzeyinde engelleyin; meşru tarayıcıları (Googlebot) engellemeden önce ters DNS ile doğrulayın.
• Yalnızca tarayıcıda görünen, curl‘da görünmeyen 429 — Tarayıcı önbelleğini temizleyin; hata yanıtını önbelleğe alan bir service worker olup olmadığını kontrol edin; 429 yanıtındaki Cache-Control başlıklarını inceleyin.
• Günlüklerde tanımlanabilir bir kalıp olmaksızın 429 — Yukarı akış CDN veya yük dengeleyici günlüklerini kontrol edin; sınır, uygulama günlüklerinde görünmeyen bir altyapı katmanında uygulanıyor olabilir.

SSS

429 ile 503 hatası arasındaki fark nedir?

429, bir istemci tanımlı istek hızını aştığında verilen kasıtlı, politika odaklı bir reddedir. 503, sunucunun aşırı yük veya bakım nedeniyle istekleri geçici olarak işleyemediğini gösterir. 429 için çözüm hız sınırı ayarlaması veya istemci davranışı düzeltmesidir; 503 için çözüm kapasite ölçeklendirme veya hizmet kurtarmadır.

429 gördüğümde her zaman hız sınırlarını artırmalı mıyım?

Hayır. Sınırları artırmak yalnızca meşru trafik engellendiğinde uygundur. 429 botlardan, kaba kuvvet girişimlerinden veya yanlış yapılandırılmış bir betikten kaynaklanıyorsa, sınırı yükseltmek daha fazla kötü amaçlı trafiğin geçmesine izin vererek sorunu daha da kötüleştirir. Her zaman önce kaynağı belirleyin.

Retry-After başlığı ne işe yarar ve her zaman dahil etmeli miyim?

Retry-After başlığı, istemciye yeniden denemeden önce kaç saniye beklemesi gerektiğini söyler. RFC 6585, her 429 yanıtına dahil edilmesini önerir. İyi davranışlı HTTP istemcileri ve API tüketicileri buna uyar; bu da orijinal hız sınırlama sorununu daha da kötüleştiren yeniden deneme fırtınalarını azaltır.

429 hatası SEO’mu etkiler mi?

Evet, Googlebot sürekli olarak 429 yanıtları alırsa siteniz için tarama sıklığını azaltır; bu da yeni veya güncellenmiş içeriğin dizine eklenmesini geciktirebilir. Wordfence ve benzeri eklentiler, doğrulanmış Google tarayıcılarını hız sınırlamasından muaf tutacak şekilde yapılandırılmalıdır. Sunucu hatalarındaki artışlar için Google Search Console’un Tarama İstatistikleri raporunu izleyin.

Kendi uygulamam harici API’lerde 429 hatalarını tetiklemekten nasıl kaçınır?

Proaktif kısıtlama (giden istek hızını API’nin belgelenmiş eşiğinin altında tutun), agresif yanıt önbelleğe alma (API sonuçlarını uygun TTL’lerle Redis veya Memcached’de saklayın) ve reaktif üstel geri çekilme (Retry-After başlıklarını ayrıştırın ve buna göre geri çekilin) kombinasyonunu uygulayın. Önünde bir önbelleğe alma katmanı olmadan her sayfa yüklemesinde eşzamanlı olarak API çağrısı yapmayın.