Nginx ve HAProxy: Doğru Ters Proxy'yi Seçmek

Ters Proxy'nin Uygulamalarınıza Ne Sağladığı

Bir ters proxy, uygulamalarınızın önünde yer alan ve istemci isteklerini önce alan bir sunucudur. Her isteği doğru arka uç servisine (uygulama sunucularınıza) iletir ve yanıtı istemciye döndürür. Kullanıcılar proxy ile konuşur; proxy uygulamalarınızla konuşur.

Bir forward proxy tersinin tersi şekilde çalışır: istemcilerin önünde bulunur (örneğin bir şirket ağı içinde) ve onların dışarıya yönelik isteklerini internete iletir. Bu genellikle istemci trafiğini kontrol etmek, filtrelemek veya gizlemek içindir.

Bir yük dengeleyici genellikle ters proxy olarak uygulanır, fakat amacı daha spesifiktir: trafiği birden çok arka uç örneği arasında dağıtır. Birçok ürün (Nginx ve HAProxy dahil) hem ters proxyleme hem de yük dengeleme yapabildiğinden, terimler bazen birbirinin yerine kullanılır.

Ekiplerin ters proxy'yi kullanma amaçları

Çoğu kurulum aşağıdaki nedenlerden biri ya da birkaçıyla başlar:

• TLS/SSL terminasyonu: HTTPS'i tek bir yerde elle yönetmek, sertifikaları merkezi yönetmek ve uygun olduğunda iç servisler için düz HTTP iletmek.
• Yönlendirme: hostname, yol, header veya diğer kurallara göre trafiği farklı servislere göndermek (ör. /api bir API servisine, / bir web uygulamasına).
• Buffering ve bağlantı yönetimi: yavaş istemciler veya yavaş upstream'leri düzeltmek, uygulama sunucularındaki bağlantı başına yükü azaltmak ve algılanan güvenilirliği artırmak.
• Koruma kontrolleri: istek limitleri uygulamak, temel filtreleme ve güvenli varsayılanları istekler uygulamaya ulaşmadan önce sağlamak.

Uygulamalarınızın önünde nerede durur

Ters proxyler genellikle web siteleri, API'ler ve microservisler'in önünde yer alır—ya kenarda (kamusal internet) ya da hizmetler arasında dahili olarak. Modern yığınlarda, ingress gateway'ler, blue/green dağıtımlar ve yüksek erişilebilirlik düzenleri için yapı taşları olarak da kullanılırlar.

Bu rehber size ne konuda yardımcı olacak

Nginx ve HAProxy örtüşür, ancak vurgu yaptıkları noktalar farklıdır. İlerleyen bölümlerde çok sayıda bağlantı altındaki performans, yük dengeleme ve sağlık kontrolleri, protokol desteği (HTTP/2, TCP), TLS özellikleri, gözlemlenebilirlik ve günlük yapılandırma ve işletme gibi karar faktörlerini karşılaştıracağız.

Nginx Genel Bakış: Güçlü Yönler ve Tipik Kullanım Alanları

Nginx hem bir web sunucusu hem de bir ters proxy olarak yaygın şekilde kullanılır. Birçok ekip, kamuya açık bir web sitesini sunmak için Nginx ile başlar ve sonra rolünü uygulama sunucularının önünde TLS, trafik yönlendirmesi ve ani yükleri düzeltme amaçlı genişletir.

Nginx'in kenarda tercih edilme sebepleri

Trafiğiniz ağırlıklı olarak HTTP(S) ise ve her şeyi yapabilen tek bir “giriş kapısı” istiyorsanız Nginx öne çıkar. Özellikle güçlü olduğu noktalar:

