Nginx Reverse Proxy ve Basit Load Balancer Kurulumu

Küçük bir SaaS uygulaması, yeni açılan bir e‑ticaret projesi veya mikroservis mimarisine geçmek isteyen bir ekip… Ortak sorun genellikle aynı: Tek sunucuda her şey güzel giderken trafik artmaya başlar, bazı saatlerde istekler yığılır, uygulama yanıt süreleri uzar ve hangi noktadan sonra mimariyi büyütmeniz gerektiği net değildir. Tam bu noktada Nginx reverse proxy ve basit bir load balancer (yük dengeleyici) mimarisi, küçük projeler için hem yönetilebilir hem de ekonomik bir çözüm sunar.

Bu yazıda pratik bir modeli adım adım anlatacağız: Önde bir Nginx reverse proxy, arkada bir veya birkaç uygulama sunucusu. Amaç; SSL sonlandırma, statik içerik sunumu, basit load balancing ve backend hatalarına karşı temel toleransı tek bir yerde toplamak. gzip/Brotli sıkıştırma ise ayrıca yapılandırılabilecek bir optimizasyondur. Komut seviyesinde, dosya yollarına kadar inen, gerçekten uygulayabileceğiniz bir rehber hazırladık. Örnek için yönetim erişiminiz olan bir proxy sunucusu ve bir veya iki uygulama sunucusu gerekir. VPS veya dedicated sunucu seçerken kaynak kapasitesini ve sunucular arası ağ erişimini planlayın; uygulamanızın kurulumu ayrıca tamamlanmış olmalıdır.

Nginx Reverse Proxy ve Load Balancer Temelleri

Önce kavramları netleştirelim. Reverse proxy, istemcilerden (tarayıcı, mobil uygulama, API client) gelen istekleri karşılayan ve bu istekleri arka uçtaki (backend) sunuculara yönlendiren bir katmandır. İstemci isteklerini reverse proxy’ye gönderir; bunun için gerçek uygulama sunucularının IP’lerini bilmesi gerekmez.

Load balancer ise birden fazla backend sunucunuz varsa, gelen trafiği bu sunucular arasında paylaştırır. Nginx, HTTP katmanında (L7) hem reverse proxy hem de basit load balancer rolünü aynı anda üstlenebilir. Yani ekstra bir ürün veya karmaşık bir yazılıma geçmeden, tek Nginx ile:

• SSL sonlandırma (HTTPS terminasyon)
• Kurulu sürüm, modüller ve yapılandırmaya bağlı HTTP/2/HTTP/3 desteği
• Statik dosyaları doğrudan sunma
• Uygulama sunucularına reverse proxy
• Round robin, least_conn gibi basit yük dengeleme algoritmaları
• Temel hata toleransı (uygun hata ve yeniden deneme koşullarında başka bir backend’e yönlendirme; her isteğin kesintisiz tamamlanması garanti değildir)

Bu yazıda Nginx’in L7 tarafını kullanacağız. Eğer daha sonra L4 seviyesi (TCP/UDP) yük dengeleme, TLS passthrough gibi ihtiyaçlarınız olursa, HAProxy ile L4/L7 yük dengeleme rehberimize de göz atabilirsiniz.

Küçük Projeler İçin Bu Mimari Neden Mantıklı?

Tek VPS’te her şeyi (web sunucu, veritabanı, queue işleri, cron’lar) koşturmak başlangıç için idealdir. Ancak zamanla şu sorunlar ortaya çıkabilir:

• Yoğun saatlerde CPU ve RAM aynı makinede tıkanır.
• Uygulamayı yeni sürüme geçirirken kullanılan deploy yöntemine bağlı olarak kesinti yaşanabilir.
• Node.js, PHP, belki Python gibi birden fazla runtime aynı makinede karışıklık yaratır.

Ön tarafa bir Nginx reverse proxy koyup arka tarafa bir veya iki uygulama sunucusu eklediğinizde:

• Yeni sürümü trafik almayan bir backend’de hazırlayıp doğruladıktan sonra Nginx yönlendirmesini değiştirebilirsiniz; trafik alan tek backend üzerinde deploy yapmak kesintiyi önlemez.
• Gerekirse ikinci bir uygulama VPS’i ekleyip basit round robin load balancing ile trafiği bölüşebilirsiniz.
• Statik dosyaları (CSS, JS, görseller) Nginx’ten direkt sunup, uygulama sunucularının yükünü azaltabilirsiniz.

