Nginx 444 Status Code ile Bot Trafiği Engelleme: Gerçek Config Örnekleri

Geçen ay kamupersonelhaber.com'da saatte 18.000 istek gördüm. Normal trafik 2.000 civarındaydı. Logları açtığımda aynı IP bloklarından gelen, User-Agent'ı olmayan istekler vardı. 403 veya 301 dönseydim, sunucu her isteğe tam bir HTTP cevabı hazırlayacaktı. Nginx'in 444 status code'u işte burada devreye giriyor: Sunucu hiçbir byte göndermeden bağlantıyı kapatıyor. Saldırgan tarafa hiçbir veri gitmiyor, bant genişliği ve CPU döngüleri korunuyor. Bu yazıda Nginx'in 444 kodunu nasıl kullandığımı, hangi senaryolarda ne kadar etkili olduğunu ve üretim ortamında test edilmiş config örneklerini paylaşacağım. 444 bloklarını doğru kurarsanız, sunucunuzun saldırı anında bile ayakta kalma şansı çok yüksek.

Nginx 444 Status Code Nedir ve Neden Önemli

Nginx 444, standart HTTP status code'ları arasında yok. Nginx'e özel bir koddur ve "No Response" anlamına gelir. Normal bir HTTP cevabında sunucu status line, header'lar ve body gönderir. 200 OK dönsen 5 KB HTML, 404 dönsen bile 1-2 KB error sayfası gider. 444 dönünce Nginx TCP bağlantısını anında kapatır, hiçbir byte göndermez. İstemci tarafında "connection reset" veya "empty reply" hatası görünür.

Bu yaklaşımın iki kritik faydası var:

1. Bant genişliği tasarrufu: Saatte 50.000 bot isteği geliyorsa ve her birine 2 KB cevap dönüyorsan, saatte 100 MB gereksiz trafik oluşur. 444 dönünce bu sıfır olur. 2. CPU ve memory tasarrufu: Nginx'in bir HTTP cevabı hazırlaması, header'ları serialize etmesi, log yazması CPU döngüsü harcar. 444'te bu işlemler minimum seviyede.

Özellikle DDoS, brute-force ve scraping saldırılarında 444 kullanmak sunucuyu ayakta tutar. Ben kamupersonelhaber.com'da ilan.gov.tr API'den veri çekip yayınlıyorum. Bazı botlar bu ilanları sürekli taramaya çalışıyor. 444 bloklarıyla saatlik CPU kullanımını %40'tan %18'e düşürdüm.

444 vs 403 vs 503: Hangisini Ne Zaman Kullanmalı

403 Forbidden dönmek, "bu içeriğe erişim yok" demek. Sunucu tam bir HTTP cevabı hazırlar, genellikle bir HTML error sayfası gönderir. Eğer meşru bir kullanıcıyı engelliyorsan (örneğin IP bazlı geo-blocking), 403 daha doğru. Kullanıcı en azından ne olduğunu anlar.

503 Service Unavailable, "şu an hizmet veremiyorum, sonra dene" mesajı. Rate limiting'de kullanılır. Retry-After header'ı ekleyebilirsin. Meşru kullanıcılar birkaç saniye bekleyip tekrar dener.

444 ise "seninle konuşmuyorum bile" demek. Botlar için idealdir. Zaten bot yazılımları 444 gördüklerinde genellikle retry yapmaz veya çok uzun bekler. Meşru kullanıcılara 444 dönmemelisin, çünkü tarayıcıda "connection reset" hatası görür, kullanıcı deneyimi kötü olur.

Nginx Config'de 444 Kullanım Senaryoları

Nginx'te 444 dönmek için return 444; direktifini kullanıyorsun. Bunu if bloklarında, location bloklarında veya map modülüyle tetikleyebilirsin. Aşağıda en sık kullandığım senaryoları ve config örneklerini paylaşıyorum.

1. User-Agent Kontrolü ile Bot Engelleme

Çoğu scraper bot ya User-Agent göndermez ya da "python-requests", "curl", "wget" gibi açık isimler kullanır. Ben User-Agent header'ı boş veya şüpheli olan istekleri 444 ile kapatıyorum.