• Statik varlıkları (resimler, CSS/JS) verimli sunma
• Basit yol- ve host-tabanlı yönlendirme ile HTTP ters proxy olarak görev yapma
• Arka uçlardaki yükü azaltmak için önbellekleme
• Header ekleme veya normalize etme (ör. X-Forwarded-For, güvenlik header'ları)

İçerik sunma ve proxy görevini birlikte yapabildiğinden, Nginx genellikle daha az parça ile küçük-orta ölçek kurulumlar için tercih edilir.

Ekiplerin güvendiği modüller ve özellikler

Popüler özellikler arasında:

• TLS terminasyonu ve sertifika yönetimi iş akışları (yenilemeler sırasında reload otomasyonu ile)
• Bant genişliğini azaltmak için sıkıştırma (build'e bağlı olarak gzip/brotli)
• Gürültülü istemcileri azaltmak için istek sınırlama ve temel istek kontrolleri
• URL temizliği ve eski yönlendirmeler için rewrite/redirect yetenekleri

Ayrıca isteğe bağlı özellikler olarak WebSocket proxyleme gibi gerçek zamanlı uygulamalar için destek bulunur.

Tipik “giriş kapısı” senaryoları

Nginx sıkça tercih edilir when:

• Bir pazarlama sitesi ile bir API'nin birlikte sunulduğu durumlar (statik + proxy)
• Birkaç uygulama örneği arasında basit yük dengeleme
• Yavaş arka uçların önünde önbellekleme (ör. CMS veya REST servisleri)
• Farklı host isimleri altında birden çok servisin gateway'i olarak hareket etme

HTTP işleme açısından zengin özelliklere ve web sunumu ile ters proxy görevlerini birleştirme fikrini seviyorsanız, Nginx genellikle varsayılan başlangıç noktasıdır.

HAProxy Genel Bakış: Güçlü Yönler ve Tipik Kullanım Alanları

HAProxy (High Availability Proxy), genellikle bir veya daha fazla uygulama sunucusunun önünde ters proxy ve yük dengeleyici olarak kullanılır. Gelen trafiği kabul eder, yönlendirme ve trafik kurallarını uygular ve istekleri sağlıklı arka uçlara iletir—çoğunlukla yüksek eşzamanlılık altında yanıt sürelerini kararlı tutarken.

HAProxy genelde ne için kullanılır

Ekipler tipik olarak HAProxy'yi trafik yönetimi için dağıtır: istekleri sunuculara yaymak, arızalar sırasında servislerin erişilebilir kalmasını sağlamak ve trafik dalgalanmalarını yumuşatmak. Hem kenar (north–south trafik) hem de dahili (east–west) trafik için sık tercih edilir; özellikle tahmin edilebilir davranış ve bağlantı yönetimi gerektiğinde.

Temel güçlü yönler: bağlantılar, yük dengeleme, sağlık kontrolleri

HAProxy, çok sayıda eşzamanlı bağlantıyı verimli şekilde işleme konusuyla bilinir. Bu, aynı anda birçok istemcinin bağlı olduğu (yoğun API'ler, uzun soluklu bağlantılar, chatty microservisler) durumlarda proxy'nin duyarlı kalmasını sağlar.

Yük dengeleme kabiliyetleri, insanların HAProxy'yi seçmesindeki ana nedenlerden biridir. Basit round-robin'in ötesinde birçok algoritma ve yönlendirme stratejisi sunar; bunlar sayesinde:

• "Sıcak" sunucuların aşırı yüklenmesini önleyebilirsiniz
• Rollout sırasında trafiği kademeli olarak kaydırabilirsiniz
• Gerekirse daha hızlı veya daha az yüklü örnekleri tercih edebilirsiniz

Sağlık kontrolleri de güçlü bir noktadır. HAProxy arka uçları aktif olarak doğrulayabilir ve sağlıksız örnekleri otomatik olarak devre dışı bırakıp iyileştiklerinde tekrar devreye alabilir. Bu, kesinti süresini azaltır ve yarım bozuk dağıtımların tüm kullanıcıları etkilemesini engeller.

Katman 4 vs Katman 7: pratikte ne anlama geliyor

HAProxy Katman 4 (TCP) ve Katman 7 (HTTP) seviyelerinde çalışabilir.

• Katman 4 (TCP) modu ham bağlantı iletmeye odaklanır. HTTP ayrıntılarını incelemenize gerek olmayan protokoller için idealdir—ör. genel TCP servisleri, veritabanı proxyleri veya minimal ek yük istediğiniz durumlar.
• Katman 7 (HTTP) modu HTTP semantiklerini anlar ve header-tabanlı yönlendirme, yol kuralları ve daha ince trafik kontrolleri sağlar.

Pratik fark: L4 genelde daha basit ve TCP iletimi için çok hızlıdır; L7 ise ihtiyaç duyduğunuzda daha zengin yönlendirme ve istek mantığı sunar.

HAProxy ne zaman tercih edilir

HAProxy genellikle güvenilir, yüksek performanslı yük dengeleme ve güçlü sağlık kontrolü gerektiğinde tercih edilir—örneğin API trafiğini birden çok uygulama sunucusuna dağıtmak, kullanılabilirlik bölgeleri arasında failover yönetmek ya da bağlantı hacminin ve öngörülebilir trafik davranışının web sunucusu özelliklerinden daha önemli olduğu servisleri yönlendirmek için.

Performans Temelleri: Gecikme, Verim ve Bağlantılar

Performans karşılaştırmaları sıkça tek bir sayıya (ör. “maks RPS”) bakılarak yanlış yapılır; bunun yerine kullanıcıların ne hissettiğine odaklanmak gerekir.

Veri akışı vs gecikme vs kuyruk gecikmesi (tail latency)

• Verim (throughput) ne kadar işin geçirilebildiğidir (istek/saniye veya byte/saniye).
• Gecikme (latency) bir isteğin ne kadar sürdüğüdür.
• Tail latency (p95/p99) gerçek sıkıntının görüldüğü yerdir: ortalama iyi olsa bile en yavaş %1–5 zaman aşımına, yeniden denemelere ve kötü kullanıcı deneyimine yol açabilir.

Bir proxy, verimi artırırken yük altındayken çok fazla kuyruklama yaparsa tail latency'yi kötüleştirebilir.

Bağlantı desenleri önemlidir

Uygulamanızın "şekli" hakkında düşünün:

• Birçok kısa ömürlü istek (tipik web trafiği): bağlantı kabul etmede, TLS el sıkışmalarında ve istek ayrıştırmada verimlilik önemli.
• Daha az, uzun ömürlü bağlantılar (WebSocket, streaming, gRPC, veri tabanı benzeri TCP): bağlantı başına öngörülebilir kaynak kullanımı ve kararlılık ham RPS'den daha önemli.

Benchmark'ı bir modelle yapıp başka birine dağıtırsanız, sonuçlar geçerli olmaz.

Buffering: dost mu düşman mı

Buffering, istemciler yavaş veya patlamalıysa yardımcı olabilir; proxy isteği (veya yanıtı) tamamen okuyup uygulamanıza daha dengeli besleyebilir.

Buffering, uygulamanız streaming'den faydalanıyorsa zarar verebilir (server-sent events, büyük indirmeler, gerçek zamanlı API'ler). Ek buffering bellek baskısı yaratır ve tail latency'yi artırabilir.

Pratik benchmark ipuçları

Sadece “maks RPS” ölçmeyin:

• RPS/verim, p50/p95/p99 gecikme ve hata oranı (zaman aşımı, 502/503)
• Sabit yük ve ani patlamalar ile test edin (kısa patlamalar genellikle kuyruk davranışını ortaya çıkarır)
• Gerçekçi keep-alive/TLS ayarları kullanın ve CPU, bellek, açık bağlantıları kaydedin

Eğer p95 hızla yükseliyorsa ama hatalar görünmüyorsa, bu doygunluğun erken uyarısıdır—"boşta başı" değil.

Yük Dengeleme ve Sağlık Kontrolleri Karşılaştırması

Nginx ve HAProxy her ikisi de birden çok uygulama örneğinin önünde trafiği dağıtabilir ama kutudan çıkan yük dengeleme özellik setlerinde derinlik farkı vardır.

Yük dengeleme algoritmaları

Round-robin benzer arka uçlar için varsayılan ve çoğu zaman yeterli bir seçimdir. Basit, öngörülebilir ve durumsuz uygulamalar için iyi çalışır.

Least connections istek süresi değişken olduğunda (dosya indirme, uzun API çağrıları, websocket-benzeri yükler) faydalıdır. Daha az aktif isteği olan arka uçları tercih ederek yavaş sunucuların aşırı yüklenmesini önler.

Ağırlıklı dengeleme (weights ile round-robin veya weighted least connections), sunucular eşit olmadığında (eski ve yeni node karışımı, farklı instance boyutları, kademeli trafik geçişi) pratik bir seçenektir.

Genel olarak, HAProxy daha fazla algoritma seçeneği ve Katman 4/7 üzerinde ince kontrollere sahipken, Nginx ortak durumları temiz şekilde karşılar (ve sürüme/ek modüllere bağlı olarak genişletilebilir).

Oturum kalıcılığı (stickiness)

Stickiness, kullanıcıyı istekler boyunca aynı arka uca yönlendirir.

• Çerez tabanlı kalıcılık web uygulamaları için genellikle en iyisidir: açık, NAT arkasındaki kullanıcılar için çalışır ve arka uç kaybolduğunda kontrollü failover sağlar.
• Kaynak IP kalıcılığı etkinleştirmesi kolaydır, ama adil olmayabilir (çok sayıda kullanıcı aynı IP'den gelir) ve istemci IP görünürlüğü değişirse bozulabilir (CDN'ler, proxy'ler).

Legacy server-side oturumlar yoksa, mümkün olduğunda kalıcılıktan kaçının: durumsuz servisler daha iyi ölçeklenir ve kurtarılır.

Sağlık kontrolleri: aktif vs pasif

Aktif sağlık kontrolleri periyodik olarak arka uçları probe'lar (HTTP uç noktası, TCP connect, beklenen durum) ve düşük trafik sırasında bile hataları yakalar.

Pasif sağlık kontrolleri gerçek trafiğe tepki verir: zaman aşımı, bağlantı hatası veya hatalı cevaplar bir sunucuyu sağlıksız olarak işaretler. Hafiftir ama sorunları tespit etmesi daha uzun sürebilir.

HAProxy, zengin sağlık kontrolü ve hata yönetimi kontrolleri (eşikler, rise/fall sayıları, ayrıntılı testler) ile tanınır. Nginx de sağlam kontroller sunar; yetenekler build ve sürüme bağlıdır.

Kesintisiz deploylar: draining ve yeniden deneme

Rolling deploylar için arayın:

• Connection draining: yeni istek göndermeyi bırakın ama devam eden isteklerin bitmesine izin verin.
• Retries ve redispatch: bir arka uç ortada başarısız olursa, güvenli istekler için yeniden deneyin (sadece idempotent istekler) ya da isteği başka sağlıklı sunucuya gönderin.

Hangi aracı seçerseniz seçin, draining'i kısa, tanımlı zaman aşımı ayarları ve "ready/unready" sağlık uç noktasıyla eşleştirin ki deploy sırasında trafik düzgün kaysın.

Protokoller ve TLS: HTTP, HTTP/2 ve TCP Proxyleme

Ters proxyler sisteminizin kenarında durur; bu yüzden protokol ve TLS seçimleri tarayıcı performansından servislerin birbirleriyle güvenli konuşmasına kadar her şeyi etkiler.

TLS terminasyonu ve sertifika yönetimi

Hem Nginx hem HAProxy TLS'i "terminate" edebilir: istemciden gelen şifreli bağlantıları kabul eder, trafiği çözer ve arka uçlara HTTP ya da tekrar şifrelenmiş TLS ile iletir.

Operasyonel gerçeklik sertifika yönetimidir. Bir planınız olmalı:

• Sertifika temini ve yenileme (genellikle ACME/Let’s Encrypt)
• Özel anahtarların güvenli saklanması ve erişim kısıtlamaları
• Bağlantıları düşürmeden konfigürasyon reload'ları

Nginx, TLS terminasyonunun web sunucu özellikleri (statik dosya sunma, yönlendirmeler) ile birlikte olduğu durumlarda sıkça tercih edilir. HAProxy ise TLS'i daha çok trafik yönetimi katmanının bir parçası olarak kullanan kurulumlarda tercih edilir.

HTTP/2: performans ve uyumluluk

HTTP/2, tarayıcılar için çoklu isteği tek bir bağlantıda çoğullaştırarak sayfa yükleme sürelerini azaltabilir. Her iki araç da istemci tarafında HTTP/2'yi destekler.

Dikkat edilmesi gerekenler:

• İstemci uyumluluğu: çoğu modern tarayıcı HTTP/2'yi destekler, fakat bazı eski istemciler ve otomatik araçlar desteklemeyebilir.
• Arka uç desteği: genellikle HTTP/2'yi proxy'de sonlandırıp upstream ile HTTP/1.1 konuşmak yaygındır ve daha basittir.

TCP proxylemenin önemi

HTTP dışı trafik (veritabanları, SMTP, Redis, özel protokoller) yönlendirmeniz gerekiyorsa TCP proxyleme gerekir. HAProxy yüksek performanslı TCP yük dengeleme için yaygın şekilde kullanılır. Nginx de stream yetenekleriyle TCP proxyleyebilir; basit pass-through senaryoları için bu yeterli olabilir.

Karşılıklı TLS (mTLS)

mTLS, iki tarafı da doğrular: istemci sertifika sunar, sadece sunucu değil. Servisler arası iletişim, partner entegrasyonları veya sıfır-güven (zero-trust) tasarımları için uygundur. Her iki proxy de kenarda istemci sertifika doğrulamasını zorunlu kılabilir; birçok ekip ayrıca proxy ile upstream arasında da mTLS kullanır, böylece "güvenilen ağ" varsayımlarını azaltır.

Gözlemlenebilirlik: Loglama, Metrikler ve Hata Ayıklama

Ters proxyler her isteğin ortasında yer aldığından, "ne oldu?" sorusuna cevap vermek için en iyi yerlerdendir. İyi gözlemlenebilirlik tutarlı loglar, yüksek sinyal veren küçük metrik seti ve zaman aşımı ile gateway hatalarını tekrar üretilebilir şekilde hata ayıklama yolları sağlar.

Gerekli loglar: access, error ve upstream zamanlamaları

Prod ortamda en azından access log ve error log açık tutun. Access log'larda upstream zamanlamalarını dahil edin ki gecikmenin proxy'den mi yoksa uygulamadan mı kaynaklandığını anlayın.

Nginx'te yaygın alanlar $request_time, $upstream_response_time, $upstream_status gibi değişkenlerdir. HAProxy'de HTTP log modu ve queue/connect/response zamanları yakalanarak "bir arka uç için bekleme" ile "arka uç yavaş" arasındaki fark ayrıştırılabilir.

Logları mümkünse yapılandırılmış (JSON) tutun ve proxy loglarını uygulama loglarıyla ilişkilendirmek için bir istek ID'si ekleyin (gelen header'dan veya üretimden).

Dışa aktarılması gereken metrikler

Prometheus çekiyor olun ya da metrikleri başka yere gönderin, tutarlı bir set dışa aktarın:

• İstek sayıları ve yanıt kodları (2xx/4xx/5xx)
• Hata sayaçları (yeniden denemeler, başarısız sağlık kontrolleri, 502/504)
• Gecikme (p50/p95/p99; tercihen proxy vs upstream ayrımı)
• Bağlantılar (aktif, kuyrukta, reddedilen)

Nginx genellikle stub status uç noktası veya Prometheus exporter kullanır; HAProxy ise yerleşik bir stats endpoint'i sunar ve birçok exporter bunu okur.

Sağlık uç noktaları ve readiness kontrolleri

Hafif bir /health (işlem ayakta) ve /ready (bağımlılıklara erişebiliyor) uç noktası açın. Bunları otomasyon için kullanın: load balancer sağlık kontrolleri, deploylar ve otomatik ölçeklendirme kararları.

Zaman aşımı, reset ve 502/504 hata ayıklama

• 502: arka uç bağlantıyı reddetti/kapatıldı, DNS sorunları veya protokol uyumsuzluğu.
• 504: proxy arka uç beklerken zaman aşımına uğradı.
• Resetler/zaman aşımı: keep-alive ayarlarını, arka uç doygunluğunu ve kuyruk uzunluğunu kontrol edin.

Sorun giderirken proxy zamanlamasını (queue/connect) upstream yanıt süresiyle karşılaştırın. Eğer connect/queue yüksekse kapasite ekleyin veya yük dengeleme ayarlarını değiştirin; upstream zamanı yüksekse uygulama ve veritabanına odaklanın.

Konfigürasyon ve Günlük İşletme

Bir ters proxy işletmek sadece tepe performansla ilgili değildir—aynı zamanda ekibinizin saat 14:00'te (veya 02:00'de) güvenle değişiklik yapabilmesiyle ilgilidir.

Konfigürasyon stili ve işe alıştırma

Nginx konfigürasyonu yönerge tabanlı ve hiyerarşiktir. http → server → location gibi "blok içinde blok" okunması, site ve rota mantığıyla düşünenler için yaklaşılabilir gelir.

HAProxy konfigürasyonu daha "boru hattı" gibidir: frontends (kabul ettikleriniz), backends (trafiği gönderdiğiniz yerler) tanımlanır ve kuralları (ACL'ler) bunlara bağlayarak mantık oluşturulur. Modeli benimsediğinizde özellikle trafik yönlendirme mantığı için daha açık ve öngörülebilir gelebilir.

Reload'lar ve değişiklik yönetimi

Nginx genellikle config reload yaparken yeni worker'ları başlatır ve eski worker'ları nazikçe boşaltır. Bu, sık rota güncellemeleri ve sertifika yenilemeleri için uygundur.

HAProxy de kesintisiz reload yapabilir; ancak ekipler genelde onu daha çok "appliance" gibi tutar: sıkı değişiklik kontrolü, versiyonlu konfigürasyon ve reload komutları etrafında dikkatli koordinasyon.

Doğrulama, şablonlar ve DRY kalmak

Her ikisi de reload öncesi konfigürasyon testi desteği sunar (CI/CD içinde zorunlu). Pratikte konfigürasyonları DRY tutmak için genelde üretimle oluşturma kullanırsınız:

• Şablonlar kullanın (Helm, Ansible, Terraform veya dahili araçlar)
• Kayıt, header, timeout ve güvenlik varsayılanları için ortak parçalar saklayın

Temel işletme alışkanlığı: proxy konfigürasyonunu kod olarak ele alın—incelenmiş, test edilmiş ve uygulama değişiklikleri gibi dağıtılmış olsun.

Ölçekle işletmek: çok sayıda uygulama, rota ve sertifika

Servis sayısı arttıkça, gerçek ağrı noktası sertifika ve yönlendirme karmaşası olur. Planlayın:

• Standart adlandırma ve sahiplik (hangi hostname kimin sorumluluğunda)
• Otomatik sertifika oluşturma/rotasyon
• Her uygulama için zaman aşımı ve yeniden deneme konvansiyonları

Yüzlerce host bekliyorsanız, konfigürasyonları elle düzenlemek yerine servis meta verisinden konfig. üretmeyi düşünün.

Koder.ai bu iş akışında nerede duruyor

Birden çok servis üzerinde geliştirip iterasyon yapıyorsanız, ters proxy teslim hattının yalnızca bir parçasıdır—hala tekrarlanabilir uygulama iskeleti, ortam tutarlılığı ve güvenli rollout'lara ihtiyacınız var.

Koder.ai ekiplerin fikirden çalışan servislere daha hızlı geçmesine yardımcı olabilir: sohbet tabanlı iş akışıyla React web uygulamaları, Go + PostgreSQL backend'ler ve Flutter mobil uygulamalar üretebilir; ardından kaynak kodu dışa aktarma, dağıtım/barındırma, özel alan adları ve anlık görüntüler ile geri alma desteği sunar. Bu, bir API + web ön yüzünü prototipleyip dağıttıktan sonra gerçek trafik modellerine dayanarak Nginx mi yoksa HAProxy mi diye karar vermenizi kolaylaştırır.

Güvenlik ve Sertleştirme Düşünceleri

Güvenlik nadiren tek bir "sihirli" özellikten ibarettir—saldırı yüzeyini azaltmak ve kontrolsüz trafiğe karşı varsayılanları sıkılaştırmak önemlidir.

Temel sertleştirme (en az ayrıcalık, izinler, ağ kuralları)

Proxy'yi mümkün olduğunca az ayrıcalıkla çalıştırın: ayrıcalıklı portlara Linux capabilities ile bağlanma veya bir öndeki hizmet aracılığıyla bind etme, worker süreçlerini ayrıcalıksız tutma. Konfigürasyon ve anahtar materyalini (TLS özel anahtarları, DH parametreleri) servis hesabı tarafından salt okunur yapın.

Ağ katmanında, içeri sadece beklenen kaynaklardan izin verin (internet → proxy; proxy → arka uçlar). Arka uçlara doğrudan erişimi mümkünse reddedin; böylece proxy kimlik doğrulama, oran sınırlama ve loglama için tek boğaz noktası olur.

Oran sınırlama ve kötüye kullanım koruması

Nginx limit_req / limit_conn gibi birincil primitive'lere sahiptir. HAProxy ise genellikle stick table'lar kullanarak istek oranlarını, eşzamanlı bağlantıları veya hata desenlerini izler ve sonra kötü niyetli istemcileri engeller, yavaşlatır veya cezalandırır.

Tehdit modelinize uygun bir yaklaşım seçin:

• Giriş/API uç noktalarında patlama kontrolü
• Yavaş istemcilerin worker'ları tüketmesini önlemek için bağlantı kapasiteleri
• Tekrarlayan 4xx/5xx desenlerine göre yasaklama (test edilerek kullanın)

Header işleme tuzakları (X-Forwarded-For, Host)

Hangi header'ları güvendiğinizi açıkça belirtin. X-Forwarded-For ve benzerlerini yalnızca bilinen upstream'lerden kabul edin; aksi halde saldırganlar istemci IP'sini sahteleyip IP-tabanlı kontrolleri atlayabilir. Benzer şekilde, cache zehirlenmesini ve host-header saldırılarını önlemek için Host'u doğrulayın veya proxy tarafından ayarlayın.

Basit bir kural: proxy, yönlendirme header'larını ayrıcalıklı şekilde set etmeli, onları körü körüne iletmemelidir.

Smuggling ve kötü girişlere karşı daha güvenli varsayılanlar

Request smuggling genellikle çelişkili Content-Length / Transfer-Encoding, garip boşluklar veya geçersiz header formatları gibi belirsiz ayrıştırmadan faydalanır. Daha katı HTTP ayrıştırma modlarını tercih edin, bozuk header'ları reddedin ve konservatif limitler koyun:

• Maks header boyutu / sayısı
• Header/gövde için makul zaman aşımı (slowloris koruması)
• Connection, Upgrade ve hop-by-hop header'lar için açık işleyiş

Bu kontroller Nginx ve HAProxy arasında sözdizimi olarak farklılık gösterir, ama sonuç aynı olmalı: belirsizlikte kapat (fail closed) ve limitleri açıkça tutun.

Yaygın Dağıtım Modelleri (ve Ne Zaman Kullanmalı)

Ters proxyler genelde iki şekilde devreye girer: tek bir uygulama için ayrılmış giriş kapısı olarak ya da birçok servisin önünde duran paylaşılan bir gateway olarak. Her iki araç da her iki rolü de yapabilir—önemli olan kenarda ne kadar yönlendirme mantığına ihtiyaç duyduğunuz ve günlük işletmeyi nasıl yapmak istediğinizdir.

1) Bir uygulama, bir proxy (basit ve öngörülebilir)

Bu model ters proxy'yi doğrudan tek bir web uygulamasının (veya sıkı ilişkili küçük bir servis setinin) önüne koyar. TLS terminasyonu, HTTP/2, sıkıştırma, önbellekleme (Nginx kullanılıyorsa) veya kamu interneti ile özel uygulama arasındaki net ayrım gerektiğinde uygundur.

Kullanılmalı when:

• Bir ana uygulama domain'iniz ve açık bir arka uç hedefiniz varsa.
• Basit rollback'ler ve minimal yönlendirme kuralları istiyorsanız.
• Uygulamaya ait konfigürasyonun uygulama ile birlikte gitmesini tercih ediyorsanız.

2) Birçok uygulama için paylaşılan gateway (merkezi yönlendirme)

