Nginx'te Rate Limit ve Güvenlik Başlıkları

Bir web sunucusunu ilk kurduğunuzda her şey pürüzsüz çalışır: siteniz açılır, sayfalar hızlı yüklenir, sorun yok gibidir. Ama internete açık her sunucu, canlıya alındığı ilk saatten itibaren otomatik tarayıcıların, kaba kuvvet botlarının ve zaman zaman gerçek saldırıların hedefi olur. Bunların çoğu size özel değildir; internetin tamamını tarayan sistemler, açık bir /wp-login.php ya da yanıt veren bir /api/login uç noktası bulur bulmaz saniyede onlarca istek göndermeye başlar. Hiçbir sınır koymadıysanız bu trafik ya sunucunuzun CPU'sunu ve veritabanı bağlantılarını tüketir ya da şifre denemeleriyle bir hesabı ele geçirmeye kadar gider.

İşte bu noktada Nginx'in iki basit ama güçlü aracı devreye girer: rate limiting (istek sınırlama) ve güvenlik başlıkları (security headers). Rate limiting, tek bir IP'nin belirli bir süre içinde kaç istek atabileceğini sınırlar; yani kaba kuvvet ve botları yavaşlatarak zararsız hale getirir. Güvenlik başlıkları ise tarayıcıya "bu siteyi nasıl güvenli göstermeni istiyorum" talimatını verir; clickjacking, MIME sniffing ve HTTPS düşürme gibi saldırı sınıflarını kapatır. Bu rehberde her ikisini de gerçek yapılandırma örnekleriyle, üretimde bozulmadan çalışacak şekilde kuruyoruz. Nginx'i henüz kurmadıysanız önce Ubuntu'da Nginx kurulumu rehberine göz atmanızı öneririm.

Rate Limiting Neden Gerekli?#

Rate limiting, tek bir istemcinin (genelde bir IP adresinin) belirli bir zaman penceresinde yapabileceği istek sayısını sınırlama tekniğidir. Amaç, meşru kullanıcıyı hiç etkilemeden anormal davranışı kısmaktır. Normal bir ziyaretçi bir sayfayı açar, birkaç saniye okur, sonra bir başka sayfaya geçer; saniyede belki bir-iki istek atar. Bir bot ise aynı uç noktaya saniyede 50 istek gönderir. Sınır koyduğunuzda meşru kullanıcı sınıra hiç yaklaşmaz, bot ise anında duvara toslar.

Bunun somut faydaları şunlardır:

• Kaba kuvvet (brute force) saldırılarını durdurur. Login formuna saniyede yüzlerce şifre denemesi yapan bir botu, dakikada birkaç denemeye indirirseniz saldırı pratikte imkânsız hale gelir.
• Kaynak tüketimini engeller. Arama, filtreleme veya rapor üreten pahalı uç noktalar, sınırsız çağrıldığında sunucuyu dize getirir. Rate limit bu maliyeti tavanlar.
• Scraping ve içerik hırsızlığını yavaşlatır. Tüm siteyi kopyalamaya çalışan botlar, sayfa başına saniyeler beklemek zorunda kalır.
• Küçük ölçekli DDoS'a ilk savunma hattıdır. Katman-7 seviyesindeki basit saldırılara karşı ilk tamponu oluşturur. Büyük hacimli saldırılar için tek başına yeterli değildir; onun için ağ katmanında çalışan DDoS koruma çözümlerine ihtiyaç duyarsınız.

Şunu baştan netleştirmek gerekir: rate limiting bir "sihirli kalkan" değildir. Katman-3/4 hacim saldırılarını (gigabitlerce trafik) tek başına karşılayamaz, ama uygulama katmanındaki kötüye kullanımı ciddi biçimde azaltır. Bunu, kapsamlı bir savunmanın en ucuz ve en hızlı kurulan parçası olarak düşünün.

limit_req_zone ile İstek Sınırlama Kurmak#

Nginx'te istek sınırlamanın kalbi iki direktiftir: limit_req_zone ve limit_req. Birincisi paylaşımlı bir hafıza bölgesi (zone) tanımlar ve oranı belirler; ikincisi ise bu bölgeyi belirli bir server veya location bloğunda uygular.

