Load balancer (yük dengeleyici), bir siteye gelen istekleri önceden tanımlı bir kurala göre birden fazla sunucu arasında dağıtan katmandır. Türkçede “yük dengeleyici” adıyla anılır; iki ifade aynı bileşeni tanımlar.
İhtiyacın kaynağı tektir: tek sunucu üzerinde çalışan bir site için o sunucu tek arıza noktasıdır. Sunucu kapandığında, bakıma alındığında ya da eşzamanlı istek sayısına yetişemediğinde site erişilemez hale gelir. Yük dengeleyici, aynı içeriği sunan birden fazla sunucuyu tek havuzda toplar ve isteği bu havuzun uygun üyesine iletir.
Ziyaretçi bu yapıyı görmez. İstemci tek bir sanal IP adresine bağlanır; isteği hangi sunucunun karşılayacağına yük dengeleyici karar verir. Bu kararı dört temel yöntemden biriyle verir: round robin, least connection, IP hash ve weighted. Yük dengeleyici yalnızca dağıtmaz; havuzdaki sunucuları düzenli aralıklarla denetler ve yanıt vermeyeni dağıtımın dışına çıkarır.
Aşağıda yük dengeleyicinin ne işe yaradığını, isteği hangi adımlardan geçirdiğini, dört yöntemin hangi koşulda seçildiğini ve aynı işin yazılım, donanım, bulut ve konteyner ortamlarındaki karşılığını açıklıyoruz.
Load balancer ne işe yarar?
Yük dengeleyici, bir sunucu havuzunun önünde çalışarak aşağıdaki beş işi üstlenir:
- Kesintisiz erişim. Havuzdaki 3 sunucudan biri kapansa da site kalan 2 sunucuyla yanıt verir.
- Yatay ölçeklenme. Tek sunucunun donanımını büyütmek yerine havuza sunucu eklenir; kapasite, eklenen sunucu sayısı oranında artar.
- Bakım penceresi. Güncellenecek sunucu havuzdan çıkarılır, işlem bitince geri alınır; güncelleme trafiği kesmez.
- Trafik yalıtımı. Katman 7 dağıtımında istekler adrese göre ayrılır;
/apiyolundaki ağır yük ziyaretçinin sayfasını yavaşlatmaz. - Şifreleme yükünün devri. TLS el sıkışması yük dengeleyici üzerinde tamamlanır, arka sunucuların işlemcisi bu işten kurtulur.
Beş kazanç da tek mekanizmadan doğar: isteğin sunucuya ulaşmadan bir karar noktasından geçmesinden.

