429 Too Many Requests Hatası Nedir, Nasıl Çözülür?

429 Too Many Requests hatası, sunucunun "belirli bir süre içinde çok fazla istek gönderdin, seni geçici olarak durduruyorum" demesidir. Çok fazla istek hatası olarak da bilinir ve tarayıcıda çıplak bir beyaz sayfada tek satır metin olarak görünür. Türkçe kaynakların neredeyse tamamı bu hatayı tek yönlü anlatır: "bekleyin, daha az istek atın, VPN'i kapatın." Bu tavsiye, hatayı alan taraf içindir ve doğrudur ama eksiktir.

Bu yazı asıl boşluğu kapatıyor: 429'u üreten taraf sizseniz ne yapacaksınız. Pratikte en sık gördüğüm senaryo, sitenin kendi gerçek ziyaretçilerinin engellenmesidir — Nginx limit_req bölgesi fazla dar ayarlanmıştır, cPHulk bir ofisin ortak IP'sini kilitlemiştir ya da Cloudflare Rate Limiting kuralı sayfa başına yüklenen 40 statik dosyayı 40 ayrı istek sayıp kuralı tetiklemiştir. Aşağıda önce hatanın kimden geldiğini kesin olarak ayırt etmeyi, sonra Nginx, cPanel, Cloudflare ve WordPress katmanlarında limiti doğru kurmayı, en sonda da API tüketicisi tarafındaki Retry-After davranışını anlatıyorum.

429 Too Many Requests Hatası Nedir#

429, RFC 6585 ile tanımlanmış bir HTTP durum kodudur ve "hız sınırlaması" anlamına gelir. 4xx ailesinde olduğu için sorumluluk teknik olarak istemciye atfedilir, ama bu her zaman istemcinin suçlu olduğu anlamına gelmez — çoğu zaman sunucudaki eşik yanlış ayarlanmıştır.

429 ile karıştırılan diğer kodlardan ayrımı önemlidir:

429 ile 503 en çok karıştırılan ikilidir. 503 ayrıntısı için 503 Service Unavailable hatası yazısına bakabilirsiniz; oradaki senaryolarla buradakiler tamamen farklıdır.

429 yanıtı ideal olarak bir Retry-After başlığı taşır. Onu görmek için:

curl -sI https://ornek.com/ | head -20

Örnek çıktı:

HTTP/2 429
retry-after: 60
x-ratelimit-limit: 100
x-ratelimit-remaining: 0
x-ratelimit-reset: 1754900000

retry-after: 60 saniye cinsindendir. Bu başlıkların varlığı ve içeriği, hatayı kimin ürettiğini bulmanın ilk ipucudur.

429 Hatasını Kim Üretti: Teşhis Sırası#

Kısa cevap: yanıtın başlıklarına ve gövdesine bakarak hatayı kimin ürettiğini üç adımda bulabilirsiniz.

Adım 1 — Yanıt gövdesine bakın. Ham yanıtı curl -s -D - https://ornek.com/ ile alın. Gövdede geçen ifade kaynağı ele verir:

• <center>nginx</center> ya da nginx/1.x → Nginx'in kendi limit_req modülü.
• cloudflare kelimesi, cf-ray başlığı ve Cloudflare markalı sayfa → Cloudflare Rate Limiting ya da WAF.
• Error code 1015 → Cloudflare'in kendi hız sınırı.
• LiteSpeed imzası → LiteSpeed bağlantı limiti.
• Sadece JSON ({"message":"Too Many Requests"}) → uygulama katmanı, muhtemelen bir API ya da WordPress eklentisi.

Adım 2 — Sunucu tarafında değil, dışarıdan test edin. Kendi IP'niz engellenmiş olabilir. Farklı bir ağdan (mobil veri, başka bir sunucudan curl) deneyin:

ssh baska-sunucu 'curl -s -o /dev/null -w "%{http_code}\n" https://ornek.com/'

Dışarıdan 200, sizden 429 geliyorsa sorun sitede değil, sizin IP'nizin engellenmiş olmasındadır. Herkeste 429 çıkıyorsa limit global olarak yanlış kurulmuştur ve acil müdahale gerekir.

Adım 3 — Logdan doğrulayın. Nginx erişim logunda 429'ları sayın:

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