limit_req_zone yalnızca http bloğunda tanımlanır. Örneğin /etc/nginx/nginx.conf dosyasının http { ... } bölümüne şunu ekleyin:

http {
    # Anahtar: istemcinin IP adresi (binary formatta, az yer kaplar)
    # Bölge adı: genel_limit, boyut: 10MB (yaklaşık 160.000 IP tutar)
    # Oran: saniyede 10 istek
    limit_req_zone $binary_remote_addr zone=genel_limit:10m rate=10r/s;

    # Login gibi hassas uçlar için ayrı, daha sıkı bir bölge
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;
}

Burada üç önemli parametre var. Anahtar ($binary_remote_addr) sınırın neye göre uygulanacağını belirler; IP başına sınırlamak için bunu kullanırız (binary hali $remote_addr'a göre daha az bellek yer). Bölge boyutu (10m) ne kadar IP'nin durumunu tutabileceğinizi belirler; 1 MB yaklaşık 16.000 IP tutar. Oran (rate) ise izin verilen hızdır: 10r/s saniyede 10 istek, 5r/m dakikada 5 istek demektir. Login için dakika bazlı, saniyeden çok daha yavaş bir oran seçtiğimize dikkat edin.

Şimdi bu bölgeyi bir server bloğunda uygulayalım. Nginx içeride oranı milisaniyeye çevirir; yani 10r/s, "her istek arasında en az 100 ms" anlamına gelir:

server {
    listen 443 ssl;
    server_name example.com;

    location / {
        limit_req zone=genel_limit burst=20 nodelay;
        proxy_pass http://127.0.0.1:8080;
    }
}

burst ve nodelay parametrelerini bir sonraki bölümde ayrıntılı ele alacağız; şimdilik önemli olan yapının çalışması. Yapılandırmayı yazdıktan sonra mutlaka söz dizimini test edin ve ancak sorunsuzsa yeniden yükleyin:

sudo nginx -t
sudo systemctl reload nginx

nginx -t çıktısı syntax is ok ve test is successful demiyorsa reload yapmayın; aksi halde canlı siteyi bozarsınız. Sınıra takılan istekler varsayılan olarak 503 Service Temporarily Unavailable yanıtı alır. Bu kodu limit_req_status 429; ile 429'a (Too Many Requests) çevirmek daha doğru ve standarda uygundur.

burst ve nodelay: Gerçek Trafiği Bozmadan Sınırlamak#

limit_req direktifini yalın rate ile kullanırsanız Nginx çok katıdır: 10r/s demek, iki istek arasında 100 ms'den az varsa ikinciyi anında reddetmek demektir. Oysa gerçek tarayıcılar bir sayfayı açarken CSS, JS, resim, font gibi 15-20 kaynağı neredeyse aynı anda ister. Yalın sınır, meşru kullanıcının yarım sayfasını 503'e düşürür. burst tam da bunu çözer.

burst=N, oranı aşan istekler için bir kuyruk tanımlar. Fazladan gelen istekler hemen reddedilmez; N kişilik kuyruğa alınıp rate hızında sırayla işlenir. nodelay eklerseniz kuyruktaki istekler beklemeden hemen işlenir, ama yine de sayaçtan düşülür; yani ani yükü (ör. sayfa açılışındaki 20 paralel istek) geciktirmeden karşılar, sadece sürekli yüksek hızı kısar. Çoğu web sitesi için doğru kombinasyon burst + nodelay'dir.

Üç davranışı karşılaştıralım:

Pratik bir örnek: statik ağırlıklı bir WordPress sitesinde, sayfa başına düşen paralel istek sayısını rahatça karşılayacak bir tampon bırakırsınız.

location / {
    limit_req zone=genel_limit burst=20 nodelay;
    # ...
}

# Login sayfasında tampon minimal, gecikmeli olsun
location = /wp-login.php {
    limit_req zone=login_limit burst=3 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

burst değerini belirlerken şu mantığı izleyin: ortalama bir sayfanın kaç alt istek doğurduğunu tahmin edin (tipik olarak 10-30) ve tamponu bunun biraz üstünde tutun. Çok yüksek burst sınırı işlevsiz bırakır; çok düşük değer meşru kullanıcıyı rahatsız eder. WordPress altyapınızın performansını WordPress bakım hizmetiyle profesyonel elden geçirmek de bu tür ayarların oturması açısından değerli olur.

limit_conn ile Eşzamanlı Bağlantı Sınırlama#

limit_req istek hızını sınırlar; limit_conn ise aynı anda açık bağlantı sayısını sınırlar. İkisi farklı saldırı türlerini kapatır. Bir bot saniyede az istek atıp ama her istekte bağlantıyı uzun süre açık tutarak (yavaş yükleme, büyük dosya indirme, Slowloris tarzı davranış) kaynak tüketebilir. limit_conn bunu engeller.

Kurulum yine iki adımlıdır. http bloğunda bölgeyi tanımlarsınız:

http {
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
}

Sonra uygulama yerinde sınırı koyarsınız:

server {
    # IP başına en fazla 15 eşzamanlı bağlantı
    limit_conn conn_limit 15;

    location /indir/ {
        # İndirme dizininde daha sıkı: IP başına 5 eşzamanlı bağlantı
        limit_conn conn_limit 5;
        # İstemci başına indirme hızını da kapayalım
        limit_rate 2m;
    }
}

Buradaki limit_rate 2m; bonus bir korumadır: her bağlantının bant genişliğini 2 MB/s ile sınırlar; büyük dosyaları indirerek hattı tıkayan botları frenler. limit_conn için makul bir başlangıç değeri IP başına 10-20 bağlantıdır. Modern tarayıcılar bir alan adına genelde 6 paralel bağlantı açtığı için bu değer meşru kullanıcıyı hiç etkilemez, ama tek IP'den yüzlerce bağlantı açmaya çalışan botu keser. limit_req ile limit_conn'u birlikte kullanmak, hem hız hem eşzamanlılık boyutunu kapattığı için önerilir.

Güvenlik Başlıkları (add_header) ile Sertleştirme#

Rate limiting kötüye kullanımı yavaşlatır; güvenlik başlıkları ise tarayıcıyı sizin lehinize çalışan bir savunma katmanına dönüştürür. HTTP yanıtına eklenen bu başlıklar, modern tarayıcılara "bu siteyi şu kurallarla göster" der ve clickjacking, MIME sniffing, HTTPS düşürme gibi bütün saldırı sınıflarını kapatır. Nginx'te add_header direktifiyle eklenirler.

En önemli başlıkları ve ne işe yaradıklarını görelim:

Bunları server bloğuna ekleyelim. Kritik uyarı: add_header direktifinin Nginx'te sinsi bir davranışı vardır; bir location bloğunda add_header kullanırsanız, üst bloktaki tüm add_header tanımları o location için iptal olur. Bu yüzden başlıkları en dış geçerli seviyede toplu tutun.

server {
    listen 443 ssl;
    server_name example.com;

    # 1 yıl boyunca yalnızca HTTPS; alt alan adlarını da kapsa
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # İçerik türü tahminini kapat
    add_header X-Content-Type-Options "nosniff" always;

    # Iframe'e gömülmeyi tamamen yasakla
    add_header X-Frame-Options "SAMEORIGIN" always;

    # Referer bilgisini kısıtla
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Temel bir CSP (sitenize göre uyarlayın)
    add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self'" always;
}

Sonundaki always parametresi önemlidir; onsuz başlık yalnızca 2xx/3xx yanıtlarda eklenir, hata sayfalarında (403, 404, 500) eklenmez. always ile her yanıtta garantilenir. HSTS'te dikkat edin: max-age süresi boyunca tarayıcı siteye ısrarla HTTPS ile bağlanır, dolayısıyla önce SSL sertifikanızın kusursuz çalıştığından emin olun. Geçerli bir sertifikanız yoksa ücretsiz veya ücretli SSL çözümüyle başlayın; HSTS'i bozuk sertifikayla açmak siteyi tümden erişilemez yapabilir.

CSP başlığı en güçlü ama en dikkat isteyen başlıktır. Çok katı bir CSP, kendi script ve stillerinizi bile bloke edip siteyi bozabilir. Üretime almadan önce Content-Security-Policy-Report-Only modunda test edip tarayıcı konsolundaki ihlalleri gözlemleyin, kuralı oturttuktan sonra gerçek başlığa geçin. Güvenlik başlıkları, sunucu güvenliği temelleri rehberinde anlatılan bütünsel sertleştirmenin uygulama katmanındaki tamamlayıcısıdır.

Login ve API Uçlarını Hedefli Korumak#

Rate limiting'in en yüksek getirisi, her yeri aynı sınırla boğmak değil; doğru uçları doğru sınırla hedeflemektir. Ana sayfaya günde binlerce meşru istek gelir; login ve API uçlarına ise saldırgan trafiği yoğunlaşır. Bu yüzden bunlara özel, daha sıkı bölgeler tanımlanır.

Login uçları için mantık basittir: gerçek bir kullanıcı dakikada birkaç kez şifre girer; bir bot ise saniyede yüzlerce dener. 5r/m gibi bir oran, meşru kullanıcıyı hiç zorlamadan kaba kuvveti bitirir:

# http bloğunda
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r/s;

# server bloğunda
location = /api/login {
    limit_req zone=login_limit burst=3 nodelay;
    limit_req_status 429;
    proxy_pass http://127.0.0.1:8080;
}

location /api/ {
    limit_req zone=api_limit burst=50 nodelay;
    limit_req_status 429;
    proxy_pass http://127.0.0.1:8080;
}

API uçlarında oranı, ödeme yapan gerçek entegrasyonların ihtiyacına göre daha cömert (ör. 30r/s) tutabilirsiniz; login uçlarını ise mümkün olan en kısık ayarda bırakın. limit_req_status 429; eklemek, istemcinin standart bir "çok fazla istek" yanıtı almasını sağlar; iyi yazılmış istemciler bu kodu görünce geri çekilip yeniden dener.

Bir ince nokta: sunucunuz bir CDN veya ters proxy arkasındaysa $binary_remote_addr her isteği CDN'in IP'si olarak görür ve tüm kullanıcıları tek IP sanarak yanlışlıkla hepsini sınırlar. Bu durumda gerçek istemci IP'sini X-Forwarded-For başlığından güvenilir şekilde almak için ngx_http_realip_module (set_real_ip_from + real_ip_header) yapılandırmanız gerekir; ancak bunu yalnızca güvendiğiniz proxy IP aralıkları için yapın, aksi halde saldırgan başlığı taklit edip sınırı atlatır. Uygulama seviyesinde ek koruma isterseniz, WAF katmanı login ve API uçlarını imza tabanlı kurallarla da savunur.

Rate Limit, Güvenlik Başlıkları ve WAF Nasıl Birlikte Çalışır?#

Bu üç mekanizmayı birbirinin alternatifi değil, katmanlı savunmanın (defense in depth) parçaları olarak düşünün. Her biri farklı bir saldırı yüzeyini kapatır ve birlikte kullanıldıklarında tekil bir çözümün asla ulaşamayacağı bir dayanıklılık verir.

Rollerini net ayıralım. Rate limiting hacimsel kötüye kullanımı hedefler: kimin ne kadar sık istek atabileceğini belirler, ama isteğin içeriğine bakmaz. Güvenlik başlıkları tarayıcı tarafındaki saldırıları kapatır: clickjacking, MIME sniffing, protokol düşürme; bunlar sunucuya değil, kullanıcının tarayıcısına yönelik tehditlerdir. WAF (Web Application Firewall) ise isteğin içeriğini inceler: SQL injection, XSS, path traversal, bilinen zafiyet imzaları gibi kötü niyetli yükleri tespit edip engeller.

Tipik bir istek yolu şöyle işler:

İstemci
  → DDoS koruma (hacim saldırısını süzer)
  → WAF (kötü niyetli içeriği engeller: SQLi, XSS...)
  → Nginx rate limit (istek hızını/eşzamanlılığı kısar)
  → Uygulama (güvenlik başlıklarıyla yanıt döner)

Karşılaştırma tablosu bunu netleştirir:

Bu yüzden "WAF'ım var, rate limit'e gerek yok" ya da tersi düşünce yanlıştır. Örneğin WAF, teknik olarak geçerli ama sadece çok sık gönderilen bir login isteğini "temiz" görür; onu ancak rate limit durdurur. Buna karşılık rate limit'i aşmayan tek bir SQL injection isteğini ise ancak WAF yakalar. En sağlam kurulum, üçünü de aynı anda kullanan kurulumdur. Kendi sunucunuzu yönetmek istemiyorsanız sunucu yönetimi hizmetiyle bu katmanların tümünü profesyonel olarak kurdurabilirsiniz.

Test, İzleme ve Yaygın Hatalar#

Yapılandırmayı yazmak işin yarısıdır; gerçekten çalıştığını doğrulamak diğer yarısıdır. Rate limit'i canlıya almadan önce basit bir yük testiyle deneyin. ab (Apache Benchmark) ile tek IP'den art arda istek atarak sınıra takılıp takılmadığınızı görün:

# 200 istek, 20 eşzamanlı; kaç tanesi 503/429 aldı?
ab -n 200 -c 20 https://example.com/api/login

Çıktıdaki "Non-2xx responses" satırı, sınıra takılan istek sayısını gösterir. Beklediğiniz kadar isteğin reddedildiğini görüyorsanız yapılandırma çalışıyor demektir. Güvenlik başlıklarını doğrulamak için ise curl yeterlidir:

curl -I https://example.com | grep -iE "strict-transport|x-frame|x-content|referrer|content-security"

Bu komut yanıt başlıklarını listeler; eklediğiniz her başlığı burada görmelisiniz. Sınıra takılan istekler ise Nginx hata günlüğüne düşer; onları izlemek için:

sudo tail -f /var/log/nginx/error.log | grep "limiting requests"

Uygulamada en sık yapılan hatalar şunlardır. always unutmak: güvenlik başlıklarını always olmadan eklerseniz hata sayfalarında başlıklar kaybolur. add_header gölgeleme tuzağı: bir location'da add_header kullanınca üst bloktaki tüm başlıkların iptal olduğunu unutmak; bu yüzden başlıkları tek bir yerde toplayın veya her location'da tekrarlayın. CDN arkasında yanlış IP: realip modülü olmadan tüm kullanıcıları tek IP sanıp topluca sınırlamak. Aşırı katı HSTS: SSL kusurluyken uzun max-age verip siteyi erişilemez yapmak. Fazla düşük burst: gerçek kullanıcıları 503'e düşürüp "site bozuk" şikayetleri almak. Bu ayarları oturttuktan sonra, sitenizin genel sağlığını ve yanıt sürelerini düzenli izlemek için araçlar sayfasındaki yardımcıları ve düzenli yedekleme alışkanlığını da ihmal etmeyin.

Sıkça Sorulan Sorular#

Rate limit koyduğumda gerçek kullanıcılarım etkilenir mi?#

Doğru ayarlandığında meşru kullanıcılar sınırı hiç fark etmez. Normal bir ziyaretçi saniyede bir-iki istek atarken, 10r/s gibi bir oran ve burst=20 gibi bir tampon bu davranışı rahatça karşılar. Etkilenme yaşanıyorsa genelde burst değeri çok düşük tutulmuştur ya da tek bir sayfanın doğurduğu paralel istek sayısı hesaba katılmamıştır; bu durumda tamponu yükseltmek sorunu çözer. Her zaman canlıya almadan önce ab gibi bir araçla test edip meşru trafiğin sınıra takılmadığını doğrulayın.

HSTS başlığını açtıktan sonra geri alabilir miyim?#

Teknik olarak başlığı yapılandırmadan kaldırabilirsiniz, ama pratikte iş biraz karışıktır. HSTS başlığını bir kez gören tarayıcı, max-age süresi dolana kadar siteye ısrarla HTTPS ile bağlanmaya devam eder; siz başlığı kaldırsanız bile o tarayıcıdaki kayıt hemen silinmez. Bu yüzden HSTS'i açmadan önce SSL sertifikanızın kusursuz çalıştığından emin olun ve ilk denemede kısa bir max-age (örneğin birkaç saat) verip her şeyin yolunda olduğunu gördükten sonra bir yıla çıkarın.

limit_req ile limit_conn arasındaki fark nedir?#

İkisi farklı boyutları sınırlar ve birbirini tamamlar. limit_req, bir IP'nin belirli sürede kaç istek yapabileceğini yani istek hızını kısar; kaba kuvvet ve hızlı tarama saldırılarına karşı etkilidir. limit_conn ise bir IP'nin aynı anda kaç bağlantı açık tutabileceğini sınırlar; bağlantıyı uzun süre açık tutarak kaynak tüketen Slowloris tarzı saldırılara karşı korur. En sağlam kurulum ikisini birlikte kullanır, çünkü tek başına hiçbiri her senaryoyu kapatmaz.

503 yerine 429 döndürmek neden daha iyi?#

Standartlara göre 429 (Too Many Requests) kodu tam olarak "istek sınırını aştın" anlamına gelir, 503 (Service Unavailable) ise "sunucu geçici olarak hizmet veremiyor" gibi daha genel bir durumu ifade eder. İyi yazılmış istemciler ve API entegrasyonları 429 kodunu görünce geri çekilip bir süre sonra yeniden denemesi gerektiğini anlar; 503'ü ise farklı yorumlayabilirler. limit_req_status 429; ekleyerek doğru sinyali vermiş olur ve arama motorlarının da bu durumu geçici bir sınırlama olarak doğru algılamasını sağlarsınız.

Rate limit tek başına DDoS saldırılarına karşı yeterli mi?#

Hayır, tek başına yeterli değildir ve buna güvenmek yanıltıcı olur. Nginx rate limiting, uygulama katmanındaki (Katman-7) kötüye kullanımı ve orta ölçekli botları etkili biçimde yavaşlatır; ancak gigabitlerce trafik gönderen hacimsel (Katman-3/4) saldırılar sunucunuza ulaşmadan ağ seviyesinde süzülmelidir. Bu tür saldırılar için özel DDoS koruma altyapısına ihtiyaç duyarsınız. Rate limiting'i, bu bütünsel savunmanın en ucuz ve en hızlı kurulan ilk katmanı olarak görün, tek savunma hattınız olarak değil.

CDN veya ters proxy arkasındayken rate limit neden yanlış çalışıyor?#

Çünkü Nginx varsayılan olarak $binary_remote_addr ile isteğin geldiği en yakın IP'yi görür; siz bir CDN arkasındaysanız bu her zaman CDN'in IP'sidir. Sonuçta bütün kullanıcılarınız tek bir IP'den geliyormuş gibi görünür ve rate limit hepsini topluca sınırlar, siteniz erken tıkanır. Çözüm, ngx_http_realip_module'ü yapılandırıp gerçek istemci IP'sini X-Forwarded-For başlığından almaktır; ancak bunu yalnızca güvendiğiniz proxy IP aralıkları için etkinleştirin, aksi halde saldırganlar başlığı taklit ederek sınırı atlatabilir.

Kapanış#

Nginx'te rate limiting ve güvenlik başlıkları, birkaç satır yapılandırmayla kurulan ama karşılığında ciddi bir savunma katmanı kazandıran araçlardır. limit_req_zone ile hız sınırı, limit_conn ile eşzamanlılık sınırı koyup kaba kuvvet ve botları etkisiz hale getirirken; add_header ile eklediğiniz HSTS, X-Frame-Options ve CSP gibi başlıklar tarayıcı tarafındaki saldırıları kapatır. Bunları WAF ve DDoS koruma ile katmanlı biçimde birleştirdiğinizde, tek bir çözümün asla veremeyeceği bir dayanıklılığa ulaşırsınız. Yapılandırmayı canlıya almadan önce nginx -t ile test etmeyi, always parametresini unutmamayı ve burst değerini gerçek trafiğinize göre ayarlamayı aklınızda tutun.

Bu sertleştirmeyi kendiniz uygulamak yerine hazır ve yönetilen bir altyapıda çalışmak istiyorsanız Clou.TR sizi bu yükten kurtarır. Yüksek performanslı hosting paketlerimizde temel güvenlik önlemleri ön tanımlı gelir; tam kontrol isteyenler için VDS ve sanal sunucu çözümlerimizde rate limit, güvenlik başlıkları ve WAF katmanlarını dilediğiniz gibi yapılandırabilir, isterseniz sunucu yönetimi hizmetiyle tüm kurulumu bize bırakabilirsiniz. Sunucunuzu güvenli, hızlı ve ölçeklenebilir bir temele oturtmak için doğru yerdesiniz.