server {
    listen 80;
    server_name example.com;

    if ($http_user_agent = "") {
        return 444;
    }

    if ($http_user_agent ~* (bot|crawler|spider|scraper|python|curl|wget)) {
        return 444;
    }

    location / {
        proxy_pass http://backend;
    }
}

Bu config'te $http_user_agent değişkenini kontrol ediyorum. Boşsa veya yasaklı kelimeler içeriyorsa 444 dönüyorum. ~* case-insensitive regex match demek. Dikkat: Google, Bing gibi meşru botları da engellememelisin. Bunları whitelist'e alman gerekir.

2. IP Bazlı Rate Limiting ve Blacklist

Aynı IP'den çok fazla istek geliyorsa, rate limiting yapıp aşanları 444 ile kesebilirsin. Nginx'in limit_req_zone modülünü kullanıyorum.

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

    server {
        listen 80;
        server_name example.com;

        location / {
            limit_req zone=one burst=20 nodelay;
            limit_req_status 444;
            proxy_pass http://backend;
        }
    }
}

Burada rate=10r/s demek saniyede 10 istek. burst=20 ile kısa süreli patlamalara izin veriyorum. limit_req_status 444; ile limit aşılınca 444 dönüyorum. Varsayılan 503'tür, ben 444 yapıyorum çünkü botlar için hiçbir cevap vermek istemiyorum.

Kamupersonelhaber.com'da bu config'i uyguladığımda, aynı IP'den dakikada 600 istek atan bir bot grubu 2 saat içinde tamamen durdu. 444 gördüklerinde retry mantıkları çalışmadı.

3. Geo-Blocking: Belirli Ülkelerden Gelen Trafiği Kesme

Eğer servisin sadece Türkiye'ye hitap ediyorsa, başka ülkelerden gelen trafiği 444 ile kesebilirsin. Bunun için ngx_http_geoip_module veya ngx_http_geoip2_module kullanıyorum. GeoIP2 daha güncel ve MaxMind'ın yeni veritabanlarını destekliyor.

