Nginx Reverse Proxy ve Basit Load Balancer Kurulumu: Küçük Projeler İçin Uygulamalı Rehber

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 DCHost ekibi olarak, sık kullandığımız pratik bir modeli adım adım anlatacağız: Önde bir Nginx reverse proxy, arkada bir veya birkaç uygulama sunucusu. Amaç; SSL sonlandırma, gzip/Brotli sıkıştırma, statik içerik sunumu, basit load balancing ve temel sağlık kontrollerini tek bir yerde toplamak. Komut seviyesinde, dosya yollarına kadar inen, gerçekten uygulayabileceğiniz bir rehber hazırladık. Elinizde bir DCHost VPS veya dedicated sunucu olması yeterli; geri kalanı bu yazıda birlikte kuracağız.

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 gerçek uygulama sunucularının IP’lerini bilmez; sadece reverse proxy ile konuşur.

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)
• 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ı (sunucu düşerse otomatik diğerine yönlendirme)

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 kısa da olsa kesinti yaşanır.
• 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:

• Uygulamayı yeni sürüme alırken önce arka uçta deploy yapıp, sonra Nginx tarafında yönlendirmeyi değiştirebilirsiniz.
• 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:

• 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. Siz bu rehberde kuracağımız Nginx reverse proxy:

• 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 otomatik diğerine geçsin,
• İleride Nginx mikro önbellekleme ile sayfaları 1–5 saniyelik cache’leyebilsin.

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 güncel bir Linux dağıtımını öneriyoruz. 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/AAAA kayıtlarını Nginx proxy sunucusunun IP’sine yönlendirin.
• 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 dışarıya sadece 80 ve 443 portlarını açın. Uygulama sunucularında ise mümkünse sadece:

• 22 (SSH) – Sadece yönetim için, IP kısıtlaması önerilir
• Uygulamanın dinlediği port (örneğin 127.0.0.1:9000, 127.0.0.1:8000 veya 0.0.0.0:8080), sadece proxy sunucusunun IP’sine açık olmalı

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 8000 portunda dinliyor.

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;
    }
}

Siteyi etkinleştirin ve Nginx’i test edip yeniden başlatın:

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

sudo nginx -t
sudo systemctl reload nginx

Artık example.com alan adınıza gelen tüm HTTP istekleri, 10.0.0.11:8000 üzerindeki uygulama sunucusuna yönlenecek.

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.

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;
}

Bu tanım ile Nginx gelen istekleri sırayla 10.0.0.11 ve 10.0.0.12’ye gönderir. Bir sunucu art arda 3 kez hata verirse (5xx veya timeout), 30 saniye boyunca devre dışı sayılır.

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;
    }
}

Kaydedin, ardından:

sudo nginx -t
sudo systemctl reload nginx

Artık istekleriniz iki uygulama sunucusu arasında otomatik olarak paylaştırılıyor. Basit ama oldukça etkili bir load balancing elde etmiş oldunuz.

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:

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.

SSL, HTTP/2 ve Güvenlik Katmanı

1. SSL sertifikası ve HTTPS Zorunluluğu

Public bir sitede reverse proxy daima HTTPS konuşmalıdır. Sertifikaları genellikle proxy sunucusunda sonlandırmanız en pratik yaklaşımdır. Sertifikayı aldıktan sonra server bloğunu şu şekilde güncelleyebilirsiniz:

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;
    }
}

Modern ve güvenli bir TLS yapılandırması için, örnek cipher setleri, OCSP Stapling ve Brotli gibi ek ayarlar konusunda Nginx üzerinde TLS 1.3 ve Brotli kurulumu rehberimizi mutlaka incelemenizi öneririz.

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

Reverse proxy katmanı, güvenlik başlıklarını merkezi olarak yönetmek için ideal bir yer. Örneğin:

add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";

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.

Statik Dosyalar ve Önbellekleme

1. Statik İçerikleri Nginx’ten Sunmak

Özellikle PHP veya Node.js tabanlı uygulamalarda, statik dosyaları Nginx’in doğrudan sunması büyük performans kazancı sağlar. Örneğin Laravel projelerinde /public klasörünü proxyle birleştirebilirsiniz:

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

    root /var/www/example.com/public;

    location / {
        try_files $uri @app;
    }

    location @app {
        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;
    }

    location ~* .(css|js|jpg|jpeg|png|gif|ico|webp|avif)$ {
        expires 30d;
        add_header Cache-Control "public, max-age=2592000";
    }
}

Bu sayede CSS, JS ve görseller uygulama sunucusuna uğramadan Nginx üzerinden servis edilir.

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 kullanmak muazzam performans artışı sağlar. 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ı

Reverse proxy katmanı, tüm trafiğin geçtiği yer olduğu için loglarınızın merkezi noktasıdır. Varsayılan olarak:

• /var/log/nginx/access.log – Tüm 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 genellikle çok ağır yük altında kalmaz; ancak trafik arttıkça CPU, bellek ve network kullanımını izlemeniz gerekir. DCHost üzerindeki VPS veya dedicated sunucunuzda Prometheus + Grafana, Netdata gibi çözümlerle 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 Sıfıra Yakın Kesinti

Nginx reverse proxy kullanmanın en keyifli yanlarından biri de deploy stratejilerini esnek hale getirmesidir. Örneğin yeni bir sürümü önce app2 sunucusuna deploy edip, Nginx upstream konfigürasyonunu kademeli olarak değiştirebilirsiniz:

• Önce weight ile app2’ye az trafikten başlayın.
• Hata oranları ve performans iyi ise yavaş yavaş ağırlığı artırın.
• Her şey yolundaysa app1’i de güncelleyin.

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, parolalı girişleri kapatıp SSH anahtarlarını kullanın. Küçük ekipler için SSH anahtar yönetimi rehberi burada çok işinize yarar.
• Yedekler: Nginx konfigürasyonlarını, /etc/nginx dizinini ve SSL anahtarlarını düzenli olarak yedekleyin. Sunucu değişimlerinde dakikalar içinde geri dönmek mümkün olur.
• 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 Mimarİye Geçmelisiniz?

Nginx reverse proxy + basit load balancer modeli, uzun süre idare eder. 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 Nginx’i edge katmanında tutup arkasına HAProxy, Kubernetes, k3s gibi sistemler eklemek mantıklı olabilir. DCHost olarak hem çoklu VPS mimarileri hem de dedicated/colocation altyapılarında bu tip senaryoları sıkça tasarlıyoruz; ihtiyacınız olduğunda teknik ekibimizle planlama yapabilirsiniz.

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 dosya ve mikro önbellekleme ile ciddi performans kazanımı sağlayabilir,
• Deploy süreçlerinizi daha kontrollü, neredeyse kesintisiz hale getirebilirsiniz.

İlk adımda tek bir DCHost VPS üzerinde Nginx reverse proxy’yi kurup, ardından ikinci bir uygulama VPS’i ekleyerek upstream mantığını devreye almanızı öneriyoruz. 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, DCHost destek ekibi olarak kapasite planlama, uygun VPS/dedicated seçimi ve Nginx mimarisinin tasarımı konusunda sizinle birlikte adım adım bir plan çıkartabiliriz. İyi tasarlanmış küçük bir mimari, uzun vadede büyük ve karmaşık sistemlere geçerken en sağlam dayanağınız olacaktır.