30 Ağu 2025·8 dk
Nginx ve HAProxy: Doğru Ters Proxy'yi Seçmek
Nginx ve HAProxy'yi ters proxy olarak karşılaştırın: performans, yük dengeleme, TLS, gözlemlenebilirlik, güvenlik ve yaygın kurulumlar ile en uygun çözümü seçin.
Nginx ve HAProxy'yi ters proxy olarak karşılaştırın: performans, yük dengeleme, TLS, gözlemlenebilirlik, güvenlik ve yaygın kurulumlar ile en uygun çözümü seçin.
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.
Çoğu kurulum aşağıdaki nedenlerden biri ya da birkaçıyla başlar:
/api bir API servisine, / bir web uygulamasına).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.
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 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.
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:
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.
Popüler özellikler arasında:
Ayrıca isteğe bağlı özellikler olarak WebSocket proxyleme gibi gerçek zamanlı uygulamalar için destek bulunur.
Nginx sıkça tercih edilir when:
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 (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.
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.
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:
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.
HAProxy Katman 4 (TCP) ve Katman 7 (HTTP) seviyelerinde çalışabilir.
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 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 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.
Bir proxy, verimi artırırken yük altındayken çok fazla kuyruklama yaparsa tail latency'yi kötüleştirebilir.
Uygulamanızın "şekli" hakkında düşünün:
Benchmark'ı bir modelle yapıp başka birine dağıtırsanız, sonuçlar geçerli olmaz.
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.
Sadece “maks RPS” ölçmeyin:
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.
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.
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).
Stickiness, kullanıcıyı istekler boyunca aynı arka uca yönlendirir.
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.
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.
Rolling deploylar için arayın:
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.
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.
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ı:
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, 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:
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.
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.
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.
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).
Prometheus çekiyor olun ya da metrikleri başka yere gönderin, tutarlı bir set dışa aktarın:
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.
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ı.
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.
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.
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.
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.
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:
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.
Servis sayısı arttıkça, gerçek ağrı noktası sertifika ve yönlendirme karmaşası olur. Planlayın:
Yüzlerce host bekliyorsanız, konfigürasyonları elle düzenlemek yerine servis meta verisinden konfig. üretmeyi düşünün.
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 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.
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.
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:
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.
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:
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.
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.
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:
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:
app1.example.com, app2.example.com) ve tek bir ingress katmanı istiyorsanız.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:
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.
Tek bir proxy tek hata noktasıdır. Yaygın HA desenleri:
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.
Tipik bir ön-arka zinciri: CDN (opsiyonel) → WAF (opsiyonel) → ters proxy → uygulama.
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 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.
Pratikte karar nadiren “hangisi daha iyi” olur; daha çok “trafik deseninize ve kenarda ne kadar HTTP manipülasyonu gerektiğine hangisi uyuyor” şeklindedir.
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ılar proxy'leri kısa HTTP isteklerinden farklı şekilde zorlar. Dikkat edilmesi gerekenler:
Hangi aracı seçerseniz seçin, kısa testler yerine gerçekçi sürelerle (dakikalar/saatler) test edin.
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.
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.
Proxy aynı zamanda web trafiği için bir "giriş kapısı" ise Nginx genellikle daha uygun varsayılandır.
Öncelik detaylı trafik dağıtımı ve yük altındaki kesin kontrolse, HAProxy öne çıkar.
Her ikisini birlikte kullanmak yaygındır; böylece web sunucu kolaylıkları ile uzman dengeleme ayrılabilir:
Bu ayrım ekiplerin sorumluluklarını ayırmaya da yardımcı olabilir: web kaygıları vs trafik mühendisliği.
Kendinize sorun:
Bir ters proxy, istemcilerin proxy'ye bağlandığı ve proxy'nin istekleri doğru arka uç hizmetine iletip yanıtı döndürdüğü uygulamalarınızın önünde yer alır.
Bir forward proxy ise istemcilerin önünde bulunur ve genellikle kurumsal ağlarda dış internete çıkan trafiği kontrol eder.
Bir yük dengeleyici, trafiği birden çok arka uç örneğine dağıtmaya odaklanır. Birçok yük dengeleyici ters proxy olarak uygulanır; bu yüzden terimler bazen örtüşür.
Pratikte, genellikle tek bir araç (ör. Nginx veya HAProxy) hem ters proxy hem de yük dengeleme görevlerini birlikte yapar.
Tek kontrol noktasına ihtiyaç duyduğunuz sınırda konumlandırın:
Önemli nokta, istemcilerin doğrudan arka uçlara erişmesine izin vermemek; böylece proxy politika ve görünürlük için tek boğaz noktası olur.
TLS terminasyonu, proxy'nin HTTPS işlemlerini ele aldığı anlamına gelir: şifreli istemci bağlantılarını kabul eder, şifreyi çözer ve trafiği HTTP veya yeniden şifrelenmiş TLS üzerinden arka uçlara iletir.
Operasyonel olarak planlamanız gerekenler:
Proxy aynı zamanda bir web “giriş kapısı” ise Nginx genellikle daha kullanışlıdır:
HAProxy'yi, öncelik trafik yönetimi ve yük altındaki öngörülebilirlik olduğunda seçin:
Benzer arka uçlar ve çoğunlukla uniform istek maliyeti için round-robin uygundur.
İstek süreleri değişiyorsa (dosya indirme, uzun API çağrıları, uzun ömürlü bağlantılar) least connections kullanın; bu, daha yavaş örneklerin ezilmesini önler.
Arka uçlar farklıysa (farklı instance boyutları, aşamalı geçişler) weighted çeşitleri kullanarak trafiği bilinçli şekilde kaydırın.
Stickiness, bir kullanıcıyı istekler boyunca aynı arka uca yönlendirir.
Mümkünse stickiness'ten kaçının: stateless servisler daha iyi ölçeklenir ve daha sorunsuz failover sağlar.
Buffering, yavaş veya patlamalı istemcilerle başa çıkarken arka uca daha sabit bir akış verir ve yardımcı olabilir.
Ancak streaming (SSE, WebSocket, büyük indirmeler) gerektiğinde ekstra buffering zararlı olabilir; bellek baskısı yaratır ve tail latency'yi kötüleştirebilir.
Uygulamanız stream odaklıysa, varsayılanlara güvenmek yerine buffering'i açıkça test edip ayarlayın.
Önce proxy gecikmesini ve arka uç gecikmesini ayrıştırmak için log/metric'leri karşılaştırın.
Yaygın anlamlar:
Karşılaştırılması yararlı sinyaller:
Çözümler genellikle zaman aşımı ayarlarını değiştirmek, arka uç kapasitesini artırmak veya sağlık/readiness uç noktalarını iyileştirmeyi içerir.