Küçük SaaS’ler, ajansların yönettiği çok müşterili WordPress/Laravel projeleri veya hafif mikroservis ortamları için bu model son derece pratiktir. Daha kapsamlı mimariler için küçük SaaS uygulamaları için mimari rehberimizi de inceleyebilirsiniz.

Hedef Mimari: 1 Reverse Proxy + 2 Uygulama Sunucusu

Bu rehberde aşağıdaki basit mimariyi kurduğunuzu varsayalım. Tek reverse proxy hâlâ tek hata noktasıdır; iki backend kullanmak proxy arızasına karşı yedeklilik sağlamaz:

• proxy.example.com – DCHost üzerinde çalışan Nginx reverse proxy (genel IP bu sunucuda)
• app1.internal – Uygulama sunucusu 1 (PHP/Laravel, Node.js veya başka bir stack)
• app2.internal – Uygulama sunucusu 2 (aynı uygulamanın ikinci kopyası)

DNS tarafında www.example.com ve api.example.com gibi alan adlarınız, sadece Nginx reverse proxy sunucusunun IP’sine işaret eder. Uygulama sunucuları doğrudan internete açılmak zorunda değildir; mümkünse sadece özel ağ (private network) veya firewall ile kısıtlı IP erişimi ile korunmalıdır.

Örnek Kullanım Senaryosu

Diyelim ki Laravel tabanlı bir e‑ticaret siteniz var. Uygulama kodu Laravel, arka planda queue işleri var, veritabanı ayrı bir VPS’te. Bu rehberde kuracağımız Nginx reverse proxy için hedefleriniz şunlar olsun:

• Tüm HTTPS trafiğini kabul etsin,
• Statik dosyaları (CSS/JS/img) kendisi sunsun,
• Uygulama isteklerini app1 ve app2 arasında dengelesin,
• Uygulama sunucularından biri cevap vermezse uygun yeniden deneme koşullarında diğerini kullanabilsin,
• İleride Nginx mikro önbellekleme ile yalnızca herkese aynı sunulan, önbelleğe uygun sayfaları 1–5 saniye saklayabilsin; oturum, sepet, ödeme ve kişiye özel yanıtlar kapsam dışında kalsın.

Mikro önbellekleme tarafına derinleşmek isterseniz, detaylı kural örnekleri için Nginx mikro önbellekleme rehberimize bakabilirsiniz.

Ön Hazırlık: Sunucu, DNS ve Güvenlik

1. Sunucuları Hazırlayın

Minimumda ihtiyacınız olanlar:

• 1 adet DCHost VPS veya dedicated sunucu: Nginx reverse proxy
• 1–2 adet DCHost VPS: Uygulama sunucuları

Dağıtım olarak Ubuntu 22.04 LTS veya Debian 12 gibi, kullanacağınız paketler için güvenlik güncellemeleri almaya devam eden bir Linux sürümü seçin. Yeni bir VPS açıyorsanız, temel hardening adımlarını atlamayın; bunun için yeni VPS’te ilk 24 saat rehberini adım adım uygulayabilirsiniz.

2. DNS Yapılandırması

Alan adınızın DNS yönetim panelinde:

• example.com ve www.example.com için A kayıtlarını Nginx proxy sunucusunun IPv4 adresine yönlendirin. AAAA kaydı yalnızca proxy’nin IPv6 erişimi, Nginx dinleyicisi ve güvenlik duvarı buna uygun yapılandırılmışsa eklenmelidir; aşağıdaki temel örnek IPv6 dinleyicisi içermez.
• Alt alanlar (örneğin api.example.com) da yine proxy IP’sine gitmeli.

Uygulama sunucularının DNS kayıtları (örn. app1.internal) public olmak zorunda değil; /etc/hosts veya özel DNS ile de çözümleyebilirsiniz. Önemli olan, reverse proxy sunucusunun bu adresleri çözebiliyor olması.

3. Güvenlik Duvarı (Firewall) Ayarları

Proxy sunucusunda herkese açık gelen web trafiğini 80 ve 443 portlarıyla sınırlayın. SSH yönetim erişimini yalnızca yönetici IP’lerinden veya yönetim VPN’inden sağlayın; kuralları uygularken mevcut yönetim erişimini koruyun. Uygulama sunucularında ise gelen erişimi şu şekilde sınırlayın:

