Nginx Reverse Proxy ve Nginx Proxy Manager Kurulumu

Reverse proxy (ters proxy), istemcilerden gelen istekleri alıp arka plandaki uygulama sunucularına ileten ve yanıtı geri döndüren bir ara katmandır. Tek bir giriş noktası, SSL sonlandırma ve yük dağıtımı sağlar. Nginx bu işi proxy_pass direktifiyle yapar. Nginx Proxy Manager (NPM) ise bu yapılandırmayı ve Let’s Encrypt SSL sertifikalarını şık bir web arayüzünden yönetmenizi sağlayan Docker tabanlı bir araçtır. Aşağıda hem elle Nginx yapılandırmasını hem de NPM’i, üretimde karşınıza çıkacak ayrıntılarıyla birlikte adım adım anlatıyorum.

Reverse proxy ile birden çok uygulamayı tek sunucuda düzenli yayınlamak için kök erişimine sahip bir VPS/sunucu idealdir; paylaşımlı hostingde 80/443 portlarını ve Docker’ı yönetemezsiniz.

Reverse Proxy Tam Olarak Ne Yapar?

Bir reverse proxy, dışarıdan bakıldığında “sunucunuzun yüzü”dür. İstemci sizin domaininize bağlanır, ancak isteğin arka planda hangi uygulamaya, hangi porta veya hangi konteynere gittiğini bilmez. Bu basit ara katman, pratikte birkaç işi aynı anda çözer:

• Tek giriş noktası: 80 ve 443 portlarını yalnızca Nginx dinler; arka plandaki uygulamalar 3000, 8000, 8080 gibi farklı portlarda kalır ve dışarıya hiç açılmaz.
• SSL sonlandırma: HTTPS şifre çözme işi Nginx’te yapılır, arka plandaki uygulama düz HTTP konuşur. Tek noktada sertifika yönetirsiniz.
• İsim bazlı yönlendirme: app.example.com bir konteynere, api.example.com başka bir konteynere gidebilir; hepsi aynı IP ve aynı sunucu üzerinde.
• Yük dağıtımı: Aynı uygulamanın birden çok kopyasını arkaya koyup istekleri aralarında bölüştürebilirsiniz.

Forward proxy ile karıştırmamak gerekir: forward proxy istemcinin kimliğini gizler (kullanıcı tarafında), reverse proxy ise sunucunun arka yapısını gizler. Bu yazıda tamamen ikincisinden bahsediyoruz.

Nginx ile Reverse Proxy Yapılandırması

Diyelim ki 8000 portunda çalışan bir uygulamanız var ve bunu 80 portundan domain ile yayınlamak istiyorsunuz. Nginx server bloğu şöyle olur:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost: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;
    }
}

Buradaki proxy_set_header satırları, arka plandaki uygulamanın gerçek istemci bilgisini doğru görmesini sağlar. Bunları atlarsanız uygulamanız tüm istekleri 127.0.0.1‘den geliyormuş gibi görür; loglama, oran sınırlama (rate limit) ve coğrafi engelleme işe yaramaz hâle gelir. X-Forwarded-Proto ise uygulamaya isteğin aslında HTTPS olduğunu söyler; bunu vermezseniz uygulama mutlak URL üretirken veya HTTPS yönlendirmesi yaparken sonsuz döngüye girebilir.

Değişiklikten sonra mutlaka nginx -t ile söz dizimini test edin, ardından systemctl reload nginx ile devreye alın. reload, restart‘tan farklı olarak açık bağlantıları kesmeden yapılandırmayı tazeler.

WebSocket ve Canlı Bağlantılar İçin Ek Ayar

Sohbet uygulamaları, canlı bildirim panelleri, Grafana, n8n gibi araçlar WebSocket kullanır. Standart proxy bloğu bu bağlantıları düşürür çünkü Nginx varsayılan olarak HTTP/1.0 ile konuşur ve Upgrade mekanizmasını desteklemez. WebSocket’i ayakta tutmak için server bloğunun dışına bir map ekleyip location içinde HTTP sürümünü yükseltmeniz gerekir:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

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

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
    }
}

Buradaki kritik nokta proxy_read_timeout satırı. Nginx, açık bir bağlantıda 60 saniye veri akmazsa bağlantıyı varsayılan olarak kapatır. Uzun ömürlü WebSocket bağlantılarında bunu 3600 saniyeye çekmek ve uygulamanızın bu süreden daha sık ping/pong göndermesini sağlamak, “bağlantı bir süre sonra kopuyor” şikâyetlerini ortadan kaldırır.

Birden Çok Sunucuya Yük Dağıtımı (upstream)

