Nginx Reverse Proxy Nedir? Kurulum ve Kullanım Rehberi

Nginx reverse proxy, istemciden gelen HTTP veya HTTPS isteklerini arka plandaki uygulama sunucularına ileten, yanıtı alıp tekrar istemciye döndüren bir ara katmandır. Tek bir alan adının arkasında Node.js, Python, PHP, Go, Java veya container tabanlı servisleri çalıştırmak istediğinizde çok işe yarar. Bu yapı sayesinde uygulamanız doğrudan internete açılmaz, SSL yönetimi tek noktada toplanır, port karmaşası azalır ve gerektiğinde yük dengeleme ya da önbellekleme eklenebilir.

Nginx'in resmi dokümantasyonunda ters proxy kullanımı, HTTP sunucularına istek geçirme, başlıkları değiştirme ve yanıtları tamponlama gibi temel başlıklarla açıklanır. NGINX reverse proxy dokümantasyonu özellikle proxy_pass, proxy_set_header ve buffer davranışlarını anlamak için iyi bir kaynaktır. Ayrıca Nginx'in açık kaynak dokümantasyonu, reverse proxy uygulamasının HTTP, HTTPS, FastCGI, uwsgi, SCGI, memcached ve gRPC tarafında yük dengeleme ile birlikte kullanılabildiğini belirtir. Nginx load balancing dokümantasyonu

Reverse proxy nedir, ne işe yarar?

Reverse proxy, istemci ile uygulama sunucusu arasına yerleşen bir ağ bileşenidir. Kullanıcı tarayıcıya example.com yazdığında isteği önce Nginx karşılar. Nginx isteğin yoluna, alan adına, protokolüne veya başlıklarına bakarak bunu arka plandaki uygun servise iletir. Kullanıcı çoğu zaman gerçek uygulama portunu, uygulamanın hangi dilde yazıldığını veya hangi makinede çalıştığını bilmez.

Forward proxy ile reverse proxy sık karıştırılır. Forward proxy, istemci adına dış dünyaya çıkar. Reverse proxy ise sunucu tarafında durur ve dış dünyadan gelen istekleri içerideki servislere dağıtır. MDN'in HTTP proxy açıklaması da reverse proxy'nin forward proxy'nin ters yönlü karşılığı olduğunu, istemci yerine hedef sistemlerin önünde konumlandığını anlatır. MDN proxy servers and tunneling

Bu modelin pratik faydaları nettir: uygulamalarınızı farklı portlarda çalıştırabilir, tek alan adı altında farklı servislere yol verebilir, SSL sertifikalarını tek yerde yönetebilir, arka uç servisleri internete kapalı tutabilir ve bakım sırasında yönlendirmeyi değiştirebilirsiniz.

Nginx reverse proxy neden tercih edilir?

Nginx reverse proxy mimarisinin yaygın olmasının birkaç nedeni vardır. Nginx hafif çalışır, statik dosya servisinde başarılıdır, istek yönlendirmeyi sade direktiflerle yapar ve yüksek eş zamanlı bağlantılarda verimli davranır. Resmi Nginx sitesinde proje, HTTP web sunucusu, reverse proxy, içerik önbelleği, load balancer, TCP/UDP proxy ve mail proxy olarak tanımlanır. nginx.org

Bir uygulama geliştirirken çoğu framework kendi geliştirme sunucusunu getirir. Örneğin servisiniz 127.0.0.1:3000, 127.0.0.1:8000 veya bir Unix socket üzerinde çalışabilir. Bu uygulama sunucusunu doğrudan internete açmak yerine Nginx'i öne almak daha düzenli bir mimari sağlar. Nginx dış bağlantıyı karşılar, gerekirse statik dosyaları kendisi sunar, dinamik istekleri ise uygulamaya iletir.

Bu yapı özellikle sanal sunucu üzerinde birden fazla servis çalıştıran kullanıcılar için kullanışlıdır. Root erişiminizin olduğu bir VPS veya VDS üzerinde Nginx, uygulama süreci, veritabanı ve güvenlik duvarı ayarlarını aynı mimari içinde yönetebilirsiniz. SSH ile bağlantı adımlarına yeniyseniz SSH nasıl bağlanılır rehberi kurulum öncesi temel erişim tarafını netleştirir.

