[ OK ]Kernel başlatılıyor...
~/im/blog
Beni İşe Alın

Konuşalım

Çözülmesi gereken bir altyapı probleminiz mi var veya projeniz için desteğe mi ihtiyacınız var? Yeni projeler için bana ulaşabilirsiniz.

İletişime geç

Bağlantılar

Beni sosyal medyada ve profesyonel ağlarda bulun.

© 2026 Irfan Miral. Tüm hakları saklıdır.Geliştiren:Irfan Miral
Gizlilik PolitikasıŞartlar & Koşullar
Ana SayfaHizmetlerHakkımda/ÖzgeçmişBlogİletişimAraçlar
2026-05-14• 5 dk okuma süresi

Ters Vekil (Reverse Proxy) Olarak HAProxy mi Nginx mi? Nasıl Karar Veriyorum

DevOps HAProxy Nginx Load Balancing

Reklam

Nginx ve HAProxy sürekli birbirleriyle kıyaslanır. Dürüst cevap şudur ki, aralarında devasa bir örtüşme vardır. Her ikisi de TLS sonlandırabilir, birden fazla sunucu arasında yük dengeleyebilir (load balance) ve trafiği hostname veya yollara (path) göre yönlendirebilir. Altyapıların çok büyük bir kısmı için her ikisi de mükemmel şekilde iş görür.

Ancak bu iki araç çok farklı temel görevler düşünülerek inşa edilmiştir. Ve bu fark, sisteminiz "bir proxy arkasında çalışan tek bir uygulama sunucusu" aşamasını geçtiğinde acı verici derecede belirgin hale gelir.

Nginx: Tek bir uygulama sunucusu için varsayılan tercih

Eğer elinizde tam olarak bir tane uygulama sunucusu, belki yanında birkaç statik dosya dizini varsa ve proxy'nin görevi sadece TLS sonlandırmak ve istekleri doğru yere yönlendirmekse, Nginx çok daha basit bir seçimdir. Ve bu işi son derece iyi yapar:

server {
    listen 443 ssl;
    server_name ornek.com;

    ssl_certificate     /etc/letsencrypt/live/ornek.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ornek.com/privkey.pem;

    location /static/ {
        root /var/www/ornek.com;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Bu yapılandırma aynı anda üç işi birden halleder: statik dosyaları doğrudan sunmak, TLS sonlandırmak ve geri kalan her şeyi uygulamaya proxy'lemek. Tek bir backend için bu tam olarak olması gereken karmaşıklık seviyesidir. Ayrıca hemen hemen her geliştirici daha önce Nginx sözdizimini (syntax) görmüştür. Sistemi ayakta tutan tek kişi siz olmadığınızda bu durum fazlasıyla önem kazanır.

HAProxy: Birden fazla backend olduğunda varsayılan tercih

Uygulamanızın ikinci bir kopyasını (instance) ayağa kaldırdığınız an, sormanız gereken sorular kökten değişir. Şu an hangi backend'ler sağlıklı? Yük bunlar arasında nasıl dağıtılmalı? Bir backend aniden ölürse, o sırada havada olan bir isteğe (request) ne olacak?

İşte bu, HAProxy'nin temel görevidir ve bu durum yapılandırma dosyasında kendini çok net belli eder:

frontend web
    bind *:443 ssl crt /etc/haproxy/certs/ornek.com.pem
    default_backend app_servers

backend app_servers
    balance roundrobin
    option httpchk GET /healthz
    server app1 10.0.0.11:3000 check
    server app2 10.0.0.12:3000 check
    server app3 10.0.0.13:3000 check

option httpchk GET /healthz satırı, HAProxy'nin her bir backend'in sağlık (health) uç noktasını aktif olarak yokladığı anlamına gelir. Eğer bir backend bu kontrollerden geçememeye başlarsa, HAProxy o sunucuyu rotasyondan otomatik olarak çıkarır. Sıfır manuel müdahale gerekir.

HAProxy'nin yerleşik istatistik sayfası; tam olarak hangi backend'lerin ayakta olduğunu, her birinin kaç bağlantıyı işlediğini ve sunucu başına yanıt sürelerini size anlık ve detaylı bir şekilde gösterir. Takip etmeniz gereken birden fazla sunucu olduğunda bu izlenebilirlik (observability) gerçekten vazgeçilmezdir.

İkisini birlikte kullanmak

Bu araçlar birbirini dışlayan şeyler değildir. Tek bir sunucunun ötesine ölçeklenirken (scaling) kullanılan çok yaygın bir mimari, HAProxy'yi en dış uca (edge) yerleştirmektir. HAProxy, TLS sonlandırmasını ve birden fazla uygulama sunucusu arasındaki yük dengelemeyi üstlenir. Ardından, her uygulama sunucusu kendi içinde statik dosyaları sunmak ve istekleri doğrudan uygulama sürecine proxy'lemek için yerel bir Nginx çalıştırır.

HAProxy'nin statik dosyalar hakkında hiçbir şey bilmesine gerek yoktur. Nginx'in de genel sunucu kümesi (cluster) hakkında hiçbir şey bilmesine gerek yoktur. Her parça sadece en iyi olduğu işi yapar.

Gerçek Karar

Eğer tek bir backend'iniz varsa ve ana hedefiniz TLS sonlandırma artı temel yönlendirmeyse, Nginx daha basittir, daha tanıdıktır ve tamamen yeterlidir. Tek bir backend'in önüne HAProxy koymak, size pek bir yetenek katmadan fazladan koca bir ağ katmanı ekler.

Ancak birden fazla backend kopyanız varsa ve sunucu sağlığını dikkate alan bir yük dengeleme (health-aware load balancing) gerçekten önemliyse (sadece yedeklilik için iki uygulama sunucusu olsa bile), HAProxy tam da bunun için inşa edilmiştir. HAProxy'nin o kaya gibi sağlam sağlık kontrolü modelini Nginx'te taklit etmeye çalışmak, sırf aynı sonucu almak için üçüncü taraf modüllere (third-party modules) bulaşmak veya HAProxy'nin ihtiyaç duyduğundan çok daha karmaşık yapılandırmalar yazmak demektir.

Soru hangi aracın objektif olarak daha iyi olduğu değildir. Soru, "bu istek hangi backend'e gitmeli ve o backend şu an sağlıklı mı?" probleminin, altyapınızın cevaplaması gereken bir problem olup olmadığıdır. Eğer cevap evetse, HAProxy o yeri sonuna kadar hak eder.

Reklam

Yardıma mı ihtiyacınız var?

Eğer Web Sunucu Yapılandırması işini sizin yerinize birinin halletmesini tercih ederseniz, benim asıl işim tam olarak bu.

İletişime Geç
ÖncekiSpam Kutusuna Düşmeyen Bir Posta Sunucusu KurmakSonraki Proxmox'ta Docker vs LXC: Canlı Ortamda Gerçekte Ne Kullanıyorum?