Arka planda çalışan uygulama sunucularını dış dünyaya tek bir kapıdan açmak, modern web mimarisinin temel taşlarından biri. Nginx, düşük bellek tüketimi ve olay tabanlı mimarisi sayesinde bu işin en çok tercih edilen araçlarından. Aşağıda kurulumdan ince ayara kadar gerçek bir yapılandırmanın nasıl kurgulandığını ele alıyoruz.

Reverse Proxy Ne İşe Yarar?

Reverse proxy, istemciden gelen istekleri karşılayıp bunları arkadaki bir veya birden fazla uygulama sunucusuna yönlendiren ara katmandır. İstemci yalnızca Nginx'i görür; Node.js, Python (Gunicorn/Uvicorn), Java ya da PHP-FPM süreçleri arka tarafta gizli kalır. Bu yapının sağladığı başlıca avantajlar şunlardır:

  • SSL sonlandırma: TLS şifre çözme işini tek noktada toplar, uygulama sunucusunu bu yükten kurtarır.
  • Yük dağıtımı: Birden fazla backend arasında istekleri paylaştırır.
  • Önbellekleme ve sıkıştırma: Statik içeriği ve yanıtları cache'leyerek backend'e giden trafiği azaltır.
  • Güvenlik: Backend portlarını doğrudan internete açmadan, rate limit ve erişim kuralları uygulamanıza imkân verir.

Nginx Kurulumu

Çoğu dağıtımda Nginx depolarda hazır gelir. Debian/Ubuntu tarafında kurulum ve servis kontrolü oldukça yalındır:

sudo apt update
sudo apt install -y nginx
sudo systemctl enable --now nginx
sudo nginx -v

RHEL, AlmaLinux veya Rocky Linux kullanıyorsanız paket yöneticisi dnf olur:

sudo dnf install -y nginx
sudo systemctl enable --now nginx
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

Kaynak yoğunluğu yüksek projelerde proxy katmanını ayrı bir makinede tutmak isteyebilirsiniz; ölçeklenebilir projeleriniz için hızlıca devreye alabileceğiniz sanal sunucu çözümleriyle Nginx'i izole bir ortamda barındırmak performans açısından genellikle daha öngörülebilir sonuç verir.

Temel Proxy Yapılandırması