• 22 (SSH) – Sadece yönetim için, IP kısıtlaması önerilir
• Uygulamanın HTTP dinleyicisi (örneğin app1 üzerinde 10.0.0.11:8000), ağ üzerinden proxy’nin erişebildiği bir arayüzde dinlemeli; bu porta yalnızca proxy sunucusundan erişim verilmelidir. 127.0.0.1 yalnızca aynı makineden erişilebilir, ayrı proxy sunucusundan erişilemez.

Güvenlik duvarı tarafında daha detaylı ipuçları için VPS güvenlik duvarı yapılandırma rehberimize göz atabilirsiniz.

Nginx Reverse Proxy Kurulumu: Adım Adım

1. Nginx Kurulumu

Proxy sunucusunda aşağıdaki komutlarla Nginx’i kuralım (Ubuntu/Debian):

sudo apt update
sudo apt install nginx -y

Kurulumdan sonra servis durumunu kontrol edin:

sudo systemctl status nginx

Tarayıcınızdan sunucu IP’sine gittiğinizde Nginx’in varsayılan karşılama sayfasını görmelisiniz.

2. Basit Reverse Proxy Konfigürasyonu

Önce tek uygulama sunucusuna reverse proxy yaparak başlayalım. Varsayalım ki uygulama sunucunuzun iç IP’si 10.0.0.11 ve uygulama bu IP’nin 8000 portunda HTTP isteklerini kabul ediyor. Bu adresi proxy’den erişilebilen gerçek backend adresinizle değiştirin. PHP/Laravel kullanıyorsanız burada doğrudan PHP-FPM değil, uygulamayı HTTP üzerinden sunan bir web sunucusu bulunmalıdır.

Proxy sunucusunda yeni bir site dosyası oluşturun:

sudo nano /etc/nginx/sites-available/example.com.conf

İçine şu iskeleti ekleyin:

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://10.0.0.11:8000;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
    }
}

Siteyi etkinleştirin; yapılandırma testi başarılı olursa Nginx yapılandırmasını yeniden yükleyin:

sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/example.com.conf

sudo nginx -t && sudo systemctl reload nginx

DNS ve ağ erişimi doğruysa, bu yapılandırmanın 80 portunda karşıladığı example.com ve www.example.com HTTP istekleri 10.0.0.11:8000 üzerindeki uygulamaya iletilir. Bu aşama ilk bağlantı testi içindir; HTTPS kurulup doğrulanmadan giriş, ödeme veya başka hassas kullanıcı trafiği almayın. HTTPS yapılandırması sonraki bölümde ele alınacaktır.

Basit Load Balancer: Nginx Upstream Yapılandırması

1. Upstream Bloğu ile Başlayalım

Şimdi ikinci bir uygulama sunucusu ekleyelim: 10.0.0.12:8000. Nginx’te upstream bloğu tanımlayarak bu iki backend’i tek bir isim altında toplayacağız. Önce ikinci backend’in aynı uygulama sürümünü ve uyumlu yapılandırmayı kullandığından emin olun. Oturumlar ve yüklenen dosyalar gibi sunucuya yerel durumun her iki backend’den de erişilebilir olmasını sağlayın; yalnızca uygulama kodunu kopyalamak, isteklerin iki sunucuya dağıtılması için yeterli olmayabilir.

Proxy sunucusunda /etc/nginx/conf.d/upstreams.conf dosyasını oluşturalım:

sudo nano /etc/nginx/conf.d/upstreams.conf

İçeriği:

upstream app_backend {
    # Varsayılan: round robin
    server 10.0.0.11:8000 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:8000 max_fails=3 fail_timeout=30s;
}

Varsayılan eşit ağırlıklı round robin, istekleri iki backend arasında dağıtır. max_fails=3 ve fail_timeout=30s, 30 saniyelik aralıkta üç başarısız iletişim denemesi sayılan backend’in 30 saniye kullanılamaz kabul edilmesini sağlar; hataların art arda olması gerekmez. Başarısızlık sayımı proxy_next_upstream tanımına bağlıdır. Varsayılan yeniden deneme koşulları error ve timeout’tur; bütün 5xx yanıtları otomatik olarak bu kapsama girmez. Örneğin 500/502/503/504 yanıtlarının sayılması ayrıca seçilmiş olmalarına bağlıdır; 403/404 bu hata sayımına dahil edilmez. Bu pasif hata takibidir, uygulama sağlığını periyodik sorgulayan aktif kontrol değildir. İstemciye yanıt gönderilmeye başladıktan sonra başka backend’e geçerek yanıt düzeltilemez; upstream’e gönderilmiş POST gibi işlemleri yeniden denemek de yan etki oluşturabilir.