Load balancer nasıl çalışır?
Yük dengeleyici, isteği karşılayan ve ileten bir ara durak olarak çalışır. İstemci alan adını çözümlediğinde arka sunuculardan birinin değil, yük dengeleyicinin sanal IP adresine (VIP) bağlanır; yük dengeleyici seçili kurala göre havuzdan bir sunucu seçer, isteği ona iletir ve dönen yanıtı istemciye döndürür.
Arka plandaki sunucu grubuna sunucu havuzu denir; NGINX ve HAProxy yapılandırmalarında upstream, bulut hizmetlerinde backend adıyla geçer. Üyeler aynı içeriği sunduğu için isteği hangisinin karşıladığı fark etmez.
Bu akışın üzerine üç mekanizma biner: yük dengeleyici havuzdaki sunucuları düzenli olarak denetler, oturum gerektiren isteklerde ziyaretçiyi aynı sunucuya sabitler ve şifreli bağlantıyı kendi üzerinde sonlandırır.
Sağlık kontrolü (health check) nedir ve ne sıklıkla yapılır?
Sağlık kontrolü, yük dengeleyicinin havuzdaki her sunucuya belirli aralıklarla istek göndererek yanıt verip vermediğini ölçtüğü denetimdir. Dağıtım kuralı isteğin nereye gideceğini belirler, sağlık kontrolü nereye gitmeyeceğini.
Kontrol aralığı tipik olarak 2–30 saniyedir. Bir sunucu arka arkaya 2–3 başarısız yanıt verdiğinde havuzdan çıkarılır; yeniden HTTP 200 döndürdüğünde havuza geri alınır. Aralık kısaldıkça arıza erken yakalanır, denetim trafiği artar.
İki tür kontrol kullanılır: aktif kontrolde yük dengeleyici ziyaretçi trafiğinden bağımsız kendi denetim isteğini gönderir, pasif kontrolde gerçek trafikteki hatalar sayılır ve eşik aşıldığında sunucu devre dışı bırakılır. Havuzda sağlıklı sunucu kalmadığında ziyaretçi 503 Service Unavailable hatasıyla karşılaşır.
Bir sunucunun ne zaman havuz dışına çıkarıldığını Sunucu Logları Nedir? Nasıl Okunur ve İzlenir? yazısındaki yöntemlerle izleyebilirsiniz. Erişilebilirliğin oran olarak nasıl ölçüldüğünü ise SLA Nedir? Hosting SLA ve Uptime Takibi Nasıl Yapılır? yazısında ele aldık.
Oturum sürekliliği (sticky session) neden gerekir?
Oturum sürekliliği, aynı ziyaretçiden gelen isteklerin havuzda hep aynı sunucuya gönderilmesidir. Gerekliliği oturum verisinin nerede tutulduğuna bağlıdır: sepet, giriş bilgisi ve çok adımlı form verisi sunucunun belleğinde tutuluyorsa, ziyaretçi bir sonraki istekte başka sunucuya düştüğünde oturum kopar.
Sabitleme iki yolla yapılır. Birincisinde yük dengeleyici kendi çerezini basar ve sonraki isteklerde bu çerezi okuyarak aynı sunucuyu seçer. İkincisinde kaynak IP adresi kullanılır; çerez gerekmez, ancak aynı ağdan çıkan kullanıcılar tek sunucuya yığılır. Üçüncü yol sorunu tamamen kaldırır: oturum verisi ortak bir veri deposunda tutulursa sabitlemeye gerek kalmaz. Sticky session, ziyaretçileri belirli sunuculara çivilediği için dağıtım dengesini bozar.
SSL sonlandırma yük dengeleyicide nasıl yapılır?
SSL sonlandırma, TLS el sıkışmasının arka sunucularda değil, yük dengeleyici üzerinde tamamlanmasıdır. Sertifika yük dengeleyicide durur, şifre çözme işini onun işlemcisi yapar ve istek arka tarafa ya düz HTTP olarak ya da yeniden şifrelenerek iletilir.
Kazanç iki yönlüdür: sertifika tek noktada yenilenir, her sunucuya ayrı kurulmaz; şifre çözmenin işlemci maliyeti de arka sunuculardan alınır. Yük dengeleyici ile arka sunucular arasındaki ağı denetlemiyorsanız trafiği iç tarafta da şifrelemelisiniz. Doğrulama seviyelerini SSL Çeşitleri Nelerdir? Aralarındaki Farklar Nelerdir? yazısında karşılaştırdık; sertifikayı SSL Sertifikası sayfasından seçebilirsiniz.
Sonlandırmadan sonra sıra isteğin hangi sunucuya gideceğine gelir; bu kararı dağıtım yöntemi verir.

Yük dengeleme yöntemleri nelerdir?
Yük dengeleme yöntemi, isteğin havuzdaki hangi sunucuya gideceğini belirleyen kuraldır ve yaygın olarak dört yöntem kullanılır. Aşağıdaki tablo her yöntemin dağıtımı nasıl yaptığını ve hangi koşulda seçildiğini gösterir:
| Yöntem | Nasıl dağıtır | Ne zaman seçilir |
|---|---|---|
| Round robin (sıralı dağıtım) | İstekleri havuzdaki sunuculara sırayla ve eşit sayıda gönderir; 3 sunuculu havuzda 6 istek her sunucuya 2’şer düşer | Havuzdaki sunucular aynı donanıma sahipse ve istekler birbirine yakın maliyetteyse |
| Least connection (en az bağlantı) | O anda üzerinde en az açık bağlantı bulunan sunucuyu seçer | İsteklerin işlenme süresi değişkense; rapor üretme, arama ve dosya yükleme gibi uzun işlemler varsa |
| IP hash (kaynak IP karması) | Ziyaretçinin IP adresini karma fonksiyonundan geçirir; aynı IP her seferinde aynı sunucuya yönlendirilir | Çerez kullanmadan oturum sürekliliği gerekiyorsa |
| Weighted (ağırlıklı dağıtım) | Her sunucuya kapasitesine göre ağırlık verilir; 3’e 1 ağırlıkta 4 istekten 3’ü güçlü sunucuya, 1’i zayıf sunucuya gider | Havuzdaki sunucuların işlemci ve bellek kapasiteleri farklıysa |
Dağıtım yazılımlarının çoğu varsayılan olarak round robin ile çalışır; yöntem sonradan değiştirilebilir. Kuralın hangi bilgiye bakarak karar verdiği ise dağıtımın hangi katmanda yapıldığına bağlıdır.
Katman 4 ile katman 7 yük dengeleme arasındaki fark nedir?
Katman 4 yük dengeleme isteğin IP adresine ve portuna bakar, katman 7 ise isteğin içeriğine — URL yoluna, Host başlığına ve çereze — bakar. Fark, kararın hangi bilgiye dayandığıdır.
Katman 4 (L4) dağıtımda paket açılmaz; yük dengeleyici TCP ya da UDP bağlantısını olduğu gibi aktarır. İşlem maliyeti düşüktür, şifreli trafik çözülmeden iletilir, ancak isteğin neye dair olduğu bilinmez.
Katman 7 (L7) dağıtımda HTTP isteği okunur. Bu sayede /api ile başlayan istekler bir havuza, geri kalanlar başka havuza gönderilebilir; farklı alan adları aynı IP üzerinden ayrıştırılabilir ve çerez tabanlı oturum sabitlemesi yapılabilir. Protokol sürümleri de bu katmanda karşılanır; farkları HTTP/2 ve HTTP/3 Nedir? Aralarındaki Farklar Nelerdir? yazısında karşılaştırdık.
Aynı katmanda bir bileşen daha çalışır: isteği içeriğine bakarak inceleyen ve zararlı olanları engelleyen web uygulama güvenlik duvarı, çoğu kurulumda yük dengeleyicinin hemen önünde konumlanır; işleyişini 🔴WAF Nedir? yazısında ele aldık. Sıra bu işi hangi yazılımın üstleneceğine gelir.