Burada bir (veya az sayıda) proxy, hostname, yol, header veya diğer istek özelliklerine göre trafiği birden çok uygulamaya yönlendirir. Bu kamu giriş noktalarının sayısını azaltır ama temiz konfigürasyon yönetimi ve değişiklik kontrolünün önemini artırır.

Kullanılmalı when:

• Birden fazla uygulama barındırıyorsanız (örn. app1.example.com, app2.example.com) ve tek bir ingress katmanı istiyorsanız.
• Hizmetler arasında tutarlı politikalar (TLS ayarları, yönlendirmeler, oran sınırlama) uygulanmasını istiyorsanız.
• Sertifikaları ve erişim kayıtlarını merkezi yönetmek istiyorsanız.

3) Proxy katmanında blue/green ve canary dağıtımlar

Proxy'ler kodu değiştirmeden "eski" ve "yeni" sürümler arasında trafiği bölebilir. Yaygın yaklaşım iki upstream havuzu (blue ve green) veya iki backend (v1 ve v2) tanımlamak ve trafiği kademeli olarak kaydırmaktır.

Tipik kullanım:

• Blue/green: doğrulandıktan sonra trafiğin %100'ünü blue'dan green'e geçirin.
• Canary: yeni versiyona %1–10 arasında trafik gönderin (weight, cookie, header veya özel canary hostname ile) ve sonra kademeli artırın.