2. Server Bloğunu Upstream ile Eşleştirme

Şimdi example.com.conf içindeki proxy_pass satırını upstream ismine çevirelim:

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://app_backend;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
    }
}

Kaydedin; yapılandırma testi başarılı olursa yeniden yükleyin:

sudo nginx -t && sudo systemctl reload nginx

Yapılandırma yüklendikten sonra her backend’in istek aldığını kendi uygulama kayıtlarından doğrulayın. Uygulamanın güvenilen proxy ayarına yalnızca backend’in gördüğü gerçek proxy kaynak adresini ekleyin; tüm özel ağı veya herhangi bir kaynağı güvenilir saymayın. Nginx örnekleri yönlendirilen host ve protokol başlıklarını değiştirir; uygulamada kabul edilen alan adlarını da sınırlandırın. X-Forwarded-For listesinin ilk adresini doğrulamadan istemci IP’si kabul etmeyin. NAT veya ek proxy varsa tüm yolu doğrulayın; çelişkili istemci başlıklarıyla IP, host ve HTTPS algısını sınayın.

3. Farklı Load Balancing Algoritmaları

Nginx’in birkaç temel algoritması var:

• Round robin (varsayılan): İstekleri sırayla dağıtır.
• least_conn: En az aktif bağlantısı olan sunucuya yönlendirir.
• ip_hash: Aynı IP’den gelen istekleri aynı backend’e yönlendirir (basit sticky session).

Örneğin yoğun trafiğiniz varsa ve bağlantı sayıları arasında fark oluşuyorsa least_conn kullanılabilir. Önceki app_backend bloğunu aşağıdakiyle değiştirin; aynı isimle ikinci bir blok eklemeyin:

upstream app_backend {
    least_conn;
    server 10.0.0.11:8000 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:8000 max_fails=3 fail_timeout=30s;
}

Oturumun aynı sunucuda kalması kritikse (örneğin sunucu taraflı session kullanan eski bir uygulama) ip_hash düşünebilirsiniz; fakat güncel uygulamalarda genellikle paylaşımlı session store (Redis vb.) kullanmak daha sürdürülebilirdir.

Algoritmayı değiştirdikten sonra sudo nginx -t && sudo systemctl reload nginx ile yalnızca başarılı testten sonra yükleyin; backend seçimini kayıtlardan kontrol edin. IP’ye bağlı yönlendirme, arıza veya istemci adresi değişimi sırasında aynı oturumun korunacağını garanti etmez.

SSL, HTTP/2 ve Güvenlik Katmanı

1. SSL sertifikası ve HTTPS Zorunluluğu

Bu rehber TLS’i proxy sunucusunda sonlandırır; proxy ile backend arasındaki örnek bağlantı HTTP’dir. Bu bağlantıyı güvenilen özel ağda veya şifreli tünel içinde kullanın; yalnızca kaynak IP’sini güvenlik duvarıyla kısıtlamak trafiği şifrelemez. Örneği şifrelenmemiş bir genel internet bağlantısına uygulamayın. Aşağıdaki HTTPS bloğundan önce, yönettiğiniz alan adlarını kapsayan sertifikayı ve özel anahtarı hazırlayın. Örnek dosya yollarını mevcut gerçek tam sertifika zinciri ve anahtar yollarıyla değiştirin; dosyalar yokken TLS bloğunu veya HTTPS yönlendirmesini etkinleştirmeyin. Mevcut HTTP server bloğunu aşağıdaki düzenle değiştirin; aynı isimle ikinci bir çakışan blok eklemeyin.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/certs/example.com.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # Güçlü TLS ayarları
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
    }
}

