Ters Vekil Sunucu: nginx, Traefik ve Caddy Karşılaştırması

Kısa cevap: Ters vekil sunucu (reverse proxy), gelen istekleri karşılayıp arka taraftaki uygulamalara dağıtan ve TLS sertifikalarını tek noktada yöneten katmandır. Üç yaygın seçenek arasındaki fark şudur: Traefik konteyner ortamında servisleri otomatik keşfeder, Caddy en sade yapılandırmayla otomatik HTTPS verir, nginx en olgun ve en çok ince ayar sunan seçenektir.

Ters vekil sunucu neyi çözer?

Tek bir sunucuda birden fazla servis yayımladığınızda dört sorun aynı anda ortaya çıkar:

1. Port çakışması. İki uygulama da 80 portunu dinleyemez.
2. Sertifika dağınıklığı. Her uygulamanın kendi TLS sertifikasını yönetmesi, her birinde ayrı yenileme mekanizması demektir.
3. Doğrudan maruz kalma. Uygulama sunucularının internete doğrudan açılması, saldırı yüzeyini gereksiz genişletir.
4. Tekrarlanan ortak işler. Sıkıştırma, önbellek başlıkları, hız sınırı, erişim logu her uygulamada ayrı ayrı çözülmek zorunda kalır.

Ters vekil sunucu dördünü tek noktada toplar. Mimari şöyle olur:

İnternet
   │  443 (TLS)
   ▼
Ters vekil sunucu  ──►  uygulama-a  (127.0.0.1:3000)
   │                ──►  uygulama-b  (127.0.0.1:4000)
   │                ──►  statik site (dosya sisteminden)
   └── sertifika yönetimi, sıkıştırma, hız sınırı, erişim logu

Kritik ayrıntı: arka uçlar yalnız yerel arayüzde dinler. Konteyner ortamında bu, portu 127.0.0.1:3000:3000 biçiminde yayımlamak veya hiç yayımlamayıp iç ağ üzerinden erişmek demektir. Portu tüm arayüzlerde açık bırakmak, ters vekil sunucunun sağladığı korumayı baştan iptal eder; ayrıntısı Linux firewall rehberinde.

nginx, Traefik ve Caddy arasındaki farklar neler?

Ölçüt	nginx	Traefik	Caddy
Otomatik HTTPS	Ayrı araç gerekir (certbot)	Dahili	Dahili, varsayılan açık
Konteyner keşfi	Yok (elle yapılandırma)	Otomatik (etiketlerle)	Yok (eklentiyle sınırlı)
Yapılandırma uzunluğu	Uzun	Orta	En kısa
Yeniden yükleme	Elle veya otomasyonla	Kendiliğinden	Kendiliğinden
İnce ayar imkânı	En geniş	Orta	Orta
Olgunluk ve bilgi birikimi	En yüksek	Yüksek	Orta
Bellek kullanımı	En düşük	Orta	Orta
Docker dışı servis yayımlama	Doğal	Ek yapılandırma	Doğal

Karar kuralım:

• Konteynerler sık değişiyor, servis ekleyip çıkarıyorsanız: Traefik. Yeni servisi etiketleyip başlattığınızda vekil sunucuya dokunmanız gerekmez.
• Az sayıda servis, sadelik ve otomatik HTTPS önceliğiniz ise: Caddy. Beş satırlık bir dosyayla çalışan bir HTTPS sitesi elde edersiniz.
• Yüksek trafik, ayrıntılı önbellek ve hız sınırı kuralları, statik dosya sunumu ağırlıklıysa: nginx.

nginx: klasik ve en çok kontrol veren

nginx’in gücü olgunluğundan gelir; karşılaşacağınız hemen her sorunun bir cevabı zaten yazılmıştır. Bedeli, yapılandırmanın elle yapılması ve sertifika yenilemesi için ayrı bir araç gerekmesidir.

Tipik bir ters vekil sunucu bloğu:

