Bir web uygulaması geliştirdiğinizde, istemci ile sunucu arasındaki trafiği yönetmek çoğu zaman uygulamanın kendi mantığını kurgulamak kadar önemlidir. İşte bu noktada Reverse Proxy (Ters Vekil Sunucu) mimarisi devreye girer.

Nginx, düşük kaynak tüketimi ve yüksek performansıyla reverse proxy, web sunucusu ve load balancer olarak dünya çapında yaygın şekilde kullanılan araçlardan biridir.

Ancak önemli soru şu:

Her projede Nginx kullanmak gerçekten gerekli mi?

Cevap: Hayır.

Bazı projelerde Nginx; SSL yönetimi, trafik yönlendirme, güvenlik ve load balancing gibi konularda ciddi avantajlar sağlarken, bazı küçük projelerde yalnızca mimariyi gereksiz yere karmaşıklaştırabilir.

Bu yazıda Nginx reverse proxy'nin ne zaman gerçekten ihtiyaç olduğunu, ne zaman over-engineering (aşırı mühendislik) sayılabileceğini ve hangi alternatiflerin kullanılabileceğini mühendislik açısından inceleyeceğiz.

Reverse Proxy Nedir?

Reverse proxy'yi basitçe, kullanıcı ile uygulama sunucuları arasında duran bir trafik yöneticisi olarak düşünebiliriz.

Normal bir yapıda kullanıcı doğrudan uygulamaya ulaşabilir:

Kullanıcı
   │
   ▼
Node.js :3000

Reverse proxy kullanılan yapıda ise:

Kullanıcı
   │
   ▼
 Nginx
   │
   ▼
Node.js :3000

Kullanıcı dışarıdan Nginx ile iletişim kurar. Nginx ise gelen isteği arka planda çalışan uygulamaya iletir ve uygulamadan aldığı cevabı tekrar kullanıcıya gönderir.

Örneğin:

example.com
      │
      ▼
    Nginx
      │
      ├── /       → Frontend
      │
      └── /api    → Node.js :5000

Böylece kullanıcı :5000 gibi backend portlarını bilmek zorunda kalmaz.

Nginx Sadece Reverse Proxy Değildir

Burada önemli bir ayrım yapmak gerekiyor:

Nginx kullanmak ile Nginx'i reverse proxy olarak kullanmak aynı şey değildir.

Nginx farklı görevlerde kullanılabilir:

Örneğin yalnızca HTML, CSS ve JavaScript dosyalarından oluşan bir web sitesi Nginx tarafından doğrudan sunulabilir:

Browser
   │
   ▼
 Nginx
   │
   ├── index.html
   ├── style.css
   └── app.js

Burada arkada başka bir uygulama sunucusu bulunmadığı için Nginx'in reverse proxy özelliğini kullanmanız gerekmez.

Nerelerde Kullanmak Mantıklı?

Nginx'i uygulamanızın önüne bir trafik polisi olarak koymanın birçok operasyonel avantajı vardır.

1. Port Gizleme ve Yönlendirme

Bir sunucuda birden fazla uygulama çalıştırıyorsanız Nginx gelen istekleri ilgili servislere yönlendirebilir.

example.com
     │
     ▼
   Nginx
   ├──────────────► Frontend
   │
   └── /api ──────► Node.js :5000

Dışarıya yalnızca 80 ve 443 portlarını açıp, backend servislerinin 5000, 3000 gibi portlarını internetten erişilemez hâle getirebilirsiniz. Bu yapı hem daha düzenli hem de daha güvenli bir mimari oluşturabilir.

2. SSL/TLS Sonlandırma

HTTPS bağlantılarının TLS işlemlerini Nginx üzerinde sonlandırarak SSL sertifikalarını merkezi bir noktadan yönetebilirsiniz.

Kullanıcı
   │
 HTTPS
   ▼
 Nginx
   │
 HTTP
   ▼
Node.js

Bu yaklaşımda backend servislerinin her birinde ayrı ayrı sertifika yönetmek yerine, dış dünyaya açılan tek giriş noktasını Nginx üzerinden yönetebilirsiniz. Özellikle Let's Encrypt ve Certbot gibi araçlarla sertifika yenileme işlemlerini otomatikleştirmek de mümkündür.