Sertifika yolları ve yapılandırma hazırsa sudo nginx -t && sudo systemctl reload nginx çalıştırın; başarısız testten sonra ilerlemeyin. Her alan adını dışarıdan HTTPS ile açıp sunulan sertifika adlarını, HTTP’den HTTPS’ye yönlendirmeyi ve doğru backend yanıtını doğrulayın. TLS ayarları ve Brotli sıkıştırması için Nginx üzerinde TLS 1.3 ve Brotli kurulumu rehberimizi inceleyebilirsiniz. OCSP Stapling desteği sertifikaya ve sertifika otoritesine bağlıdır: Let’s Encrypt, OCSP hizmetini 6 Ağustos 2025’te kapattığından güncel Let’s Encrypt sertifikalarında kullanılamaz.

2. HTTP Güvenlik Başlıkları

Güvenlik başlıklarını uygulamanın ihtiyacına göre mevcut HTTPS server bloğuna ekleyebilirsiniz. Örnekte SAMEORIGIN, başka kökenden çerçeveleme gerektiren bir uygulamayla uyumlu olmayabilir; kritik akışları kontrol edin. Eski X-XSS-Protection filtresi önerilmez; HSTS ve CSP’yi izleyen rehberdeki gibi aşamalı değerlendirin. Daha alt bir location düzeyinde add_header tanımı varsa üst başlıklar varsayılan kalıtımla aktarılmaz; gerekiyorsa ilgili başlıkları o düzeyde de koruyup gerçek yanıtı denetleyin:

add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options SAMEORIGIN always;

Daha ileri seviyede HSTS, CSP gibi başlıkları uygularken dikkatli olmak gerekir; yanlış konfigürasyon frontendu bozabilir. Bu konuda genel prensipleri anlamak için HTTP güvenlik başlıkları rehberimize göz atabilirsiniz.

Başlık değişikliklerini kaydettikten sonra sudo nginx -t && sudo systemctl reload nginx ile test başarılıysa yükleyin; normal ve hata yanıtlarında beklenen başlıkları kontrol edin.

Statik Dosyalar ve Önbellekleme

1. Statik İçerikleri Nginx’ten Sunmak

Yalnızca herkese açık, uygulamanın yayımladığı statik varlıkları proxy sunucusunda /var/www/example.com/public/assets/ altına dağıtın ve uygulama sürümüyle eşzamanlı tutun. Örnekte /assets/app.css isteği bu dizindeki app.css dosyasına karşılık gelir. Uygulamanın ürettiği varlık URL’lerini bu özel yol ile eşleştirin. Laravel public dizinini bütünüyle kopyalamayın; PHP kaynaklarını, giriş betiklerini, gizli dosyaları ve özel kullanıcı yüklemelerini bu dizine koymayın.

Aşağıdaki blok tek başına tam bir HTTPS yapılandırması değildir. Önceki HTTPS server bloğundaki sertifika ve TLS ayarlarını koruyun; yalnızca aşağıdaki root ve location bölümlerini o bloğa uygulayın, mevcut location / bölümünü değiştirin.

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    # Önceki HTTPS örneğinin gerçek sertifika ve TLS ayarlarını burada koruyun.
    root /var/www/example.com/public;

    location ^~ /assets/ {
        try_files $uri =404;
        expires off;
        add_header Cache-Control "public, max-age=2592000";
        add_header X-Content-Type-Options nosniff always;
        add_header X-Frame-Options SAMEORIGIN always;
    }

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
    }
}

Bu eşlemede yalnız /assets/ altındaki yayımlanmış dosyalar yerelden sunulur; bu yol altında eksik bir dosya 404 döner ve uygulamaya aktarılmaz. Bu nedenle özel yüklemeleri veya dinamik görsel uçlarını bu ad alanına yerleştirmeyin. Örneğin başka bir yol altındaki özel profil görseli, uzantısı .jpg olsa da uygulamaya gider ve uygulamanın erişim denetimine tabidir. expires off ek Expires/Cache-Control üretimini kapatır; statik yanıtta tek açık 30 günlük Cache-Control politikası bulunur. URL sürümleme veya daha kısa süreyle güncellemeleri yönetin; 404 yanıtına uzun süreli public başlığı eklenmez. Statik location kendi add_header satırlarını kullandığı için iki güvenlik başlığı burada da korunur. Gerekli diğer başlıkları uygulamanızın politikasına göre ekleyip gerçek yanıtı denetleyin.