Çıktı tek bir IP'de yoğunlaşıyorsa hedefli bir bot/saldırı vardır. Çıktı yüzlerce farklı IP'ye yayılmışsa limit yanlış kurulmuştur ve gerçek ziyaretçileri kesiyorsunuzdur. Bu ayrım yazının en kritik noktasıdır.

Hata logundaki limit_req satırları asıl kanıttır — grep 'limiting requests' /var/log/nginx/error.log | tail -20 çıktısı şuna benzer:

2026/08/11 14:02:11 [error] 1234#0: *5567 limiting requests, excess: 5.320 by zone "genel", client: 88.240.x.x, request: "GET /wp-content/themes/tema/style.css HTTP/2.0"

Bu satırdaki request: kısmına dikkat edin. Engellenen şey bir CSS dosyası ise, o ziyaretçi bot değil, sadece sayfayı açan normal bir kullanıcıdır — ve limitiniz yanlıştır.

Yanlış Pozitif: Gerçek Ziyaretçileriniz Engelleniyor Olabilir#

Türkçe içerikte hiç anlatılmayan asıl senaryo budur. Hız sınırı kurarken sıkça yapılan varsayım, "bir kullanıcı saniyede 5 istekten fazlasını yapmaz" olur ve bu varsayım yanlıştır: modern bir web sayfası tek açılışta 40-80 HTTP isteği üretir (HTML, CSS, 10-20 JS dosyası, yazı tipleri, 20-30 görsel, AJAX çağrıları) ve HTTP/2 üzerinde bunların hepsi neredeyse eşzamanlı gider.

Şu üç durum yanlış pozitifi kesinleştirir:

1. Statik dosyalar limite dahil edilmiş. limit_req kuralı location / altına yazıldıysa CSS, JS ve görseller de sayılır. Doğru yaklaşım limiti yalnızca dinamik uç noktalara uygulamaktır.

2. NAT arkasındaki ortak IP. Bir okul, ofis ya da mobil operatör NAT havuzu arkasındaki yüzlerce kişi tek bir genel IP ile görünür; IP başına limit koyduğunuzda o kurumun tamamını tek kullanıcı sayarsınız.

3. Gerçek istemci IP'si okunmuyor. Site Cloudflare ya da bir ters vekil arkasındaysa ve real_ip yapılandırması yoksa, Nginx tüm ziyaretçileri vekilin aynı IP'sinden geliyor sanır. Bu durumda IP başına 10 istek limiti, tüm siteye saniyede 10 istek limiti demektir ve site pratikte kapanır. Bu tek başına en çok gördüğüm 429 sebebidir.

Gerçek IP okumasını doğrulamak için erişim logunun ilk sütununa bakın (awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -5). Tek bir IP tüm trafiğin neredeyse tamamını oluşturuyorsa ve o IP bir CDN aralığına aitse, real_ip yapılandırmanız eksiktir. Nginx tarafında düzeltmesi:

# CDN/vekil aralıklarını tanıt, gerçek IP'yi başlıktan al
set_real_ip_from 10.0.0.0/8;
real_ip_header   CF-Connecting-IP;
real_ip_recursive on;

⚠️ real_ip_header yönergesini yalnızca güvendiğiniz vekil aralıkları set_real_ip_from ile tanımlandıktan sonra kullanın. Aksi halde herkes kendi IP'sini uydurabilir ve hız sınırınız tamamen etkisiz hale gelir.

Nginx limit_req Ayarını Doğru Kurma#

Nginx'te hız sınırı iki parçadır: bir bölge tanımı (limit_req_zone, http bloğunda) ve o bölgeyi uygulayan kural (limit_req, location içinde).

Yaygın hatalı kurulum, location / altına burst tanımlamadan tek bir limit_req zone=genel; satırı yazmaktır. Bu iki hata içerir: statik dosyalar da sayılır ve patlama toleransı olmadığı için eşiği aşan her istek anında reddedilir. Sayfa açılışındaki 50 istek bunu ilk saniyede tetikler.

Doğru kurulum:

http {
    # Dinamik istekler için bölge
    limit_req_zone $binary_remote_addr zone=dinamik:10m rate=10r/s;
    # Giriş/form gibi hassas uçlar için ayrı ve dar bölge
    limit_req_zone $binary_remote_addr zone=giris:10m rate=1r/s;

    limit_req_status 429;
    limit_req_log_level warn;
}

