0850 302 60 70
BlogBilgi BankasıDestekÖdeme
Buyukweb
Nginx Reverse Proxy: Yapılandırma, SSL ve Yük Dengeleme
Ağ & Network

Nginx Reverse Proxy: Yapılandırma, SSL ve Yük Dengeleme

Nginx'i reverse proxy olarak yapılandırmayı, SSL/TLS termination, upstream sunucular ve yük dengeleme stratejilerini öğrenin.

Büyükweb Editör EkibiHosting, Sunucu ve Sistem Yönetimi Editörü9 dakika okuma

Nginx Reverse Proxy: Yapılandırma, SSL ve Yük Dengeleme

Nginx, dünyanın en yaygın kullanılan web sunucusu ve reverse proxy çözümüdür. Yüksek eşzamanlı bağlantı sayısı, düşük bellek kullanımı ve esnek yapılandırma seçenekleri ile uygulama önünde ters vekil sunucu (reverse proxy) olarak kurulan en yaygın yazılımdır. Bu rehberde Nginx'i sıfırdan reverse proxy olarak nasıl yapılandıracağınızı, SSL/TLS termination, upstream sunucu havuzu, yük dengeleme, cache ve rate limiting konularını detaylı şekilde öğreneceksiniz.

Reverse Proxy Nedir, Ne İşe Yarar?

Bir reverse proxy, istemci ile uygulama sunucularınız arasında konumlanan ve gelen istekleri arka plandaki backend sunuculara yönlendiren bir aracı katmandır. Forward proxy istemcinin tarafında çalışırken, reverse proxy sunucu tarafında çalışır.

Reverse proxy'nin temel avantajları:

  • SSL/TLS termination: Sertifikaları tek bir yerde yönetirsiniz; backend'ler düz HTTP konuşur
  • Yük dengeleme: Trafik birden fazla backend'e dağıtılır
  • Cache: Statik veya statik benzeri yanıtlar diskte tutulur
  • Güvenlik: Backend IP'lerini gizler, WAF ve rate limiting katmanı sağlar
  • Sıkıştırma: gzip / brotli bir kez uygulanır
  • HTTP/2 ve HTTP/3 sonlandırma: Backend HTTP/1.1 olsa da istemci modern protokolden yararlanır

Nginx Kurulumu

# Ubuntu/Debian
apt update && apt install nginx -y

# CentOS/RHEL/AlmaLinux/Rocky
dnf install epel-release -y
dnf install nginx -y

# Sürüm ve modül kontrolü
nginx -v
nginx -V 2>&1 | grep --color -E "configure|--with"

# Servis komutları
systemctl enable --now nginx
systemctl reload nginx     # Yapılandırmayı yeniden yükle (downtime yok)
nginx -t                   # Sözdizimi kontrolü (her reload öncesi şart)

İpucu: Türkiye lokasyonlu bir Linux sunucuda Nginx kurmak için Büyükweb'in Linux VDS sunucu paketleri tercih edilir; Tier 3 veri merkezinde 1 Gbps simetrik portla yüksek bant genişliği sunulur.

Temel Reverse Proxy Yapılandırması

# /etc/nginx/sites-available/app.example.com

upstream backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    keepalive 32;             # Backend'e açık kalan bağlantı havuzu
}

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

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name app.example.com;

    # SSL sertifikaları (Let's Encrypt yolu)
    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    # Modern SSL ayarları (Mozilla "intermediate" profil)
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    # Güvenlik başlıkları
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options DENY always;
    add_header X-Content-Type-Options nosniff always;
    add_header Referrer-Policy strict-origin-when-cross-origin always;

    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";          # keepalive için boş bırak
        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;

        # Zaman aşımı
        proxy_connect_timeout 5s;
        proxy_send_timeout    60s;
        proxy_read_timeout    60s;
    }
}

X-Forwarded-For, X-Forwarded-Proto ve X-Real-IP başlıkları olmadan backend uygulamanız gerçek istemci IP'sini ve protokolü göremez; özellikle WAF, fraud detection ve audit log'lar için kritiktir.

Yük Dengeleme Stratejileri