Dosya dağıtımı ve yapılandırma düzenlemesi tamamlanınca sudo nginx -t && sudo systemctl reload nginx çalıştırın. Test başarısızsa yeniden yüklemeye geçmeyin. Var olan bir statik dosyayı, eksik bir varlığı, normal bir uygulama URL’sini ve erişim denetimi gerektiren bir kullanıcı dosyasını ayrı ayrı kontrol edin; durum kodlarını, içerik türlerini ve önbellek başlıklarını doğrulayın.

2. Mikro Önbellekleme ile Dinamik Sayfaları Hızlandırmak

Yoğun okunma trafiği olan, ancak çok sık değişmeyen sayfalarda (blog, ürün listeleme vb.) 1–5 saniyelik mikro önbellek backend yükünü ve yanıt süresini azaltabilir; kazanç önbellek isabet oranına bağlıdır. Ortak önbelleğe yalnızca tüm ziyaretçilere aynı içeriği veren yanıtları alın; oturum açmış kullanıcılara ait veya kişiselleştirilmiş yanıtları hariç tutun. Nginx’in proxy_cache özelliğiyle bunu reverse proxy katmanında yönetebilirsiniz. Detaylı bir uygulama ve purge stratejileri için tekrar Nginx mikro önbellekleme rehberine başvurabilirsiniz.

Loglama, İzleme ve Sorun Giderme

1. Nginx Access ve Error Logları

Bu mimaride reverse proxy, gelen web isteklerini izlemek için merkezi bir noktadır. Yaygın log yolları aşağıdadır; etkin dosyaları ve kayıt kapsamını Nginx yapılandırmanızdan doğrulayın:

• /var/log/nginx/access.log – Erişim kaydına alınan istekler
• /var/log/nginx/error.log – Nginx hataları

Özellikle 4xx–5xx hata oranlarınızı okumayı öğrenmek, performans ve hata ayıklama açısından kritiktir. Bunun için hem Apache hem de Nginx örnekleriyle anlattığımız sunucu loglarını okuma rehberimize bakabilirsiniz.

2. Kaynak Kullanımı ve Alarmlar

Reverse proxy’nin kaynak ihtiyacı trafik hacmine ve yaptığı işlemlere bağlıdır; CPU, bellek ve network kullanımını izleyin. Yönetimini üstlendiğiniz bir VPS veya fiziksel sunucuda Prometheus + Grafana ya da Netdata gibi çözümleri kurarak ayrıntılı metrik toplayabilirsiniz. Özellikle:

• CPU kullanımı (yüksek pikler)
• Load average
• Network throughput (Mbit/s)
• Disk I/O (log yazımı için)

Adım adım metrik ve alarm kurgulamak için VPS izleme ve uyarı kurulum rehberimizi kullanabilirsiniz.

Canlıya Alma, Deploy ve Kesintiyi Azaltma

Nginx reverse proxy, deploy stratejilerini esnek hale getirebilir. Örneğin yeni sürümü önce app2 sunucusuna dağıtıp trafiği kademeli artırabilirsiniz. Bu sırada app1’in tek başına yükü karşılayabilmesi, iki sürümün oturum verileri ve veritabanı şemasıyla uyumlu olması gerekir:

• Önce app2’yi yeni trafik almayacak şekilde havuzdan çıkarın ve mevcut isteklerin tamamlanmasını bekleyin; ardından yeni sürümü dağıtıp sağlık kontrollerini yapın.
• app2’yi düşük trafik payıyla yeniden havuza alın; weight değerlerini iki sunucunun göreli trafik payına göre belirleyin.
• Hata oranları ve performans iyi ise trafik payını kademeli artırın; sorun varsa trafiği sağlıklı eski sürüme geri alın.
• Her şey yolundaysa aynı trafik boşaltma ve kontrol adımlarını uygulayarak app1’i de güncelleyin. Her Nginx yapılandırma değişikliğini yeniden yüklemeden önce doğrulayın.

Daha ileri seviye için Nginx ile canary deployment ve ağırlıklı yönlendirme konularını anlattığımız canary dağıtımı rehberine de göz atabilirsiniz.

Operasyonel İpuçları: Küçük Ekipler İçin Pratikler