Bu, dağıtım aracınız weighted rollouts yapamıyorsa veya ekipler arasında tutarlı bir rollout mekanizması istiyorsanız özellikle kullanışlıdır.

4) Yüksek kullanılabilirlik: active/passive, VRRP ve ötesi

Tek bir proxy tek hata noktasıdır. Yaygın HA desenleri:

• Active/passive + VRRP: iki proxy node sanal bir IP paylaşır; biri birincil olur, diğeri arızada devralır.
• Active/active load balancer arkasında: birden çok proxy trafiği alır, genelde bulut veya donanım load balancer ile.
• Anycast (ileri seviye): aynı IP birden fazla konumdan duyurulur; routing kullanıcılara en yakın sağlıklı siteye gönderir.

Ortamınıza göre seçin: VM/bare metal'de VRRP yaygındır; bulutta yönetilen load balancer'lar genelde en basit olanlardır.

5) CDN ve WAF nerede durur

Tipik bir ön-arka zinciri: CDN (opsiyonel) → WAF (opsiyonel) → ters proxy → uygulama.

• CDN origin yükünü azaltır ve statik/önbelleklenebilir içerik için gecikmeyi iyileştirir.
• WAF zararlı istekleri proxy/app'e ulaşmadan önce filtreler.
• Ters proxy yönlendirme, TLS politikası ve upstream sağlık davranışı için kontrol noktası olmaya devam eder.