Buradaki avantaj yalnızca performans değildir; asıl avantajlardan biri TLS yapılandırmasının merkezi hâle gelmesidir.

3. Statik Dosya Sunumu ve Caching

Görseller, CSS, JavaScript ve diğer statik dosyaları doğrudan Nginx üzerinden sunmak, dinamik backend sunucusunun gereksiz yere meşgul olmasını engelleyebilir.

Kullanıcı
   │
   ▼
 Nginx
   ├── /images
   ├── /css
   ├── /js
   │
   └── /api → Backend

Bu sayede backend yalnızca gerçekten uygulama mantığı gerektiren isteklerle ilgilenebilir. Caching de uygun senaryolarda performansı artırmak için kullanılabilir.

4. Load Balancing

Uygulamanız büyüdüğünde tek bir backend sunucusu yerine aynı servisten birden fazla instance çalıştırabilirsiniz.

                   ┌──► Node.js #1
                   │
Kullanıcı ─► Nginx ─┼──► Node.js #2
                   │
                   └──► Node.js #3

Nginx gelen istekleri bu sunucular arasında dağıtabilir. Örneğin Round Robin yönteminde istekler sırayla her instance'a gönderilir; ilk istek birinci sunucuya, ikinci istek ikinci sunucuya gider ve liste bittiğinde başa dönülür. Nginx ayrıca en az bağlantıya sahip sunucuyu seçen least_conn veya istemci IP'sine göre sabit yönlendirme yapan ip_hash gibi yöntemleri de destekler.

Bu yapı özellikle Docker veya benzeri container tabanlı mimarilerde kullanışlı olabilir.

5. Tek Domain Üzerinden Birden Fazla Servis

Frontend ve backend farklı servislerde çalışıyorsa Nginx bunları kullanıcıya tek bir domain üzerinden sunabilir.

example.com
      │
      ▼
    Nginx
      │
      ├── /       → Frontend
      │
      ├── /api    → Backend
      │
      └── /admin  → Admin Panel

Bu yapı frontend ve API'nin aynı origin altında sunulmasını sağlayarak bazı CORS ihtiyaçlarını ortadan kaldırabilir veya azaltabilir.

Ancak önemli bir nokta:

Nginx tek başına CORS problemlerinin çözümü değildir.

CORS, browser'ın origin güvenlik politikasıyla ilgilidir. Nginx yalnızca doğru mimari ve yapılandırmayla CORS ihtiyacını azaltmaya yardımcı olabilir.

Hangi Projelerde Gerekli?

Her teknoloji gibi Nginx de doğru bağlamda kullanıldığında değer yaratır. Her projeye Nginx eklemek yerine önce gerçekten hangi probleme çözüm aradığınızı belirlemek gerekir.

Production Ortamları

İnternete açık production uygulamalarında TLS yönetimi, trafik yönlendirme, rate limiting, caching, güvenlik katmanı veya load balancing gibi ihtiyaçlar varsa reverse proxy önemli bir avantaj sağlar.

Ancak burada kritik bir ayrım vardır:

Production ortamında reverse proxy ihtiyacı olabilir; fakat bunun mutlaka Nginx olması gerekmez.

Cloudflare, AWS Application Load Balancer, Kubernetes Ingress veya kullandığınız platformun kendi proxy katmanı da benzer görevleri üstlenebilir.

Mikroservis veya Ayrık Mimariler

Frontend, backend, authentication servisi ve diğer API'ler farklı servisler hâlinde çalışıyorsa tek bir giriş noktası oluşturmak büyük kolaylık sağlar.

                    ┌──► Frontend
                    │
Kullanıcı ─► Nginx ─┼──► API
                    │
                    ├──► Auth Service
                    │
                    └──► Admin Panel

Bu durumda Nginx routing, TLS ve dışarıya açılan servislerin kontrolü açısından oldukça kullanışlı olabilir.

Docker ile Birden Fazla Servis Çalıştırılan Sunucular