Trafik arttığında aynı uygulamayı birden fazla örnekte çalıştırıp istekleri aralarında bölüştürmek istersiniz. Bunun için upstream bloğu kullanılır:

upstream uygulama_havuzu {
    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;
    keepalive 32;
}

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://uygulama_havuzu;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
    }
}

Yöntem belirtmezseniz Nginx istekleri sırayla dağıtan round-robin kullanır. Uzun süren bağlantılar için least_conn (en az bağlantısı olan sunucuya gönder), oturum sürekliliği gerektiren uygulamalar için ip_hash daha uygundur. max_fails ve fail_timeout, bir sunucu hata verdiğinde Nginx’in onu bir süre devre dışı bırakıp diğerlerine yönelmesini sağlar; bu basit ayar tek bir uygulama örneği çöktüğünde sitenin ayakta kalmasını sağlar. keepalive ve proxy_http_version 1.1 birlikte kullanıldığında bağlantılar yeniden kullanılır ve gecikme düşer.

Nginx Proxy Manager (NPM) Kurulumu

Config dosyalarıyla uğraşmak istemiyorsanız, NPM’i Docker Compose ile kurabilirsiniz. NPM, perde arkasında yine Nginx’tir; siz arayüzden tıkladıkça o tıpkı yukarıdaki gibi config üretir. Önce bir docker-compose.yml oluşturun:

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'     # HTTP
      - '443:443'   # HTTPS
      - '81:81'     # Yonetim arayuzu
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Ardından docker compose up -d ile başlatın ve yönetim arayüzüne http://SUNUCU_IP:81 adresinden erişin. İlk açılışta konteynerin veritabanını hazırlaması birkaç dakika sürebilir; arayüz hemen gelmezse kısa bir süre bekleyip sayfayı yenileyin.

İlk Giriş ve SSL

NPM’in fabrika çıkışı giriş bilgisi e-posta admin@example.com, parola changeme‘dir; ilk girişten sonra bunları derhal değiştirin. Bu adımı atlamak, yönetim panelinizi internete açık ve herkesçe bilinen bir parolayla bırakmak demektir.

Bir site eklemek için arayüzde Hosts > Proxy Hosts > Add Proxy Host yolunu izleyin. Domain Names alanına yayınlayacağınız adı (örneğin app.example.com), Forward Hostname/IP alanına hedef konteyner adını ya da IP’yi, Forward Port alanına da uygulamanın portunu (örneğin 3000) girersiniz. Websockets Support kutusunu işaretlerseniz NPM yukarıda anlattığımız WebSocket ayarlarını sizin yerinize ekler. SSL sekmesinden Request a new SSL Certificate seçip Force SSL ve HTTP/2 Support‘u açtığınızda Let’s Encrypt sertifikası tek tıkla alınır ve otomatik yenilenir.

NPM mi, Elle Nginx mi? Hangi Durumda Hangisi

İkisi de aynı motoru kullandığı için “hangisi daha hızlı” sorusunun anlamı yok; fark yönetim biçiminde. Karar verirken şu tablo işinizi görür:

Pratik bir kural: Onlarca alt alan adını panelden hızlıca yönetmek, ekibe görsel kolaylık sunmak istiyorsanız NPM; özel oran sınırlama, gelişmiş önbellekleme, karmaşık rewrite kuralları gerekiyorsa elle Nginx daha rahat eder. Çoğu kişi ev/ofis lab ortamında NPM ile başlar, üretim yükü büyüdükçe kritik servisleri elle config’e taşır.

Güvenlik ve Dayanıklılık İçin Öneriler

• 80 ve 443 portları üretimde dışarıya açık olmalı; aksi hâlde Let’s Encrypt’in HTTP doğrulaması (challenge) başarısız olur ve SSL alınamaz.
• İlk girişten sonra admin@example.com / changeme bilgilerini hemen değiştirin; bu, en sık görülen ve en kolay sömürülen güvenlik açığıdır.
• Yönetim portunu (81) genel internete açmayın; mümkünse yalnızca VPN ya da güvenlik duvarı izinli IP üzerinden erişin.
• ./data ve ./letsencrypt klasörleri tüm proxy kayıtlarını ve sertifikaları tutar; bunları düzenli yedekleyin. Bu iki klasör elinizdeyse kurulumu dakikalar içinde başka sunucuda ayağa kaldırırsınız.
• Nginx ve NPM imajını güncel tutun. Reverse proxy katmanı internete bakan ilk satırdır; çıkan güvenlik yamalarını geciktirmeyin.
• Reverse proxy arkasındaki uygulamalar için gerçek istemci IP’sini iletmek üzere X-Forwarded-For ve X-Forwarded-Proto header’larını mutlaka doğru ayarlayın.