Eğer zaten bir CDN/WAF kullanıyorsanız, proxy'yi uygulama teslimi ve yönlendirmeye odaklı tutun; tek güvenlik katmanı haline getirmeye çalışmayın.

Kubernetes ve Modern Uygulama Yığınları

Kubernetes uygulamaları "önleme" şeklini değiştirir: servisler geçicidir, IP'ler değişir ve yönlendirme kararları genellikle cluster kenarında bir Ingress controller ile yapılır. Hem Nginx hem de HAProxy burada iyi uyum sağlayabilir, ancak biraz farklı roller öne çıkar.

Kubernetes: Ingress controller seçenekleri ve takaslar

• Nginx Ingress için çok yaygın bir tercihtir çünkü ekosistem geniştir ve konfigürasyon modeli HTTP yönlendirmesi (hostlar, yollar, redirect, rewrite) ile doğal olarak eşleşir. L7 davranışı esnek olanlar bunu sever.
• HAProxy ise yüksek eşzamanlılık altında öngörülebilir performans, bağlantı yönetimi ve yük dengeleme davranışı istediğinizde tercih edilir.

Pratikte karar nadiren “hangisi daha iyi” olur; daha çok “trafik deseninize ve kenarda ne kadar HTTP manipülasyonu gerektiğine hangisi uyuyor” şeklindedir.