Aynı VPS üzerinde birden fazla uygulama veya container çalıştırıyorsanız domain bazlı yönlendirme ihtiyacı ortaya çıkabilir.

site1.com     → Container A
site2.com     → Container B
api.site1.com → Container C

Nginx burada bütün dış trafiği karşılayan merkezi bir giriş noktası olarak görev yapabilir.

Backend Servisinin Doğrudan İnternete Açılmasını İstemiyorsanız

Örneğin Node.js uygulamanız 127.0.0.1:5000 üzerinde çalışabilir ve internetten yalnızca 80/443 portlarına izin verilebilir:

İnternet
   │
   ├── 80
   └── 443
       │
       ▼
     Nginx
       │
       ▼
127.0.0.1:5000

Bu, reverse proxy kullanımının en pratik avantajlarından biridir.

Hangi Durumlarda Overkill Olabilir?

1. Local Development Ortamı

Uygulamanızı kendi bilgisayarınızda geliştiriyorsanız araya Nginx koymak çoğu zaman gerekli değildir. localhost:3000 üzerinden çalışan bir React veya Node.js uygulaması için ayrıca Nginx yapılandırmak geliştirme sürecine gereksiz bir katman ekleyebilir.

2. Basit Statik Web Siteleri

Siteniz yalnızca HTML, CSS, JavaScript ve görsellerden oluşuyorsa reverse proxy kullanmanıza gerek yoktur. Hatta böyle bir site için kendi VPS'inizi yönetmek yerine GitHub Pages, Vercel veya benzeri managed platformlar daha pratik olabilir.

Eğer Nginx kullanıyorsanız bile burada Nginx'i reverse proxy olarak değil, web server olarak kullanırsınız.

3. Küçük ve Tek Servisli Uygulamalar

Tek bir uygulama sunucunuz varsa ve kullandığınız hosting platformu HTTPS, domain ve proxy işlemlerini zaten sizin yerinize yapıyorsa ayrıca Nginx kurmak gereksiz olabilir.

Kullanıcı
   │
   ▼
Platform
   │
   ▼
Uygulama

Bu mimaride Nginx'i ayrıca yönetmenin size sağlayacağı fayda oldukça sınırlı olabilir.

4. Dışa Kapalı İç Ağlar

İki backend servisi aynı kapalı ağ içerisinde doğrudan iletişim kurabiliyorsa aralarına gereksiz bir reverse proxy katmanı eklemek mimariyi karmaşıklaştırabilir.

Service A ─────► Service B

yerine:

Service A ─► Proxy ─► Service B

koymak her zaman daha iyi değildir. Proxy; authentication, routing, observability veya başka bir ihtiyaç için kullanılmıyorsa ek bir katman hâline gelebilir.

Burada amaç mümkün olan en fazla katmanı eklemek değil, gerekli olan katmanları kullanmaktır.

Peki Nginx Kullanmalı mıyım?

Karar vermek için şu soruları sorabilirsiniz:

Sonuç

Nginx'i her projeye eklemek doğru bir yaklaşım değildir. Asıl önemli olan, Nginx'in hangi problemi çözdüğünü bilmektir.

Birden fazla servisiniz varsa, frontend ve backend'i tek domain altında toplamak istiyorsanız, HTTPS yönetimini merkezileştirmek istiyorsanız, backend servislerini doğrudan internete açmak istemiyorsanız ya da caching veya load balancing ihtiyacınız varsa Nginx oldukça güçlü ve kullanışlı bir araçtır.

Fakat küçük bir local proje, tek servisli basit bir uygulama veya zaten reverse proxy hizmeti sağlayan managed bir platform kullanıyorsanız, Nginx eklemek yalnızca yönetmeniz gereken yeni bir katman oluşturabilir.

Bu nedenle iyi bir mimarinin amacı mümkün olduğunca fazla teknoloji kullanmak değil, ihtiyaca uygun teknolojiyi kullanmaktır.

Nginx bir zorunluluk değil, doğru problemi çözdüğünde ciddi değer sağlayan bir mimari araçtır.