Tüm bunlara ek olarak, reverse proxy’nizin bulunduğu sunucunun ağ katmanında da korunaklı olması gerekir. Yoğun bir DDoS karşısında en iyi yapılandırılmış Nginx bile tek başına yetmez; bu noktada barındırma sağlayıcınızın altyapısı devreye girer. Alastyr tarafında sunucular, ağ katmanında Voxility tabanlı 1 Tbps üzeri kapasiteli L3-L4 anti-DDoS koruması ve İzmir’deki kendi veri merkezi üzerinden, Türkiye içi düşük gecikmeyle yayınlanır. Böylece proxy katmanınız uygulama trafiğini düzenlerken alt katmandaki hacimsel saldırılar ağ tarafında süzülür.

Sık Karşılaşılan Sorunlar ve Çözümleri

502 Bad Gateway: Nginx arka plandaki uygulamaya ulaşamıyordur. Hedef port doğru mu, uygulama gerçekten çalışıyor mu, Docker ağında konteyner adını doğru yazdınız mı kontrol edin. NPM kullanıyorsanız hedef olarak localhost değil konteynerin servis adını yazmanız gerekir.

SSL alınamıyor: Domainin A kaydı gerçekten sunucu IP’sine bakıyor mu? DNS henüz yayılmamışsa Let’s Encrypt doğrulaması başarısız olur. 80 portunun da açık olduğundan emin olun.

Sonsuz yönlendirme döngüsü: Genellikle X-Forwarded-Proto header’ı eksiktir; uygulama isteği HTTP sanıp tekrar HTTPS’e yönlendirir. Header’ı eklemek sorunu çözer.

Sıkça Sorulan Sorular

Reverse proxy ne işe yarar?

Tek giriş noktası, SSL sonlandırma, yük dağıtımı ve birden çok uygulamayı tek sunucuda yayınlama imkânı sağlar. Arka plandaki uygulamaların portlarını dışarıya açmadan domain üzerinden güvenle yayınlarsınız.

NPM mi yoksa elle Nginx mi tercih etmeliyim?

Görsel kolaylık, tek tıkla SSL ve çok sayıda alt alan adını panelden yönetmek için NPM uygundur. Özel oran sınırlama, gelişmiş önbellekleme ya da karmaşık rewrite kuralları gerekiyorsa elle Nginx yapılandırması daha fazla kontrol verir.

SSL otomatik mi alınıyor?

NPM ile evet. Domain doğru şekilde sunucu IP’sine yönlendirildiğinde Let’s Encrypt sertifikası arayüzden tek tıkla alınır ve süresi dolmadan otomatik yenilenir. 80 portunun açık olması şarttır.

Birden çok siteyi tek sunucuda yönetebilir miyim?

Evet. Her domain için ayrı bir Proxy Host (veya elle ayrı bir server bloğu) tanımlayarak tek sunucu ve tek IP üzerinde çok sayıda site ve uygulama yayınlayabilirsiniz.

WebSocket bağlantılarını destekler mi?

Evet. Elle yapılandırmada Upgrade ve Connection header’larını ekleyip proxy_http_version 1.1 kullanmanız, NPM’de ise Websockets Support kutusunu işaretlemeniz yeterlidir. Uzun bağlantılar için proxy_read_timeout süresini artırmayı unutmayın.

502 Bad Gateway hatası neden çıkar?

Nginx, arka plandaki uygulamaya ulaşamadığında bu hatayı verir. En sık nedenleri yanlış port, çalışmayan uygulama veya Docker ağında yanlış yazılmış konteyner adıdır.

Reverse proxy için paylaşımlı hosting yeterli mi?

Hayır. 80/443 portlarını yönetmek, Docker çalıştırmak ve özel Nginx config yazmak için kök erişimi gerekir. Bunun için VPS ya da fiziksel sunucu tercih edilmelidir.

NPM güvenli mi, üretimde kullanılır mı?

Varsayılan parolayı değiştirir, yönetim portunu (81) genele kapatır ve imajı güncel tutarsanız üretimde rahatlıkla kullanılır. Asıl risk yanlış yapılandırmadan, aracın kendisinden değil.

Yedekleme için hangi klasörleri saklamalıyım?

NPM kullanıyorsanız ./data ve ./letsencrypt klasörleri yeterlidir; bu ikisi tüm proxy kayıtlarınızı ve sertifikalarınızı içerir. Elle Nginx’te ise /etc/nginx altındaki config dosyalarını ve sertifika dizinlerini yedekleyin.