Nginx 5 ana yük dengeleme algoritması destekler. Her birinin uygun olduğu senaryo farklıdır.

# 1) Round Robin (varsayılan)
upstream backend_rr {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
    keepalive 32;
}

# 2) Least Connections (en az aktif bağlantısı olana yönlendir)
# WebSocket veya uzun süreli bağlantılar için ideal
upstream backend_lc {
    least_conn;
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

# 3) IP Hash (oturum kalıcılığı / sticky session)
# Kullanıcının her isteği aynı backend'e gider
upstream backend_ip {
    ip_hash;
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

# 4) Ağırlıklı (heterojen sunucular)
upstream backend_weighted {
    server 10.0.0.1:3000 weight=5;   # %50 trafik
    server 10.0.0.2:3000 weight=3;   # %30 trafik
    server 10.0.0.3:3000 weight=2;   # %20 trafik
}

# 5) Sağlık kontrolü ile failover
upstream backend_health {
    server 10.0.0.1:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:3000 backup;     # Yedek (diğerleri öldüğünde devreye girer)
    server 10.0.0.4:3000 down;       # Bakım modu
}

Hangi algoritma ne zaman?

Algoritma Uygun olduğu senaryo
Round Robin Eşdeğer backend'ler, stateless API
Least Conn WebSocket, uzun-poll, yavaş istek
IP Hash Oturum cookie'si yoksa, sticky session lazımsa
Weighted Farklı kapasiteli sunucular karışık
Backup Sıcak yedek mimarisi (active-passive)

SSL/TLS Termination ve Sertifika Yönetimi

Reverse proxy'de SSL'i tek bir yerde sonlandırırsınız. Backend uygulamalarınız HTTP üzerinden konuşur (ya da iç ağda kendi self-signed sertifikası ile mTLS yapar). Bu yaklaşım:

  • Sertifika yenileme operasyonel olarak çok kolay
  • Backend kodu sertifika lojiği bilmek zorunda değil
  • Cipher / protokol güncellemeleri merkezi yapılır
# Let's Encrypt ile ücretsiz sertifika (certbot)
apt install certbot python3-certbot-nginx -y
certbot --nginx -d app.example.com -d www.app.example.com

# Otomatik yenileme test
certbot renew --dry-run

Sertifika yenileme cron'u otomatik çalışır; yenileme sonrası systemctl reload nginx ile sıfır kesintiyle aktif olur.

Cache Yapılandırması

Statik içerik veya tekrar eden API yanıtlarını disk cache'inde tutarak backend'e yükü düşürebilirsiniz.

# /etc/nginx/nginx.conf
proxy_cache_path /var/cache/nginx levels=1:2
                 keys_zone=cache_zone:10m
                 max_size=1g
                 inactive=60m
                 use_temp_path=off;

server {
    location / {
        proxy_pass http://backend;
        proxy_cache cache_zone;
        proxy_cache_revalidate on;
        proxy_cache_min_uses 1;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503;
        proxy_cache_background_update on;
        proxy_cache_lock on;

        # Cache süreleri
        proxy_cache_valid 200 301 302 10m;
        proxy_cache_valid 404 1m;

        # Hangi başlıklarda HIT/MISS göster
        add_header X-Cache-Status $upstream_cache_status;

        # Cache'i atla
        proxy_cache_bypass $http_pragma $http_authorization $cookie_session;
        proxy_no_cache $http_pragma $http_authorization $cookie_session;
    }

    # Statik dosyalar
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        proxy_pass http://backend;
    }
}

use_stale özelliği sayesinde backend down olsa bile cached yanıt servis edilir — büyük operasyonel kazanç.

Rate Limiting ve DDoS Hafifletme

Nginx limit_req_zone direktifi ile L7 katmanında istek hızı sınırlaması yapabilirsiniz.

http {
    # Zone tanımları
    limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
    limit_req_zone $binary_remote_addr zone=api:10m   rate=60r/m;
    limit_req_zone $binary_remote_addr zone=general:10m rate=120r/m;

    # Eşzamanlı bağlantı sınırı
    limit_conn_zone $binary_remote_addr zone=addr:10m;
}

server {
    location /api/login {
        limit_req zone=login burst=3 nodelay;
        limit_req_status 429;
        proxy_pass http://backend;
    }

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

    location / {
        limit_req zone=general burst=50 nodelay;
        limit_conn addr 20;
        proxy_pass http://backend;
    }
}

Network seviyesi (L3-L4) DDoS için Nginx tek başına yetmez; veri merkezi seviyesinde scrubbing center gerekir. Türkiye lokasyonlu hizmet için fiziksel dedicated sunucu ve VDS paketlerimizde altyapı seviyesinde DDoS hafifletme bulunur.

WebSocket Proxy

Modern uygulamalar WebSocket veya Server-Sent Events kullanır. Nginx için Upgrade ve Connection başlıkları kritiktir.

upstream websocket {
    server 127.0.0.1:3000;
}

server {
    location /ws/ {
        proxy_pass http://websocket;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;

        # WebSocket için uzun read timeout
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

HTTP/2 ve HTTP/3 (QUIC)

Nginx 1.25+ ile HTTP/3 (QUIC) desteği gelir. listen 443 quic reuseport; yapılandırması ve alt-svc başlığı ile aktif edilir.

server {
    listen 443 ssl http2;
    listen 443 quic reuseport;        # Nginx 1.25+
    listen [::]:443 quic reuseport;

    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    # ... ssl ve proxy_pass ayarları
}

HTTP/3 mobil ağlarda paket kaybı senaryolarında HTTP/2'ye göre belirgin hız artışı sağlar.

Mikroservis Mimarisinde Reverse Proxy

Birden fazla mikroservisin önünde Nginx location ile path-based routing yapar:

server {
    location /auth/   { proxy_pass http://auth_service:4000/; }
    location /users/  { proxy_pass http://users_service:4001/; }
    location /orders/ { proxy_pass http://orders_service:4002/; }
    location /api/    { proxy_pass http://api_gateway:5000/; }

    # Statik frontend
    location / {
        root /var/www/frontend;
        try_files $uri $uri/ /index.html;
    }
}

İpucu: Path-based routing yerine subdomain-based routing (auth.example.com, api.example.com) operasyonel olarak daha temiz olur — her servis için ayrı sertifika ve cookie scope'u tanımlayabilirsiniz.

Performans Tuning

# /etc/nginx/nginx.conf
worker_processes auto;                    # CPU çekirdek sayısı kadar
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;              # Worker başına eşzamanlı bağlantı
    multi_accept on;
    use epoll;                            # Linux için en performanslı
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    keepalive_requests 1000;

    # gzip
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript application/xml+rss application/atom+xml image/svg+xml;

    # brotli (modülü yüklüyse)
    # brotli on;
    # brotli_comp_level 6;
    # brotli_types text/plain text/css application/json application/javascript;

    # Open file cache
    open_file_cache max=200000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;
}

Yüksek trafikli bir API gateway için worker_connections × worker_processes formülü ile teorik maksimum eşzamanlı bağlantı hesaplanır. 8 vCPU bir sunucuda 8 × 4096 = 32.768 eşzamanlı bağlantı potansiyeli vardır; gerçek rakam dosya tanımlayıcı (ulimit) ve kernel parametreleri ile sınırlıdır.

Sık Karşılaşılan Hatalar

Hata Olası Sebep Çözüm
502 Bad Gateway Backend kapalı veya yanıt vermiyor Backend log'larını kontrol; upstream server adresleri doğru mu?
504 Gateway Timeout Backend yavaş proxy_read_timeout artır; backend'i optimize et
413 Request Entity Too Large Yükleme boyutu limit aşıyor client_max_body_size 100M; ekle
499 Client Closed İstemci yanıt beklerken bağlantıyı kapattı Genelde mobil ağ; backend'de işlem tamam olabilir
SSL_handshake_timeout Yanlış sertifika veya cipher nginx -t + openssl s_client -connect host:443 ile test
upstream sent too big header Backend cookie/header çok büyük proxy_buffer_size 16k; proxy_buffers 4 16k;

Production Checklist

  • nginx -t sözdizimi temiz
  • SSL Labs testinde A veya A+ skor
  • HSTS preload kaydı
  • X-Forwarded-* başlıkları backend'e geçiyor
  • Rate limit kuralları kritik endpoint'lere uygulandı
  • Log rotate yapılandırıldı (logrotate)
  • Access log + error log monitoring sisteminde (ELK / Loki / Grafana)
  • Sertifika otomatik yenileme cron'u kontrollü
  • Backend health check (passive max_fails veya active modülü)
  • graceful reload akışı (systemctl reload nginx) test edildi
  • Kritik domain'ler için CT log monitoring (Certificate Transparency)

Sık Sorulan Sorular

Nginx mi HAProxy mi tercih etmeliyim?

HAProxy, saf TCP/HTTP yük dengeleme için keskin bir araçtır ve gözlemlenebilirlik (stats sayfası, runtime API) konusunda öndedir. Nginx ise yük dengeleme + statik servis + cache + WAF + image processing gibi çok yetenekli bir HTTP sunucusudur. Tek tek araçtansa Nginx pek çok ihtiyaç için tek başına yeterlidir.

Nginx Plus ücretli sürümünü almak gerekir mi?

Çoğu senaryoda Nginx open-source yeter. Aktif sağlık kontrolü (active health checks), runtime API ve gelişmiş yük dengeleme algoritmaları (least_time, random with two choices) gerekiyorsa Plus mantıklı olur. Ücretsiz alternatif: nginx-extras paketi + manuel health check script'leri.

Yük dengeleme için kaç sunucu gerek?

En az 2 backend (high-availability için), aktif kullanım %70 altında olmalı. Trafik 2× artarsa otomatik yatay ölçeklendirme şansınız var demektir. Kapasitenizi artırmak için Türkiye lokasyonlu VDS sunucu paketleri ile dakikalar içinde yeni backend ekleyebilirsiniz.

Nginx'i Cloudflare arkasında kullanırken ne değişir?

X-Forwarded-For yerine CF-Connecting-IP başlığı gerçek istemci IP'sini taşır. real_ip_header CF-Connecting-IP; ve set_real_ip_from ile Cloudflare ağ aralıklarını tanımlamanız gerekir; aksi halde tüm istekler Cloudflare IP'lerinden geliyor görünür ve rate limit yanlış çalışır.

Reverse proxy log'larını nasıl analiz edebilirim?

access_log formatına $request_time, $upstream_response_time ve $upstream_addr ekleyin. GoAccess, ELK Stack veya basit awk/zcat zincirleri ile gecikme ve hata analizleri yapabilirsiniz. Production'da merkezi log toplama (Loki, OpenObserve) önerilir.

İlgili Büyükweb Hizmetleri

Ağ altyapısı, VPN ve proxy ihtiyaçlarınız için Türkiye lokasyonlu Büyükweb hizmetleri:

Sorularınız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.

Ağ & Network İlgili Hizmetlerimiz

Bu yazıda anlatılan teknik konuyu profesyonel altyapıyla deneyimleyin

Proxy Paketleri

Türkiye SOCKS5 / HTTPS proxy

İncele

VPN Paketleri

Türkiye OpenVPN sabit IP

İncele

Oyun VPN

Metin2/KO/SRO için VPN

İncele

Sunucu Barındırma

Tier 3 colocation

İncele

Etiketler:

#nginx#reverse proxy#ssl#yük dengeleme#cache#web sunucu

Bu yazıyı paylaş

TwitterLinkedInWhatsApp

Benzer Yazılar

Metin2 Proxy Kurulum: Adım Adım Detaylı Rehber

Metin2 Proxy Kurulum: Adım Adım Detaylı Rehber

9 dk okuma
Knight Online USKO Proxy Ayarları: Detaylı Rehber

Knight Online USKO Proxy Ayarları: Detaylı Rehber

10 dk okuma
Silkroad Online SBot/SSEL Proxy Kurulum Rehberi

Silkroad Online SBot/SSEL Proxy Kurulum Rehberi

11 dk okuma