NGINX ile yük dengeleme nasıl yapılandırılır?
NGINX’te yük dengeleme, arka sunucuların bir upstream bloğunda tanımlanması ve isteklerin proxy_pass yönergesiyle bu bloğa yönlendirilmesiyle yapılandırılır. NGINX bu işi ters vekil sunucu rolüyle üstlenir.
Yukarıdaki dört yöntemin karşılıkları doğrudandır. Round robin varsayılandır ve ayrı yönerge gerektirmez. En az bağlantı least_conn, kaynak IP karması ip_hash yönergesiyle açılır. Ağırlıklı dağıtım için sunucu satırının sonuna weight= değeri yazılır.
Sağlık kontrolünde bilinmesi gereken bir ayrım vardır: NGINX’in açık kaynak sürümü yalnızca pasif kontrol yapar. max_fails kaç başarısız yanıtın sunucuyu devre dışı bırakacağını, fail_timeout bu sunucunun ne kadar süre trafik dışında kalacağını belirler; aktif kontrol ticari sürümün özelliğidir. NGINX’in diğer kullanımlarını NGINX Nedir? Hangi Amaçla Kullanılır? yazısında anlattık. Aynı dağıtımı yapan başka yazılımlar ve bir kurulum kararı da vardır.
HAProxy ve Apache yük dengeleme için ne zaman tercih edilir?
HAProxy, katman 4 ve katman 7 dağıtımını aynı anda yapması ve bağlantı sayılarını ayrıntılı bir istatistik arayüzünde göstermesi gereken kurulumlarda tercih edilir. Dağıtım kuralı tek satırda seçilir: balance roundrobin, balance leastconn ve balance source yönergeleri tablonun ilk üç satırına karşılık gelir.
Apache tarafında dağıtım mod_proxy_balancer modülüyle yapılır; tercih koşulu dardır: sunucuda zaten Apache çalışıyorsa ve yeni yazılım kurulmayacaksa bu modül işi görür.
Havuzdaki sunucuların hiçbiri yanıt vermediğinde — yazılım hangisi olursa olsun — vekil sunucu ziyaretçiye bir ağ geçidi hatası döndürür; nedenlerini 502 Bad Gateway Hatası Nedir? Nedenleri ve Çözüm Yöntemleri yazısında topladık.
Yük dengeleyici Windows ve Linux sunucularda nasıl kurulur?
Kuruluma başlamadan önce bir kuralı belirleyin: yük dengeleyici, trafiği dağıttığı sunucuların üzerinde değil, ayrı bir sunucuda çalışır. Aynı makineye kurmak, dağıtım katmanını arızalanan sunucuyla birlikte kaybetmektir.
Linux tarafında sırayı takip edin. Dağıtım sunucusuna NGINX ya da HAProxy kurun. Arka sunucuların IP adreslerini upstream havuzunda tanımlayın. Dağıtım yöntemini ve sağlık kontrolü eşiklerini yazın. Yapılandırmayı sözdizimi testinden geçirin, servisi yeniden yükleyin ve dağılımı erişim kayıtlarından doğrulayın.
Windows Server tarafında iki yol vardır: NLB (Network Load Balancing) rolü katman 4 dağıtımı yapar, IIS uygulamaları için ARR (Application Request Routing) eklentisi katman 7 dağıtımı sunar. Her iki yolda da dağıtım sunucusunun kök erişimine sahip olmanız gerekir.
Kurulum ayrıntılarını Linux VDS Nedir? Dağıtım Seçimi, Kurulum ve Yönetim Rehberi ve Windows VDS Nedir? Ne İşe Yarar ve Nasıl Seçilir? yazılarında topladık; dağıtım katmanı için VDS Satın Al (NVMe VDS Sunucu Kiralama) sayfasındaki kaynaklar yeterlidir.
Yazılım dışında hangi yük dengeleme seçenekleri vardır?
Yük dengeleme yalnızca bir sunucuya kurulan yazılımla yapılmaz. Bu iş için üretilmiş özel cihazlar, bulut sağlayıcılarının yönetilen hizmetleri ve konteyner platformlarının dağıtım katmanları da aynı sonucu üretir. Üçünü ayıran eksen tektir: dağıtım mantığı aynıdır, değişen şey kuralı kimin yönettiği ve arızada sorumluluğun kimde olduğudur.
Donanım tabanlı yük dengeleyici nedir?
Donanım tabanlı yük dengeleyici, dağıtım işini genel amaçlı bir sunucuda değil, bu iş için üretilmiş özel bir cihazda yapan çözümdür. F5 BIG-IP, Citrix NetScaler ve A10 bu kategorinin bilinen örnekleridir.
Ayırt edici niteliği işlem kapasitesidir. Cihazlar şifreleme için özel devreler taşır; saniyede işlenebilen TLS el sıkışması sayısı, aynı bütçeyle kurulmuş bir yazılım çözümünün üzerinde kalır.
Pratik koşulu yerleşimdir. Cihaz bir veri merkezine konur ve dağıttığı sunucularla aynı ağda çalışır; bu karar Fiziksel Sunucu Satın Al tarafındaki seçeneklerle birlikte değerlendirilir.
Bulut sunucularda yük dengeleyici nasıl çalışır?
Bulut sunucularda yük dengeleyici, sizin kurduğunuz bir yazılım olarak değil, sağlayıcının işlettiği yönetilen bir hizmet olarak çalışır. Panelden havuz oluşturulur, sunucular eklenir ve dağıtım kuralı seçilir; yazılımın kurulumu, güncellemesi ve yedekliliği sağlayıcıdadır.
Katman ayrımı burada da korunur: sağlayıcılar katman 4 için ağ yük dengeleyici, katman 7 için uygulama yük dengeleyici adıyla iki ayrı ürün sunar. Ek kazanç ölçeklemededir; otomatik ölçekleme kuralıyla havuza eklenen sunucu dağıtıma kendiliğinden katılır ve sağlık kontrolünden geçtikten sonra istek alır. Panel tarafını Azure Nedir? Azure Nasıl Kullanılır? 2025 yazısında ele aldık.
Ücretlendirme de farklıdır: bedel sabit paket ücreti olarak değil, çalışma süresi ve üzerinden geçen veri miktarı üzerinden hesaplanır. Havuza eklenecek sunucuların güncel kaynak bilgisi Yeni Nesil Bulut Sunucular sayfasındadır.
Kubernetes ve Docker ortamında yük dengeleme nasıl yapılır?
Kubernetes ve Docker ortamında yük dengeleme iki katmanda yapılır: küme içindeki dağıtım ve dışarıdan gelen trafiğin dağıtımı.
Küme içinde işi Service nesnesi üstlenir. ClusterIP tipindeki bir Service, aynı uygulamanın kopyalarına tek bir iç adres verir ve isteği bu kopyalar arasında dağıtır; dağıtımı düğüm üzerinde kube-proxy uygular. Dışarıdan gelen trafik için LoadBalancer tipi Service kullanılır ve bu tip, sağlayıcının yönetilen yük dengeleyicisini otomatik oluşturur.
Katman 7 dağıtımı Ingress controller ile yapılır. Yaygın Ingress controller’ların motoru NGINX’tir; upstream mantığı burada da çalışır, farkı yapılandırmanın küme nesneleriyle üretilmesidir. Docker Swarm tarafında aynı işi routing mesh görür. Konteynerler kısa ömürlü olduğu için sağlık kontrolü daha sık çalıştırılır. Konteyner mantığını Docker Nedir? Neden Docker Kullanmalısınız? yazısında anlattık.
DNS tabanlı yük dağıtımı yük dengeleyici yerine geçer mi?
Hayır, DNS tabanlı dağıtım bir yük dengeleyicinin yerini tutmaz. Aynı alan adı için birden çok A kaydı tanımlanarak istekler farklı IP adreslerine dağıtılabilir, ancak bu yöntem arızayı yönetemez.
Sebebi önbelleklemedir. DNS yanıtı, kaydın TTL süresi boyunca — tipik olarak 300–3.600 saniye — çözümleyicilerde ve tarayıcılarda saklanır. Arızalı sunucunun IP adresi kayıttan silinse bile bu süre dolana kadar ziyaretçilerin bir bölümü o adrese gider; klasik DNS round robin’de sağlık kontrolü de yoktur.
DNS katmanının doğru kullanımı başkadır: ziyaretçiyi en yakın veri merkezine yönlendirmek için DNS doğru araçtır ve içerik dağıtım ağları da bu mantıkla çalışır. Alan adı çözümlemesini DNS Nedir? yazısında, coğrafi dağıtımı CDN Nedir? Hosting ile Nasıl Çalışır? yazısında ele aldık.
Load balancer hakkında sık sorulan sorular
Yük dengeleyici kurmadan önce en çok sorulan üç soru aşağıdadır.
Yük dengeleyici tek başına kesintisiz erişim sağlar mı?
Hayır, tek başına kurulan bir yük dengeleyici kesintisiz erişim sağlamaz. Tek dağıtım sunucusu kurulduğunda arıza noktası ortadan kalkmaz, yalnızca yer değiştirir: arka sunuculardan yük dengeleyicinin kendisine taşınır. Yük dengeleyici kapandığında arkasındaki sunucular çalışsa bile site erişilemez.
Çözüm dağıtım katmanını da yedeklemektir: yük dengeleyici en az 2 düğümle kurulur, düğümler aktif-pasif ya da aktif-aktif çalışır ve sanal IP arıza anında ayakta olan düğüme geçer. Yedeklilik tek kaynaktan gelen aşırı istek trafiğini çözmez; bu taşmalar istek sınırlandırmasıyla karşılanır ve sınırı aşan isteğe dönen yanıtı 🔴429 Too Many Requests Hatası Nedir? yazısında ele aldık.
Paylaşımlı hostingde yük dengeleyici kurulabilir mi?
Hayır, paylaşımlı hosting paketinde yük dengeleyici kurulamaz. upstream tanımı sunucu genelinde geçerli bir ayardır; paylaşımlı pakette bu yapılandırmaya ve ağ katmanına erişim verilmez, çünkü aynı sunucuyu başka hesaplar da kullanır.
Yük dengeleme en az 3 sunuculu bir yapı demektir: aynı içeriği sunan en az 2 arka sunucu ve önlerinde 1 dağıtım sunucusu. Bu yapı ancak kök erişimi veren kaynaklarla kurulur. Paylaşımlı barındırmanın sınırını Paylaşımlı Hosting Nedir? Kimler İçin Uygundur? yazısında, kök erişimi veren seçeneği Sanal Sunucu (VPS) Nedir? Yeni Başlayanlar İçin Rehber yazısında açıkladık.
Yük dengeleyici site hızını artırır mı?
Evet, yük dengeleyici site hızını artırır; ancak hızlanma tek bir isteğin işlenme süresinden değil, eşzamanlı istek sayısının bölüşülmesinden gelir. Boş bir sunucuda tek ziyaretçinin gördüğü yanıt süresini yük dengeleyici kısaltmaz. Fark yoğun saatte çıkar: 3 sunuculu havuzda sunucu başına düşen kuyruk üçte birine, bekleme süresi de buna bağlı olarak iner.
İkinci kazanç SSL sonlandırmadan gelir; şifre çözme yükü arka sunuculardan alındığında bu sunucular kendi işlerine daha fazla kaynak ayırır. Yanıt süresinin nasıl ölçüldüğünü TTFB Nedir? Sunucu Yanıt Süresi Nasıl İyileştirilir? yazısında ayrıntılandırdık.
Doğru yapı en büyük havuz değil, ihtiyaç kadar sunucu ve o havuza uyan dağıtım kuralıdır. Kurulumu, sağlık kontrolü eşiklerini ve güncellemeleri kendiniz yönetmek istemiyorsanız Yönetilen Sunucular seçeneği aynı yapıyı sizin adınıza kurar ve ayakta tutar.