Servis mesh ile birlikte proxy kullanımı

Eğer bir servis mesh (örn. servisler arası mTLS ve trafik politikaları) kullanıyorsanız, kenar için hala Nginx/HAProxy'yi tutabilirsiniz (north–south trafik). Mesh east–west trafiğini ele alır. Bu ayrım kenar endişelerini—TLS terminasyonu, WAF/oran sınırlama, temel yönlendirme—iç güvenilirlik özelliklerinden (retry, circuit breaker) ayırır.

gRPC ve uzun ömürlü bağlantılarla çalışma (WebSockets, SSE)

gRPC ve uzun ömürlü bağlantılar proxy'leri kısa HTTP isteklerinden farklı şekilde zorlar. Dikkat edilmesi gerekenler:

• gRPC için HTTP/2 desteği ve tuning (zaman aşımı, max concurrent streams)
• WebSocket ve SSE için bağlantı zaman aşımı ve keepalive ayarları
• "Konuşmalı" trafiği bozmayan yük dengeleme davranışı (stickiness gerektiğinde)

Hangi aracı seçerseniz seçin, kısa testler yerine gerçekçi sürelerle (dakikalar/saatler) test edin.

Konfigürasyonları Git'te tutma ve CI/CD ile dağıtma

Proxy konfigürasyonunu kod olarak ele alın: Git'te saklayın, CI'de doğrulayın (lint, konfigürasyon testi) ve CD ile kontrollü dağıtımlar (canary veya blue/green) üzerinden yayınlayın. Bu yükseltmeleri daha güvenli kılar ve routing/TLS değişikliği üretimi etkilediğinde açık bir denetim izi sağlar.

