Bir web uygulamasını kendi bilgisayarınızda çalıştırırken adresin sonuna bir port numarası yazmanız yeterli olabilir. Uygulamayı kullanıcılarla buluşturduğunuzda ise alan adı, bağlantı güvenliği, birden fazla servis ve hata takibi gibi konular devreye girer. Reverse proxy, yani ters vekil sunucu, bu trafiğin uygulamalara ulaşmadan önce geçtiği bir katman olarak kullanılabilir.
Bu yazıda Nginx üzerinden temel yönlendirme mantığını inceleyecek, küçük bir proje için örnek yapılandırmayı okuyacağız. Örnek, yerel geliştirme senaryosuna yöneliktir; eksiksiz bir üretim kurulumu değildir ve burada çalıştırılarak test edilmemiştir.
Reverse proxy nasıl çalışır?
İstemci isteği ters vekil sunucuya gönderir. Bu sunucu isteği ilgili arka uç servisine iletir, aldığı yanıtı istemciye döndürür. Kullanıcı böylece uygulama süreçlerinin ayrı adreslerini bilmeden tek bir giriş noktası üzerinden hizmet alabilir. Nginx’in resmî ters vekil rehberi, bu yönlendirmeyi ve arka uca gönderilen başlıkların düzenlenmesini açıklar.
Örnek bir ekip paneli düşünelim. Panelin API’si aynı makinede 3000 portunda çalışıyor, ziyaretçiler ise alan adı üzerinden geliyor. Nginx gelen istekleri bu API’ye aktarabilir. Daha sonra ayrı bir raporlama servisi eklendiğinde, yönlendirme kuralları uygun biçimde genişletilebilir.
Bu örnekte önemli tasarım kararı, dışarıya açılan adreslerle içeride çalışan servis adreslerini birbirinden ayırmaktır. Bir servisin portu değiştiğinde bütün kullanıcıların yeni adres öğrenmesi yerine, giriş noktasındaki eşlemenin güncellenmesi yeterli olabilir. Elbette bunun için alan adı ve ağ erişimi de doğru yapılandırılmalıdır.
Basit bir Nginx yapılandırması
Aşağıdaki örnekte Nginx ile uygulamanın aynı makinede çalıştığı varsayılıyor. Uygulama yalnızca 127.0.0.1:3000 adresini dinliyor. Yapılandırma, mevcut Nginx dosyasındaki http bağlamına yerleştirilecek bir server bloğunu gösteriyor:
server {
listen 127.0.0.1:8080;
server_name localhost;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Tarayıcıdan yerel 8080 portuna gelen istek, 3000 portundaki uygulamaya aktarılır. Bu yapılandırma HTTPS sağlamaz; örneği kendi bilgisayarınızda yönlendirme mantığını anlamak için düşünün. Gerçek alan adında kullanım, sertifika ve ağ ayarlarıyla birlikte ayrı değerlendirilmelidir.
Nginx proxy modülü belgesinde açıklanan proxy_set_header, arka uca gönderilen başlıkları ayarlamaya yarar. Örneğimizde Host bilgisi ve isteğin Nginx’e ulaşırken kullandığı şema aktarılıyor. Arka uç uygulamasının bu başlıklara hangi vekillerden geldiğinde güveneceği ayrıca belirlenmelidir.
proxy_pass sonundaki eğik çizgi neden önemli?
Bir API’yi /api/ yolunun arkasına yerleştirdiğinizi varsayalım. Basit bir önek eşleşmesinde proxy_pass http://127.0.0.1:3000; yazılmasıyla proxy_pass http://127.0.0.1:3000/; yazılması aynı sonucu vermeyebilir. İkinci biçimde bir URI bölümü bulunduğundan, eşleşen konum öneki değiştirilebilir.
Örneğin location /api/ altında sonu eğik çizgili hedef kullanıldığında /api/gorevler isteği arka uca /gorevler olarak iletilebilir. Bu açıklama basit önek senaryosu içindir; düzenli ifadeler, yeniden yazma kuralları ve değişkenler eklenince davranışı ilgili belgeye göre değerlendirin.
Ekip panelimizde uygulamanın beklediği yol zaten /api/gorevler ise öneki kaldırmak hata yaratır. Buna karşılık uygulama yalnızca /gorevler bekliyorsa kaldırmak istenen davranış olabilir. Kararı, “hangi örneği kopyaladım?” sorusuyla değil, arka ucun beklediği sözleşmeyle verin.
Yük dengeleme ile ilişkisi nedir?
Ters vekil tek bir uygulamaya yönlendirme yapabilir. Yük dengeleme ise isteklerin birden fazla arka uç arasında dağıtılmasıyla ilgilidir. Nginx’in HTTP yük dengeleme belgesi, sunucu gruplarını ve dağıtım yöntemlerini açıklar. Varsayılan yöntem round-robin yaklaşımıdır; farklı ihtiyaçlar için başka yöntemler de bulunur.
Örnek panelimizin iki uygulama kopyasıyla çalıştığını düşünelim. Bir kullanıcı ilk isteğinde birinci kopyaya, sonraki isteğinde ikinciye ulaşabilir. Oturum verisi yalnızca ilk sürecin belleğinde tutuluyorsa uygulama davranışı bozulabilir. Bu, yönlendirme katmanı eklenmeden önce de düşünülmesi gereken bir uygulama mimarisi kararıdır.
Benzer biçimde dosya yüklemeleri yalnızca bir makinenin yerel diskinde kalıyorsa diğer kopya aynı dosyaya erişemeyebilir. Örnek projemizde ikinci kopyayı açmadan önce oturum, yüklenen dosyalar ve arka plan işleri için ortak çalışma kurallarını yazmak gerekir. Trafiği dağıtmak, bu verileri kendiliğinden eşitlemez.
WebSocket ve uzun bağlantılar
Canlı bildirim veya sohbet eklediğinizde standart kısa HTTP isteklerinin yanında WebSocket bağlantıları da oluşabilir. Nginx’in WebSocket belgesi, protokol yükseltmesiyle ilgili başlıkların özel olarak iletilmesi gerektiğini anlatır. Bu yüzden normal sayfaları açabilen bir ters vekil yapılandırması, WebSocket bağlantıları için tek başına yeterli olmayabilir.
Panel örneğimizde görev güncellemeleri anlık iletiliyorsa yalnızca giriş sayfasını kontrol ederek kurulumu başarılı saymayın. Bağlantının açılmasını, bir süre boşta kalmasını ve ağ kesintisinden sonra yeniden kurulmasını ayrı senaryolar olarak değerlendirin. Uygulamanın yeniden bağlanma davranışı ile vekilin bağlantı zaman aşımı ayarları birlikte incelenmelidir.
Kurulumdan sonra neyi kontrol etmelisiniz?
Örnek projemiz için doğrulamayı birkaç somut kullanıcı işlemi üzerinden planlayabiliriz. Önce ana sayfa ve API’nin beklenen yanıtları verdiğini kontrol edin. Ardından giriş yapma, sayfayı yenileme, dosya yükleme ve uygulamadan çıkma adımlarını deneyin. Yönlendirme döngüsü veya beklenmeyen adres değişimi varsa şema ve Host bilgisinin uygulamada nasıl yorumlandığına bakın.
Bir sonraki adımda arka uç kapalıyken ne olduğunu gözlemleyin. İstemcinin gördüğü hata ile Nginx ve uygulama günlüklerini birlikte değerlendirin. Sorunun ağ erişimi, yanlış port, uygulama hatası veya süre sınırı olup olmadığını ayırt etmeye çalışın. Rastgele süreleri büyütmek yerine başarısız isteğin hangi aşamada durduğunu belirleyin.
Üretime geçerken örnekteki yerel adres varsayımlarını yeniden kontrol edin. Konteyner kullanıyorsanız 127.0.0.1, bulunduğunuz konteynerin kendisini gösterir; başka bir servise erişim için uygun ağ adresi gerekir. Yapılandırma değişikliklerinde sözdizimi kontrolü yapın ve geri dönüş planı hazırlayın.
Reverse proxy kullanırken başlangıç hedefiniz, her bileşenin sorumluluğunu açıklayabilmek olsun: İstek nereden geliyor, hangi kuralla yönleniyor ve uygulama hangi yolu bekliyor? Bu üç sorunun cevabı netleştiğinde yeni servis eklemek ve hataları izlemek daha yönetilebilir hâle gelir.