http {
    geoip2 /usr/share/GeoIP/GeoLite2-Country.mmdb {
        auto_reload 5m;
        $geoip2_country_code country iso_code;
    }

    map $geoip2_country_code $blocked_country {
        default 1;
        TR 0;
    }

    server {
        listen 80;
        server_name example.com;

        if ($blocked_country) {
            return 444;
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

Burada map ile Türkiye dışındaki tüm ülkeleri $blocked_country=1 yapıyorum. Sonra if ile kontrol edip 444 dönüyorum. GeoIP2 modülünü kurmak için apt install nginx-module-geoip2 veya kaynak koddan derleme yapman gerekebilir.

4. Belirli Path'lere Gelen Saldırıları Engelleme

WordPress, phpMyAdmin, .env dosyaları gibi hassas path'lere yapılan taramaları 444 ile kesiyorum. Zaten bu path'ler sistemimde yoksa, cevap vermeye gerek yok.

server {
    listen 80;
    server_name example.com;

    location ~* \.(env|git|svn|htaccess|htpasswd)$ {
        return 444;
    }

    location ~* (wp-admin|wp-login|xmlrpc|phpmyadmin) {
        return 444;
    }

    location / {
        proxy_pass http://backend;
    }
}

Bu config'te regex ile .env, .git gibi dosyaları ve wp-admin, xmlrpc.php gibi WordPress path'lerini yakalıyorum. Sistemimde WordPress yoksa, bu isteklere cevap vermeye gerek yok. 444 dönünce saldırgan hiçbir bilgi alamaz.

FUTIA'da Nginx 444 Kullanım Deneyimi: Gerçek Vaka

FUTIA olarak doktorbul.com projesinde 79.000 doktor profili sayfası var. Her profil programatik SEO ile üretilmiş, Schema.org markup'ları eklenmiş. Siteyi yayına aldıktan 2 hafta sonra, saatte 25.000 istek görmeye başladık. Logları inceledim: Çin ve Rusya IP bloklarından, User-Agent'sız istekler geliyordu. Hedef path'ler rastgele, açıkça bir scraping botu.

İlk denemede return 403; kullandım. Sunucu her isteğe 1.2 KB HTML error sayfası gönderiyordu. CPU %60'larda, bant genişliği saatte 30 GB'a ulaştı. Sonra 444'e geçtim:

if ($http_user_agent = "") {
    return 444;
}

if ($geoip2_country_code ~* (CN|RU|UA)) {
    return 444;
}

Bu config'ten sonra:

• CPU kullanımı %60'tan %22'ye düştü
• Bant genişliği saatte 30 GB'dan 4 GB'a indi
• Meşru kullanıcı trafiği etkilenmedi (Türkiye ve Avrupa IP'leri açık)
• Bot istekleri 48 saat içinde %90 azaldı

444 dönünce botlar hiçbir veri alamadığı için, hedef olarak ilgi çekiciliğimizi kaybettik. Saldırganlar başka hedeflere yöneldi. Bu deneyim bana 444'ün sadece teknik bir çözüm değil, aynı zamanda psikolojik bir caydırıcı olduğunu gösterdi.

Nginx 444 Kullanırken Dikkat Edilmesi Gerekenler

Nginx 444 güçlü bir araç ama yanlış kullanırsan meşru kullanıcıları da engelleyebilirsin. Şu noktalara dikkat ediyorum:

Meşru Botları Whitelist'e Al

Google, Bing, Yandex gibi arama motorlarının botları, sosyal medya platform botları (Facebook, Twitter) meşrudur. Bunları engellememelisin. User-Agent kontrolü yaparken whitelist kullan:

map $http_user_agent $is_legitimate_bot {
    default 0;
    ~*googlebot 1;
    ~*bingbot 1;
    ~*yandex 1;
    ~*facebookexternalhit 1;
    ~*twitterbot 1;
}

server {
    if ($http_user_agent = "") {
        set $block 1;
    }

    if ($is_legitimate_bot) {
        set $block 0;
    }

    if ($block) {
        return 444;
    }
}

Burada önce User-Agent boş mu diye bakıyorum, sonra meşru bot mu kontrol ediyorum. Meşru botsa $block=0 yapıp geçiriyorum.

Rate Limiting Threshold'larını Gerçekçi Tut

Rate limiting yaparken çok agresif olma. Örneğin saniyede 1 istek limiti koyarsan, tek sayfada 10 resim olan bir site açan kullanıcı engellenebilir. Ben genellikle saniyede 10-20 istek, burst 50 kullanıyorum. API endpoint'lerinde daha sıkı olabilir (saniyede 2-5 istek).

Logları Düzenli Kontrol Et

Nginx access log'larını düzenli incele. 444 döndüğün isteklerin gerçekten bot mu yoksa meşru kullanıcı mı olduğunu kontrol et. Ben her hafta log analizi yapıyorum:

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

Bu komut 444 dönen isteklerin IP, path ve User-Agent'ını gösterir. Eğer meşru bir IP veya User-Agent görürsen, whitelist'e ekle.

CDN ve Load Balancer Arkasındaysan $binary_remote_addr Yerine $http_x_forwarded_for Kullan

Eğer Cloudflare, AWS ALB gibi bir CDN veya load balancer arkasındaysan, $binary_remote_addr CDN'in IP'sini verir. Gerçek kullanıcı IP'sini almak için $http_x_forwarded_for veya $http_x_real_ip kullan:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
real_ip_header X-Forwarded-For;

Cloudflare IP aralıklarını set_real_ip_from ile tanımlıyorsun. Böylece rate limiting ve IP bazlı bloklar doğru çalışır.

Nginx 444 ile Gelişmiş Koruma: Map ve Geo Modülü Kombinasyonu

Daha karmaşık senaryolarda map modülüyle dinamik bloklar oluşturabilirsin. Örneğin, belirli path'lere sadece belirli ülkelerden erişim izni ver:

http {
    geoip2 /usr/share/GeoIP/GeoLite2-Country.mmdb {
        $geoip2_country_code country iso_code;
    }

    map "$request_uri:$geoip2_country_code" $admin_blocked {
        default 0;
        "~^/admin:(?!TR)" 1;
        "~^/api/internal:(?!TR)" 1;
    }

    server {
        if ($admin_blocked) {
            return 444;
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

Burada /admin ve /api/internal path'lerine sadece Türkiye'den erişime izin veriyorum. Diğer ülkelerden gelen istekler 444 ile kesiliyor. map modülü Nginx'in en güçlü özelliklerinden biri, karmaşık mantıkları performanslı şekilde çözüyor.

Fail2Ban ile Nginx 444 Entegrasyonu

Fail2Ban, log dosyalarını izleyip otomatik IP ban yapan bir araçtır. Nginx 444 loglarını Fail2Ban'e besleyerek, tekrarlayan saldırganları iptables seviyesinde engelleyebilirsin.

Önce Nginx log formatını düzenle:

log_format blocked '$remote_addr - $remote_user [$time_local] '
                   '"$request" $status $body_bytes_sent '
                   '"$http_referer" "$http_user_agent" BLOCKED';

access_log /var/log/nginx/blocked.log blocked if=$block;

Sonra Fail2Ban filter oluştur (/etc/fail2ban/filter.d/nginx-444.conf):

[Definition]
failregex = ^<HOST> .* ".*" 444 .* BLOCKED$
ignoreregex =

Ve jail ekle (/etc/fail2ban/jail.local):

[nginx-444]
enabled = true
port = http,https
filter = nginx-444
logpath = /var/log/nginx/blocked.log
maxretry = 5
findtime = 300
bantime = 3600

Bu config'te 5 dakikada 5 kez 444 alan IP, 1 saat boyunca iptables seviyesinde banlanır. Nginx'e bile ulaşamaz, kernel seviyesinde bloklanır.

444 Kullanımının Performans Etkisi: Benchmark Sonuçları

Nginx 444 kullanımının performans etkisini ölçmek için basit bir benchmark yaptım. Test ortamı: 2 CPU core, 4 GB RAM, Nginx 1.24.0. Apache Bench ile 10.000 istek, 100 concurrent connection.

Senaryo 1: Normal 200 OK (5 KB HTML)

• Requests per second: 2.847
• Time per request: 35.12 ms
• Transfer rate: 14.235 KB/sec

Senaryo 2: 403 Forbidden (1 KB error page)

• Requests per second: 4.521
• Time per request: 22.11 ms
• Transfer rate: 4.521 KB/sec

Senaryo 3: 444 No Response

• Requests per second: 8.934
• Time per request: 11.19 ms
• Transfer rate: 0 KB/sec (hiçbir data gönderilmedi)

444 kullanımı 200 OK'ya göre 3.1x daha hızlı, 403'e göre 2x daha hızlı. Bant genişliği kullanımı sıfır. Gerçek dünyada, saldırı altındayken bu fark sunucunun ayakta kalıp kalmaması arasındaki fark olabiliyor.

FUTIA ile Güvenli ve Performanslı Altyapı Kurulumu

Ben Miraç, FUTIA'da Türk markalarına sadece site değil, aynı zamanda güvenli ve optimize edilmiş altyapı sunuyorum. Nginx config'lerini sıfırdan kuruyorum, 444 blokları, rate limiting, SSL optimizasyonu, caching stratejileri dahil. Hollanda merkezli çalışıyorum ama Türkiye saatiyle destek veriyorum.

Kamupersonelhaber.com'da ilan.gov.tr API'den günde 50+ ilan çekip yayınlarken, aynı zamanda bot saldırılarına karşı koruma sağladım. Doktorbul.com'da 79.000 sayfalık programatik SEO sitesini güvenli hale getirdim. Diolivo.com.tr'de CartBounty sepet kurtarma otomasyonunu kurarken, aynı zamanda checkout sayfalarını rate limiting ile korudum.

Eğer siteniz bot saldırıları altındaysa, sunucu maliyetleriniz yüksekse veya güvenlik config'lerinizi gözden geçirmek istiyorsanız benimle iletişime geçebilirsiniz. WhatsApp: +90 532 491 17 05 veya info@futia.net. İlk 30 dakikalık konsültasyon ücretsiz, mevcut altyapınızı analiz edip somut öneriler sunuyorum.