• Konfigürasyon yönetimi: Nginx ayar dosyalarını Git ile versiyonlayın, değişiklikleri stage → prod hattıyla yönetin.
• Erişim kontrolü: Sadece gerekli kişilere SSH erişimi verin. SSH anahtarıyla yeni bir oturum açabildiğinizi doğruladıktan sonra parolalı girişleri kapatın. Küçük ekipler için SSH anahtar yönetimi rehberi burada çok işinize yarar.
• Yedekler: Nginx konfigürasyonlarını içeren /etc/nginx dizinini, sertifikaları ve SSL özel anahtarlarını düzenli olarak yedekleyin. Özel anahtar içeren yedekleri şifreli ve erişimi kısıtlı tutun; sunucu değişiminden önce geri yükleme adımlarını deneyin.
• Ortam ayrımı: Geliştirme, staging ve prod ortamlarını DNS ve Nginx konfigürasyonlarıyla net ayırın (örn. staging.example.com).

Ne Zaman Daha Karmaşık Bir Mimariye Geçmelisiniz?

Nginx reverse proxy + basit load balancer modelinin ne kadar süre yeterli olacağı, iş yükünüze ve erişilebilirlik hedeflerinize bağlıdır. Ancak şu işaretleri görmeye başladığınızda sıradaki adımları düşünmenin zamanı gelmiştir:

• Tek proxy sunucusu CPU veya network açısından tıkanmaya başlıyorsa,
• Birden çok lokasyona (region) yayılmak istiyorsanız,
• TCP seviyesinde (L4) load balancing veya TLS passthrough ihtiyacınız oluştuysa,
• Otomatik ölçeklenen (auto-scaling) bir altyapıya geçmek istiyorsanız.

Bu durumda HAProxy, Kubernetes, k3s gibi seçenekleri, çözmek istediğiniz yük dengeleme veya orkestrasyon ihtiyacına göre değerlendirin. Tek proxy darboğazsa, Nginx’i aynı edge katmanında tutup yalnızca arkasına yeni sistemler eklemek bu darboğazı ortadan kaldırmaz. Çoklu VPS veya dedicated/colocation seçeneklerini değerlendirirken kapasiteyi, ağ gereksinimlerini ve yönetim sorumluluklarını planlayın; seçtiğiniz hizmetin destek kapsamını sözleşmede doğrulayın.

Sonuç ve Önerilen Yol Haritası

Nginx reverse proxy ve basit load balancer mimarisi, küçük ve orta ölçekli projeler için oldukça güçlü bir kaldıraçtır. Tek bir sunucuda her şeyi koşturmaktan bir adım öteye geçerek:

• SSL, HTTP/2 ve güvenlik başlıklarını merkezi noktada yönetebilir,
• Birden fazla uygulama sunucusuna trafiği dengeli dağıtabilir,
• Statik dosyaları Nginx’ten sunarak ve önbelleklenmeye uygun dinamik yanıtlar için mikro önbellekleme kullanarak uygulama yükünü azaltabilir,
• Deploy süreçlerinizi daha kontrollü hale getirebilir; trafik boşaltma, oturum yönetimi ve sürüm uyumluluğunu da planlayarak kesintiyi azaltabilirsiniz.

İlk adımda tek bir DCHost VPS üzerinde uygulamanızla birlikte Nginx reverse proxy’yi kurabilirsiniz. Ardından uygulamanın ikinci örneğini ayrı bir VPS’te çalıştırıp iki örneği upstream grubuna ekleyerek yük dengelemeye geçebilirsiniz. Buradaki 1 reverse proxy + 2 uygulama sunucusu ayrımını tamamlamak için Nginx’i ayrı bir proxy VPS’ine taşıyın. Trafiğiniz ve iş yükünüz büyüdükçe, izleme ve alarm sistemleriyle (Prometheus, Grafana vb.) mimarinizi gözlemleyin; darboğaz oluşan noktaları tespit ettikçe yeni sunucular veya daha gelişmiş load balancing çözümleriyle ölçeklendirin.

Eğer mevcut sitenizi veya uygulamanızı bu yapıya taşımak istiyorsanız, kapasite ihtiyacını, uygun VPS/dedicated kaynaklarını ve Nginx mimarisini içeren bir geçiş planı hazırlayın. Yönetim ve tasarım desteği gerekiyorsa, bu hizmetlerin kapsamını ayrıca belirleyin. İyi tasarlanmış küçük bir mimari, ihtiyaç duyulduğunda daha karmaşık sistemlere geçiş için bir temel oluşturabilir.