server {
    # Statik dosyalar hiç sayılmasın
    location ~* \.(css|js|jpg|jpeg|png|webp|svg|woff2|ico)$ {
        expires 30d;
        access_log off;
    }

    # Dinamik: patlamaya izin ver, kuyruğa al, reddetme
    location / {
        limit_req zone=dinamik burst=30 nodelay;
        try_files $uri $uri/ /index.php?$args;
    }

    # Giriş sayfası: dar limit, kuyruk yok
    location = /wp-login.php {
        limit_req zone=giris burst=5 nodelay;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

Üç parametrenin anlamı: rate=10r/s sürdürülebilir ortalama hızdır; burst=30 kısa süreli patlamada 30 isteğe kadar kuyruğa alır, reddetmez; nodelay ise kuyruktakileri bekletmeden işler — bu olmadan ziyaretçi sayfa açılışında yapay gecikme hisseder.

Değişiklikten sonra nginx -t && systemctl reload nginx ile sınayıp yükleyin. nginx -t hata verirse reload çalıştırmayın; bozuk yapılandırmayla yeniden yüklemek siteyi tamamen düşürür. Nginx tarafındaki hız sınırı ve güvenlik başlıklarının tamamı için Nginx rate limit ve güvenlik başlıkları yazısına bakabilirsiniz.

cPanel, cPHulk ve LiteSpeed Kaynaklı 429#

Paylaşımlı hosting kullanıyorsanız Nginx yapılandırmasına erişiminiz yoktur ve 429 genellikle şu üç kaynaktan gelir.

cPHulk Brute Force Protection. Sunucu genelinde çalışan bir koruma katmanıdır ve başarısız giriş denemelerini sayar. Sizin ofisinizde 5 kişi aynı IP'den WordPress paneline yanlış şifreyle girmeye çalıştıysa, cPHulk o IP'yi kilitler. Belirtisi: siteye erişilir ama giriş sayfası 429 ya da 403 verir. Çözümü sunucu yöneticisinden IP'nin beyaz listeye alınmasını istemektir; kendi VDS'inizde ise WHM üzerinden Security Center → cPHulk Brute Force Protection → Whitelist Management ekranından eklersiniz.

LiteSpeed eşzamanlı bağlantı limiti. LiteSpeed, IP başına eşzamanlı bağlantı sayısını sınırlar; sayfada çok fazla kaynak varsa tetiklenir ve ziyaretçi sayfanın yarısını yüklenmemiş görür. Çözüm görsel/JS birleştirme ve tembel yükleme ile eşzamanlı istek sayısını düşürmektir.

Barındırma paketi kaynak limiti. Genellikle 429 değil 508 döner ama bazı yapılandırmalarda 429 olarak görünür. cPanel'de Metrikler → Kaynak Kullanımı ekranında "Fault" sütununda birikme varsa paket limitinize dayanıyorsunuz demektir.

Hangi katmanın engellediğini görmek için sunucu hata kayıtlarını okumak gerekir; paylaşımlı pakette bu dosyalara cPanel'in Metrikler → Hatalar ekranından ulaşırsınız.

Cloudflare Kaynaklı 429 ve Error 1015#

Cloudflare arkasındaysanız 429'un büyük ihtimalle sizin sunucunuzla ilgisi yoktur. Ayırt etmek kolaydır: yanıt başlıklarında cf-ray varsa istek Cloudflare'den dönmüştür ve sunucunuza hiç ulaşmamıştır.

curl -sI https://ornek.com/ | grep -iE 'cf-ray|server|cf-cache-status'

Cloudflare tarafında 429 üreten üç ayar vardır. Rate Limiting kuralları Security → WAF → Rate limiting rules altında tanımlıdır; kuralın "Requests" eşiğine ve kapsadığı yol ifadesine bakın — tüm yolları kapsıyorsa (URI Path contains /) statik dosyalar da sayılıyor demektir. Bot Fight Mode meşru araçları (uptime izleme, ödeme sağlayıcı webhook'ları) engelleyebilir. Under Attack Mode açık kaldıysa her ziyaretçiye JS doğrulaması gösterir ve otomatik istemcileri tamamen kilitler.

Doğru yaklaşım: kural ifadesinde URI Path alanını /wp-login.php, /xmlrpc.php, /api/ gibi belirli yollarla sınırlayın, asla tüm siteye uygulamayın. Cloudflare'in DNS ve CDN katmanının çalışma mantığı için Cloudflare DNS ve CDN yazısına göz atabilirsiniz.

⚠️ Cloudflare üzerinde bir hız sınırı kuralı yazdıktan sonra kendi sitenizde 20-30 sayfa gezinerek kuralın sizi engellemediğini doğrulayın. Kuralı yazıp bırakmak, gerçek trafikte fark edilene kadar günlerce sessizce ziyaretçi kesebilir.

WordPress Eklenti Döngüsünün Ürettiği 429#

Bu senaryoda 429'u dışarıdan gelen kimse üretmez — siteniz kendi kendine saldırır.

Klasik döngü şöyledir: bir eklenti (yedekleme, SEO tarayıcı, kırık bağlantı denetleyici, otomatik görsel optimize edici) kendi sitesine wp_remote_get() ile HTTP isteği atar. Bu istek sunucunun kendi dış IP'sinden çıkıp geri gelir. Yüzlerce sayfayı tararken saniyede onlarca istek üretir ve sunucudaki hız sınırını tetikler. Sonuç: eklenti kendi taramasında 429 alır, kullanıcı da "site çok fazla istek gönderiyor" hatası görür.

Teşhis: erişim logunda sunucunun kendi dış IP'sinden gelen istekleri sayın (awk '$1 == "SUNUCU_IP" {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head). Kullanıcı aracısı alanında WordPress/6.x; https://ornek.com görürseniz kaynak kesindir: kendi WP-Cron ya da eklenti isteğiniz.

Üç çözüm: sunucunun kendi IP'sini hız sınırından muaf tutun, ağır tarayıcı eklentilerin tarama hızını düşürün, ve WP-Cron'u devre dışı bırakıp gerçek sistem cron'una taşıyın:

// wp-config.php
define( 'DISABLE_WP_CRON', true );

# 5 dakikada bir gerçek cron
*/5 * * * * curl -s https://ornek.com/wp-cron.php?doing_wp_cron > /dev/null

Nginx'te muafiyet:

geo $muaf_limit {
    default        0;
    203.0.113.10   1;   # sunucunun kendi dış IP'si
    198.51.100.0/24 1;  # ofis ağı
}

map $muaf_limit $limit_anahtari {
    0 $binary_remote_addr;
    1 "";
}

limit_req_zone $limit_anahtari zone=dinamik:10m rate=10r/s;

Boş anahtar ("") limit dışıdır; yani $muaf_limit değeri 1 olan kaynaklar hiç sayılmaz.

API Tüketicisi Tarafında 429: Retry-After ve Geri Çekilme#

429'u siz alıyorsanız — örneğin bir kargo, ödeme ya da sosyal medya API'sine bağlanan bir entegrasyon yazdıysanız — doğru davranış tekrar denemeyi hemen yapmak değil, üstel geri çekilmedir (exponential backoff).

Yanlış yaklaşım, while döngüsünde hemen tekrar denemektir; bu limiti daha da uzatır ve bazı sağlayıcılarda kalıcı engele dönüşür.

Doğru desen:

<?php
function istekAt( string $url, int $maxDeneme = 5 ) {
    $bekle = 1; // saniye

    for ( $i = 0; $i < $maxDeneme; $i++ ) {
        $ch = curl_init( $url );
        curl_setopt_array( $ch, [
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_HEADER         => true,
            CURLOPT_TIMEOUT        => 15,
        ] );
        $yanit = curl_exec( $ch );
        $kod   = curl_getinfo( $ch, CURLINFO_RESPONSE_CODE );
        curl_close( $ch );

        if ( $kod !== 429 ) {
            return $yanit;
        }

        // Retry-After varsa ona uy, yoksa üstel geri çekil
        if ( preg_match( '/retry-after:\s*(\d+)/i', $yanit, $m ) ) {
            $bekle = (int) $m[1];
        }
        sleep( $bekle );
        $bekle = min( $bekle * 2, 60 ); // tavan 60 sn
    }

    throw new RuntimeException( 'Hız sınırı aşıldı, işlem bırakıldı.' );
}

İki kural: Retry-After başlığı varsa her zaman ona uyun, yoksa bekleme süresini her denemede ikiye katlayıp bir tavana bağlayın. Ayrıca istek hacmini baştan azaltmak için yanıtları önbelleğe alın — aynı veriyi dakikada 60 kez sormak yerine bir kez sorup 60 saniye saklamak sorunu tamamen ortadan kaldırır.

Doğru Limit Nasıl Belirlenir#

Kısa cevap: limiti tahminle değil, kendi log verinizden hesaplayın.

Adım adım:

1. Mevcut normali ölçün. Son 24 saatte IP başına en yüksek dakikalık istek sayısını çıkarın:

awk '{split($4,a,":"); print $1" "a[2]":"a[3]}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

Çıktının ilk satırları en yoğun IP-dakika çiftleridir. İçlerinden bilinen botları (Googlebot, uptime izleyici) ayırın; kalan en yüksek değer gerçek kullanıcı tavanınızdır.

2. Limiti bu tavanın 2-3 katına koyun. Ölçtüğünüz tavan dakikada 120 istek ise rate değerini yaklaşık 4r/s + burst=60 civarında kurun.

3. Önce sadece izleyin. Engellemeden önce bir süre limit_req_log_level warn ile hata logunu takip edip kaç meşru isteğin tetikleneceğini görün.

4. Katmanlı limit kurun. Tek bir global limit yerine uç noktaya göre farklı eşikler kullanın:

5. Kalıcı kötü niyetli IP'yi limitle değil, engelle. Hız sınırı meşru trafiği düzenlemek içindir; ısrarlı saldırganı Fail2ban ile tamamen engellemek hem daha ucuz hem daha kesin bir çözümdür. Kurulumu için Fail2ban kurulumu yazısına bakabilirsiniz.

Sıkça Sorulan Sorular#

429 Too Many Requests ne demek#

429 Too Many Requests, sunucunun belirli bir zaman aralığında kabul ettiği istek sayısının aşıldığını bildiren HTTP durum kodudur. Sunucu çalışıyor, site ayakta, sadece o istemciye geçici bir fren uygulanıyordur. Yanıtta genellikle Retry-After başlığı bulunur ve kaç saniye beklenmesi gerektiğini söyler. Kodun 4xx ailesinde olması istemcinin suçlu olduğu anlamına gelmez; çoğu vakada sunucudaki eşik yanlış ayarlanmıştır.

429 hatası aldığımda ne kadar beklemeliyim#

Yanıttaki Retry-After başlığında yazan saniye kadar beklemelisiniz. Başlık yoksa 30-60 saniye beklemek çoğu yapılandırmada yeterlidir. Beklemeden tekrar denemek çoğu sistemde sayacı sıfırlamaz, aksine uzatır ve bazı korumalar ısrarlı denemeyi kalıcı engele çevirir. Bir entegrasyon yazıyorsanız bekleme süresini her başarısız denemede ikiye katlayıp bir tavana bağlayın.

Kendi ziyaretçilerim neden 429 alıyor#

En sık nedeni, hız sınırının statik dosyaları da sayması ve gerçek istemci IP'sinin okunamamasıdır. Modern bir sayfa tek açılışta 40-80 istek üretir; limit location / altına yazıldıysa bu patlama anında eşiği aşar. Site bir CDN ya da ters vekil arkasındaysa ve real_ip yapılandırması eksikse Nginx tüm ziyaretçileri tek IP'den geliyor sanar, bu da limitin tüm siteye uygulanması demektir. Erişim logunun ilk sütununda tek bir IP tüm trafiği kapsıyorsa teşhis kesindir.

429 hatası SEO'yu etkiler mi#

Evet, süreklilik kazanırsa etkiler. Googlebot 429 aldığında tarama hızını kendiliğinden düşürür; bu kısa vadede zararsızdır ve hatta sunucuyu korur. Ancak hata günlerce sürerse Google sitenin sağlıksız olduğunu varsayar, tarama sıklığını ciddi biçimde azaltır ve yeni içerikleriniz geç indekslenir. Search Console'da "Tarama istatistikleri" raporunda 429 satırının yükseldiğini görüyorsanız botu engelleyen kuralı gevşetmeniz gerekir.

Cloudflare Error 1015 nedir#

Error 1015, Cloudflare'in kendi hız sınırlama kuralının tetiklendiğini gösteren özel hata sayfasıdır ve teknik olarak bir 429'dur. İstek sunucunuza hiç ulaşmamıştır, dolayısıyla sunucu loglarında hiçbir iz bulamazsınız. Kaynağı Cloudflare panelinde Security → WAF → Rate limiting rules bölümünde tanımlı kuraldır. Kuralın kapsadığı yol ifadesi tüm siteyi içeriyorsa statik dosyalar da sayılıyor demektir ve daraltılması gerekir.

WordPress'te 429 hatasını hangi eklentiler tetikler#

Kendi sitesine toplu HTTP isteği atan eklentiler tetikler: kırık bağlantı denetleyicileri, site tarayan SEO araçları, tam site yedekleme eklentileri ve otomatik görsel optimize ediciler. Bunlar wp_remote_get() ile sunucunun kendi dış IP'sinden yüzlerce istek üretir ve hız sınırını tetikler. Erişim logunda kullanıcı aracısı alanında WordPress/6.x ifadesi görüyorsanız kaynak kesin olarak sitenizin kendisidir. Çözüm sunucunun dış IP'sini limitten muaf tutmak ve tarama hızını düşürmektir.

Rate limit ile DDoS koruması aynı şey mi#

Hayır, farklı katmanlarda çalışırlar. Hız sınırı uygulama katmanında, istek başına ve genellikle IP bazlı çalışır; amacı meşru trafiği düzenlemek ve kaba kuvvet denemelerini yavaşlatmaktır. DDoS koruması ağ katmanında, hacimsel saldırıları sunucuya ulaşmadan önce süzer. Saniyede yüz binlerce paket gelen bir saldırıda hız sınırı hiçbir işe yaramaz, çünkü sunucu o isteklerin başlığını okuyacak kadar bile ayakta kalamaz. İkisi birbirinin yerine geçmez, birlikte kullanılır.

429 ile 503 arasındaki fark nedir#

429 hız sınırının aşıldığını, 503 ise servisin geçici olarak hizmet veremediğini bildirir. 429'da sunucu sağlıklıdır ve isteği bilinçli olarak reddeder; 503'te sunucu ya doldu, ya bakım modunda, ya da arka uç işlem havuzu tükendi. Ayırt etmenin en pratik yolu tek bir tarayıcıdan yavaşça tek istek atmaktır: 429 birkaç saniye sonra kaybolur, 503 kaybolmaz. İkisi de kısa süreli olduğunda arama motorları için güvenlidir, sürekli hale gelirse ikisi de tarama sıklığını düşürür.

Kapanış#

429 Too Many Requests hatasında ilk yapılacak şey limiti gevşetmek değil, hatayı kimin ürettiğini kesin olarak bulmaktır. Yanıt başlıklarında cf-ray varsa istek CDN'de kesilmiştir ve sunucu loglarınızda iz bırakmaz; nginx imzası varsa limit_req bölgeniz devrededir; JSON gövde geliyorsa uygulama katmanı konuşuyordur. Ardından logdaki 429'ların tek bir IP'de mi yoksa yüzlerce IP'ye yayılmış mı olduğuna bakın — birincisi gerçek bir saldırıdır ve limit çalışıyordur, ikincisi ise yanlış pozitiftir ve gerçek ziyaretçilerinizi kesiyorsunuzdur. Limiti daima kendi log verinizden ölçtüğünüz normal tavanın 2-3 katına kurun, statik dosyaları limit dışında tutun, giriş ve API uçlarına ayrı ve dar bir eşik verin.

Bu katmanların ayarını kendiniz yönetmek istemiyorsanız devredebileceğiniz noktalar var. Hacimsel saldırı trafiğinin sunucuya ulaşmadan süzülmesi için DDoS koruma, uygulama seviyesinde kural tabanlı filtreleme ve bot yönetimi için WAF hizmetimize bakabilirsiniz. limit_req, real_ip ve Fail2ban yapılandırmasının sizin adınıza kurulup izlenmesini istiyorsanız sunucu yönetimi paketimiz bu işi üstlenir; kendi kurallarınızı yazabileceğiniz tam kök erişimli bir ortam arıyorsanız VDS sunucu paketlerimiz uygun başlangıç noktasıdır.