Karar Kontrol Listesi: Hangisini Seçmelisiniz?

En hızlı karar verme yolu, proxy'nin günlük olarak ne yapmasını beklediğinizden başlamaktır: içerik sunmak mı, HTTP trafiğini şekillendirmek mi yoksa bağlantı ve dengeleme mantığını sıkı yönetmek mi.

Nginx'i seçin eğer…

Proxy aynı zamanda web trafiği için bir "giriş kapısı" ise Nginx genellikle daha uygun varsayılandır.

• Arka uç yükünü azaltmak için önbellekleme istiyorsanız (API cevapları, varlıklar, mikro-önbellek)
• Statik dosyaları verimli sunmak istiyorsanız (varlıklar, indirmeler, basit landing page'ler)
• Basit HTTP yönlendirmeleri (host/path, redirect, header normalizasyonu)
• Sıkıştırma ve kolay TLS terminasyonu gibi uygulamaya yakın özelliklere ihtiyaç duyuyorsanız

HAProxy'yi seçin eğer…

Öncelik detaylı trafik dağıtımı ve yük altındaki kesin kontrolse, HAProxy öne çıkar.

• Gelişmiş yük dengeleme seçenekleri ve her arka uç için ince davranış kontrolü
• Sıkı bağlantı kontrolü (limitler, kuyruklar, yüksek eşzamanlılık için zaman aşımı tuning)
• Komple havuzlar için daha güvenli sağlık kontrolleri ve failover davranışı
• HTTP'nin yanı sıra öncelikli Layer 4 (TCP) proxyleme gerektiğinde

Her ikisini birlikte kullanmanın anlamı

Her ikisini birlikte kullanmak yaygındır; böylece web sunucu kolaylıkları ile uzman dengeleme ayrılabilir:

• Nginx kenarda: statik dosyalar, önbellekleme ve HTTP yönlendirme
• HAProxy arkada: çok sayıda uygulama örneğine trafiği dağıtmak, sert bağlantı politikaları uygulamak

Bu ayrım ekiplerin sorumluluklarını ayırmaya da yardımcı olabilir: web kaygıları vs trafik mühendisliği.

Hızlı kontrol listesi

Kendinize sorun:

1. Proxy'de önbellekleme veya statik dosya sunma gerekiyor mu? → Nginx
2. Arka uçları korumak için çok spesifik dengeleme/bağlantı limitleri gerekiyor mu? → HAProxy
3. Trafiğin çoğu basit yönlendirmeli HTTP mi? → Nginx
4. HTTP yanında karma TCP servisleri de dengeliyor muyuz? → HAProxy
5. Tek araç mı yoksa iki katmanlı bir yapı mi istiyoruz (edge + balancer)? → duruma göre seçin