Yapılandırmayı /etc/nginx/sites-available/ altında ayrı bir dosyada tutmak (RHEL ailesinde /etc/nginx/conf.d/*.conf) bakımı kolaylaştırır. Arka planda 3000 portunda çalışan bir uygulamaya yönlendiren sade bir örnek:

server {
    listen 80;
    server_name uygulama.bogahost.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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;
    }
}

Buradaki X-Forwarded-* başlıkları kritiktir; aksi halde uygulama tüm istemcileri 127.0.0.1 olarak görür ve gerçek IP ile şema bilgisi kaybolur. Dosyayı etkinleştirip yapılandırmayı sınamak için:

sudo ln -s /etc/nginx/sites-available/uygulama.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Upstream ile Yük Dağıtımı

Tek bir backend yerine birden çok süreç çalıştırıyorsanız upstream bloğu işleri toparlar. Nginx varsayılan olarak round-robin uygular; oturum tutarlılığı gerekiyorsa ip_hash ya da ağırlık (weight) verebilirsiniz:

upstream uygulama_backend {
    least_conn;
    server 127.0.0.1:3000 weight=2;
    server 127.0.0.1:3001;
    server 10.0.0.12:3000 backup;
}

server {
    listen 80;
    server_name uygulama.bogahost.com;
    location / {
        proxy_pass http://uygulama_backend;
        proxy_set_header Host $host;
    }
}

least_conn direktifi, açık bağlantı sayısı en düşük olan sunucuya yönlendirir; uzun süreli isteklerin ağırlıkta olduğu servislerde round-robin'e göre çoğu durumda daha dengeli bir dağılım sağlar. backup olarak işaretlenen sunucu yalnızca diğerleri devre dışı kaldığında devreye girer.

WebSocket ve Akış Trafiği

Gerçek zamanlı uygulamalar (sohbet, canlı bildirim, panel arayüzleri) WebSocket üzerinden çalışır. Bağlantının yükseltilebilmesi için Upgrade ve Connection başlıklarını elle iletmek gerekir:

location /ws/ {
    proxy_pass http://uygulama_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

Uzun süre açık kalan bağlantılarda proxy_read_timeout değerini yükseltmek, varsayılan 60 saniyenin bağlantıyı erken kesmesini engeller.

SSL Sonlandırma ve HTTPS

TLS'i proxy katmanında bitirmek en yaygın yaklaşımdır. Let's Encrypt sertifikalarını Certbot ile alıp Nginx'e otomatik tanımlatabilirsiniz:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d uygulama.bogahost.com
sudo systemctl status certbot.timer

Certbot, 443 portunu dinleyen bir server bloğu ekler ve 80'den 301 yönlendirme kurar. Sertifika yenileme certbot.timer ile otomatik yürür; üretim ortamında yenilemeyi sudo certbot renew --dry-run ile önceden doğrulamakta fayda var. Yüksek trafikli ya da yasal saklama gereksinimi olan kurulumlarda TLS oturumlarının tek bir kasada toplandığı, donanım kaynaklarını paylaşmadığınız bir fiziksel sunucu üzerinde reverse proxy mimarisi gecikme ve izolasyon açısından elinizi rahatlatır.

Bogahost Önerisi: Proxy ve backend'i ayrı süreçlerde tutuyorsanız proxy_buffering ve proxy_buffer_size ayarlarını yük testiyle netleştirin; büyük yanıt gövdelerinde tampon değerlerini körlemesine artırmak bellek tüketimini hızla şişirebilir.

Performans ve Zaman Aşımı Ayarları

Varsayılanlar çoğu senaryoda iş görür, ancak gerçek trafikte ince ayar fark yaratır. Aşağıdaki tablo sık dokunulan direktifleri ve tipik kullanım amaçlarını özetliyor:

DirektifVarsayılan (yaklaşık)İşlevi
proxy_connect_timeout60sBackend'e bağlanma süresi sınırı
proxy_read_timeout60sYanıt beklenen azami süre
keepalivetanımsızUpstream'e açık tutulan bağlantı sayısı
proxy_bufferingonYanıtın tamponlanıp tamponlanmayacağı
gzipoffYanıt sıkıştırması

Upstream tarafında kalıcı bağlantı havuzu açmak, her istekte yeni TCP el sıkışması yapma maliyetini düşürür:

upstream uygulama_backend {
    server 127.0.0.1:3000;
    keepalive 32;
}
server {
    location / {
        proxy_pass http://uygulama_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

Burada Connection başlığını boşaltmak, keepalive'in çalışabilmesi için şarttır; aksi halde Nginx her yanıttan sonra bağlantıyı kapatır ve bağlantı havuzunun anlamı kalmaz.

Statik varlıkları backend'e hiç uğratmadan Nginx'in doğrudan sunması da büyük kazanç sağlar. Görselleri, CSS ve JavaScript dosyalarını ayrı bir location bloğuyla diskten okutup uzun süreli önbellek başlığı eklemek, uygulama süreçlerini gereksiz yükten arındırır:

location ~* \.(?:css|js|jpg|jpeg|png|gif|svg|woff2)$ {
    root /var/www/uygulama/public;
    expires 30d;
    add_header Cache-Control "public, immutable";
    access_log off;
}

Sıkıştırmayı da unutmayın; gzip on; ile birlikte gzip_types text/css application/javascript application/json; satırını http bloğuna eklemek, metin tabanlı yanıtların boyutunu çoğu durumda hatırı sayılır ölçüde küçültür.

Sık Yapılan Hatalar

Devreye alma sırasında en çok karşılaşılan tökezleme noktaları genellikle birbirine benzer:

  • 502 Bad Gateway: Backend ayakta değil ya da yanlış portu dinliyor; ss -tlnp ile kontrol edin.
  • Yanlış IP loglama: X-Forwarded-For iletilmiyor veya backend bu başlığa güvenecek şekilde ayarlanmamış.
  • SELinux engeli: RHEL ailesinde setsebool -P httpd_can_network_connect on çalıştırmadan proxy bağlantıları reddedilebilir.
  • Sonsuz yönlendirme: Backend HTTPS bekliyor ama X-Forwarded-Proto gönderilmiyor.

Özetle

Sağlam bir reverse proxy, doğru başlıkların iletilmesi, upstream havuzunun makul yapılandırılması ve TLS'in tek noktada sonlandırılmasıyla başlar. Yapılandırmayı her değişiklikten sonra nginx -t ile sınamayı alışkanlık haline getirin; küçük bir yazım hatası bile tüm trafiği durdurabilir. Bu temeli kurduğunuzda önbellekleme, rate limiting ve gözlemlenebilirlik gibi katmanları üzerine eklemek çok daha kolay olur.

Reklam Alanı

İçerik Altı (728x90)

Etiketler:
sunucu SSL certbot nginx Reverse Proxy Upstream Yük Dağıtımı
İlgili İçerikler

Yorumlar (0)

Henüz yorum yapılmamış. İlk yorumu siz yapın!

Yorum Yap

Maksimum 2000 karakter

İlgili Yazılar