server {
    listen 443 ssl;
    http2 on;
    server_name uygulama.ornek.com;

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

    location / {
        proxy_pass http://127.0.0.1:3000;

        # Gerçek istemci bilgisini arka uca taşı
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket desteği
        proxy_http_version 1.1;
        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

# HTTP'yi HTTPS'e yönlendir
server {
    listen 80;
    server_name uygulama.ornek.com;
    return 301 https://$host$request_uri;
}

İki blok özellikle atlanır ve sonradan sorun çıkarır. X-Forwarded-* başlıkları olmadan arka uç uygulama her isteği 127.0.0.1 adresinden geliyor sanır; oturum yönetimi, hız sınırı ve loglama yanlış çalışır. WebSocket satırları olmadan gerçek zamanlı bağlantılar sessizce kopar; hata mesajı genellikle uygulamada değil tarayıcı konsolunda görünür.

Yapılandırmayı değiştirdikten sonra mutlaka test edip yükleyin:

sudo nginx -t          # sözdizimi hatası varsa burada görürsünüz
sudo systemctl reload nginx

Sertifika tarafında certbot ile otomatik yenileme kurulur. Yenilemenin çalıştığını varsaymayın, kuru çalıştırmayla doğrulayın:

sudo certbot renew --dry-run

Traefik: konteyner ortamının doğal seçimi

Traefik’i ayıran şey otomatik servis keşfidir. Docker’ı bir sağlayıcı olarak dinler; siz bir konteyneri belirli etiketlerle başlattığınızda Traefik onu görür, yönlendirmeyi kurar ve sertifikayı alır. Vekil sunucu yapılandırmasına hiç dokunmazsınız.

services:
  traefik:
    image: traefik:v3.1
    restart: unless-stopped
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "[email protected]"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - letsencrypt:/letsencrypt
    networks:
      - vekil

  uygulama:
    image: benim-uygulamam:1.4.2
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.uygulama.rule=Host(`uygulama.ornek.com`)"
      - "traefik.http.routers.uygulama.entrypoints=websecure"
      - "traefik.http.routers.uygulama.tls.certresolver=le"
      - "traefik.http.services.uygulama.loadbalancer.server.port=3000"
    networks:
      - vekil

volumes:
  letsencrypt:

networks:
  vekil:

Üç ayrıntı önemlidir:

exposedbydefault=false mutlaka kalsın. Aksi halde Traefik, sunucudaki tüm konteynerleri kendiliğinden internete yayımlamaya çalışır; bu, istemeden açılmış servisler demektir.

Docker soketi erişimi Traefik’in çalışma biçiminin gereğidir ama ciddi bir yetkidir: soketi görebilen konteyner, ana sistemde root yetkisine eşdeğer güce sahiptir. En azından :ro ile salt okunur bağlayın ve Traefik konteynerini güven sınırının içinde sayın. Riskin tam açıklaması Docker güvenlik sertleştirme yazısında.

acme.json kalıcı olmalı. Sertifika deposu bir hacimde durmazsa, her yeniden başlatmada yeni sertifika istenir ve sertifika sağlayıcının hız sınırlarına takılırsınız. Kalıcı veri yönetiminin genel kuralları Docker veri kalıcılığı yazısında.

Caddy: en kısa yapılandırma

Caddy’nin ayırt edici özelliği, HTTPS’in varsayılan olarak açık olmasıdır. Alan adını yazarsınız, Caddy sertifikayı alır, yeniler ve HTTP’yi HTTPS’e yönlendirir. Yapılandırma dosyası bu kadar kısadır:

uygulama.ornek.com {
    reverse_proxy 127.0.0.1:3000
}

statik.ornek.com {
    root * /var/www/statik
    file_server
    encode gzip zstd
}

Bu iki blok, iki alan adı için otomatik sertifikalı, sıkıştırmalı ve yönlendirmeli bir kurulum verir. Aynı sonucu nginx ile elde etmek belirgin biçimde daha uzun bir dosya ve ayrı bir sertifika aracı gerektirir.

Caddy’nin sınırları: konteyner keşfi doğal değildir (yeni servis eklerken dosyayı düzenlersiniz), çok ayrıntılı önbellek ve hız sınırı senaryolarında nginx kadar esnek değildir, ve topluluk bilgi birikimi daha dardır.

Sertifika yönetimi kutudan çıktığı için sık gözden kaçan bir nokta: kalıcı veri dizini. Caddy’yi konteynerde çalıştırıyorsanız sertifika deposunu bir hacme bağlayın, aksi halde her yeniden başlatmada sertifika yeniden istenir.

TLS sertifikası yenilemesi neden sessizce bozulur?

Üç seçenekte de sertifika yönetimi ACME protokolü üzerinden otomatik yürür. Buradaki asıl risk kurulum değil, sessiz bozulmadır. Otomatik yenileme kurulmuş bir sistemde yenileme şu sebeplerle durabilir:

• 80 portu kapatılmış (HTTP doğrulaması bu portu kullanır)
• DNS kaydı değişmiş veya alan adı başka bir yere yönlenmiş
• Disk dolmuş, sertifika yazılamıyor
• Sertifika deposu kalıcı değil, her başlatmada sıfırlanıyor ve hız sınırına takılıyor
• Bir yönlendirme kuralı doğrulama isteğini engelliyor

Bu bozulmaların hiçbiri anında görünmez; sertifika süresi dolana kadar her şey normal çalışır ve bir sabah site erişilemez hâle gelir.

Tek güvenilir önlem, sertifika bitiş tarihini bağımsız olarak izlemektir. Vekil sunucunun kendi durumuna değil, dışarıdan bakan bir kontrole güvenin:

# Sertifikanın gerçek bitiş tarihi (dışarıdan bakış)
echo | openssl s_client -servername uygulama.ornek.com \
  -connect uygulama.ornek.com:443 2>/dev/null | openssl x509 -noout -dates

Bunu izleme sisteminize bir kontrol olarak ekleyin ve en az üç hafta önceden uyarı üretsin; kurgusu sunucu izleme rehberinde.

Ters vekil sunucuda en sık yapılan hatalar neler?

1. Arka ucu tüm arayüzlerde açık bırakmak. Ters vekil sunucu koyup arka ucu 0.0.0.0 üzerinde dinletmek, korumayı baştan devre dışı bırakır. Arka uçlar 127.0.0.1 veya iç ağda dinlemeli.
2. X-Forwarded-* başlıklarını atlamak. Uygulama tüm istekleri yerelden geliyor sanır; hız sınırı, oturum ve loglama bozulur. Uygulama tarafında da bu başlıklara güvenmesi ayrıca yapılandırılmalıdır.
3. WebSocket yapılandırmasını unutmak. Gerçek zamanlı özellikler sessizce çalışmaz; hata genellikle uygulamada aranır, oysa vekil sunucudadır.
4. Sertifika deposunu kalıcı yapmamak. Her yeniden başlatmada yeni sertifika istenir ve hız sınırına takılır.
5. Vekil sunucu yönetim arayüzünü açık bırakmak. Traefik’in panosu gibi arayüzler, yapılandırmanın tamamını gösterir; internete açılmamalı veya en azından kimlik doğrulama arkasına alınmalıdır.

Karar özeti ve sonraki adım

Kısa yol: konteyner ortamında sık değişen servisler varsa Traefik, az sayıda servis ve sadelik istiyorsanız Caddy, yüksek trafik ve ince ayar gerekiyorsa nginx.

Bunların hepsini elle kurmak yerine dağıtımla birlikte gelen bir katman da tercih edebilirsiniz: kendi sunucunuzda çalışan bir dağıtım paneli, ters vekil sunucuyu ve sertifika yönetimini kendisi üstlenir. Bu yaklaşımın tamamı Coolify ile self-hosted PaaS yazısında; alan adı ve sertifika tarafının ayrıntısı Coolify domain ve SSL yapılandırmasında.

Konteyner ağ modellerini ve servislerin birbirine nasıl eriştiğini Docker ağ yapılandırması yazısı, compose dosyasının üretim ayarlarını Docker Compose üretim rehberi tamamlıyor. Sunucu katmanlarının bütünü Linux sunucu yönetimi yol haritasında.

Kaynaklar

• nginx Beginner’s Guide (proxy_pass ve sunucu blokları)
• Traefik Documentation (sağlayıcılar, yönlendiriciler, ACME çözümleyicileri)
• RFC 8555: ACME (otomatik sertifika protokolü)