Kurulum öncesi gereksinimler ve hazırlıklar

Kuruluma başlamadan önce sisteminizi sade bir listeyle kontrol edin. Buradaki örnekler Ubuntu veya Debian tabanlı bir sunucuya göre verilmiştir, ancak temel mantık çoğu Linux dağıtımında aynıdır.

1. Alan adı: DNS A kaydı sunucunuzun genel IP adresine yönlenmiş olmalı.
2. Sunucu erişimi: SSH ile root veya sudo yetkili kullanıcı erişiminiz bulunmalı.
3. Çalışan backend: Uygulamanız yerelde bir portta cevap vermeli, örneğin 127.0.0.1:3000.
4. Güvenlik duvarı: HTTP için 80, HTTPS için 443 portu açık olmalı.
5. SSL planı: Sertifika kurulumu için alan adının doğru sunucuya çözülmesi gerekir.

Önce uygulamanın gerçekten çalıştığını doğrulayın. Sunucu içinde şu test yapılabilir:

curl -I http://127.0.0.1:3000

Yanıt alamıyorsanız sorun Nginx tarafında değil, uygulama servisinde, portta, firewall kuralında veya bind adresindedir. Uygulama yalnızca 127.0.0.1 dinliyorsa bu çoğu reverse proxy senaryosu için uygundur, çünkü dış erişimi Nginx karşılayacaktır. Ancak uygulama farklı bir container ağında çalışıyorsa doğru IP veya servis adını kullanmanız gerekir.

Temel Nginx reverse proxy yapılandırması

Önce Nginx'i kurun ve servisin çalıştığını kontrol edin:

sudo apt update
sudo apt install nginx
sudo systemctl enable nginx
sudo systemctl status nginx

Ardından alan adınız için yeni bir site dosyası oluşturun. Örnekte alan adı example.com, uygulama portu 3000 kabul edilmiştir.

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

Temel yapılandırma şu şekilde olabilir:

server {
    listen 80;
    server_name example.com www.example.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;
    }
}

Bu dosyayı etkinleştirmek için sembolik bağlantı oluşturun, yapılandırmayı test edin ve Nginx'i yeniden yükleyin:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t
sudo systemctl reload nginx

proxy_pass direktifi, isteğin hangi backend'e gönderileceğini belirler. Resmi dokümantasyona göre bu direktif bir location bloğu içinde kullanılır ve hedef bir IP, alan adı veya port içerebilir. URI eklenip eklenmemesi de yönlendirilen path davranışını değiştirir. Bu nedenle proxy_pass http://127.0.0.1:3000; ile proxy_pass http://127.0.0.1:3000/; arasındaki farkı test etmeden canlı sisteme taşımayın.

SSL, yönlendirme ve header ayarları

Nginx reverse proxy kurulumunda SSL çoğu zaman Nginx üzerinde sonlandırılır. Yani tarayıcı ile Nginx arasındaki trafik HTTPS olur, Nginx ile yerel uygulama arasındaki trafik ise aynı makinede HTTP kalabilir. Bu, uygulamanın SSL ayrıntılarıyla uğraşmasını azaltır. SSL sertifikası alma sürecini ayrıca incelemek isterseniz SSL sertifikası nasıl alınır rehberi ve SSL sertifikaları sayfası yardımcı olur.

HTTP'den HTTPS'ye yönlendirme için genellikle 80 portunda ayrı bir blok kullanılır:

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.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

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

Header ayarları uygulamanın gerçek istemci bilgilerini anlamasını sağlar. Host, uygulamanın hangi alan adıyla çağrıldığını görmesine yardım eder. X-Real-IP istemcinin IP adresini taşır. X-Forwarded-For, zincirde birden fazla proxy varsa önceki IP'leri de listeleyebilir. X-Forwarded-Proto, uygulamaya isteğin dışarıdan HTTP mi HTTPS mi geldiğini bildirir.

WebSocket kullanan uygulamalarda ek başlıklar gerekir. Aksi halde bağlantı açılır gibi görünüp anlık bildirim, canlı sohbet veya terminal ekranı çalışmayabilir:

location /socket/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Yaygın hatalar ve test yöntemleri

Reverse proxy sorunlarında en hızlı yol hatayı katmanlara ayırmaktır. Önce DNS, sonra Nginx, sonra backend, sonra uygulama logları incelenmelidir. Aşağıdaki tablo sık görülen belirtileri ve kontrol noktalarını özetler.

Yapılandırma sözdizimi için her değişiklikten sonra şu komutu çalıştırın:

sudo nginx -t

Canlı log takibi için iki terminal açabilirsiniz. Birinde erişim, diğerinde hata loglarını izleyin:

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Alan adı henüz DNS'e yayılmadıysa test için curl ile Host başlığı gönderebilirsiniz:

curl -I -H "Host: example.com" http://SUNUCU_IP_ADRESI

Nginx reverse proxy yapılandırmasında 502 hatası en sık karşılaşılan problemdir. Bu hata Nginx'in isteği aldığını, ancak upstream sunucudan geçerli yanıt alamadığını gösterir. Yanlış port, kapalı uygulama servisi, Unix socket izinleri, container ağ hatası veya uygulamanın yalnızca farklı bir IP üzerinde dinlemesi buna yol açabilir.

Performans ve güvenlik için ipuçları

Temel kurulum çalıştıktan sonra performans ve güvenlik ayarlarını kademeli ilerletin. Her ayarı aynı anda değiştirmek yerine önce ölçün, sonra değişiklik yapın, ardından tekrar ölçün.

Timeout ve büyük dosya ayarları

Uzun süren API işlemleri, dosya yükleme ekranları veya rapor üretimi yapan uygulamalar için timeout değerlerini düzenlemek gerekebilir:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 30s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;
    client_max_body_size 50m;
}

client_max_body_size çok düşükse dosya yükleme sırasında 413 hatası alırsınız. Çok yüksek bırakılırsa gereksiz kaynak tüketimi riski doğar. Uygulamanızın gerçek ihtiyacına göre sınır belirleyin.

Buffer ve önbellek davranışı

Nginx, proxied sunuculardan gelen yanıtları varsayılan olarak buffer'lar. Resmi dokümantasyon, bu davranışın yavaş istemcilerde upstream sunucunun gereksiz beklemesini azaltabildiğini belirtir. Ancak canlı akış, server-sent events veya uzun süre açık kalan bağlantılarda buffer davranışını özel olarak ele almak gerekebilir.

location /events/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_buffering off;
}

Upstream ile basit yük dengeleme

Bir uygulamanın birden fazla kopyasını çalıştırıyorsanız upstream bloğu kullanabilirsiniz. Nginx açık kaynak sürümünde HTTP yük dengeleme için temel yöntemler resmi dokümantasyonda açıklanır.

upstream app_backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

server {
    listen 80;
    server_name example.com;

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

Güvenlik sıkılaştırma

• Backend uygulamasını mümkünse yalnızca 127.0.0.1 üzerinde dinletin.
• Sunucu firewall'ında dışarıya yalnızca gerekli portları açın.
• Varsayılan site dosyasını kaldırın veya etkisizleştirin.
• Nginx ve işletim sistemi paketlerini düzenli güncelleyin.
• Uygulama admin panellerini IP kısıtı, ek kimlik doğrulama veya VPN ile koruyun.
• Loglarda kişisel veri ve hassas token tutulmadığından emin olun.

Bulutova'nın sanal sunucu tarafında Linux seçenekleri, root erişimi, NVMe depolama ve ihtiyaca göre ölçeklendirme gibi imkanlar bulunduğu için bu tür kurulumlarda Nginx, uygulama servisi ve güvenlik duvarı ayarlarını aynı sunucu üzerinde esnek biçimde yönetebilirsiniz. Trafik arttığında mimariyi tek sunucudan birden fazla backend'e taşımanız da daha planlı olur.

Kısa toparlama

Nginx reverse proxy, modern web uygulamalarında trafiği düzenlemek, SSL'i merkezi yönetmek, gerçek uygulama portlarını gizlemek ve gerektiğinde yük dengeleme yapmak için güçlü bir yöntemdir. Sağlıklı bir kurulum için önce backend servisinin yerelde çalıştığını doğrulayın, ardından proxy_pass ve header ayarlarını sade biçimde ekleyin. SSL, WebSocket, timeout, buffer ve log kontrollerini ihtiyaca göre kademeli yapılandırın. Her değişiklikten sonra nginx -t, curl ve log takibi ile sistemi test ederseniz hataları büyümeden yakalarsınız.