Nginx, Caddy ve Traefik: Hangi Reverse Proxy Seçilmeli?

Nginx, Caddy ve Traefik: Kısa yanıt

Nginx, Caddy ve Traefik, reverse proxy olarak aynı işi yapar: 443 numaralı portu dinler, gelen her istekteki hostname bilgisini okur ve bunu VPS üzerindeki ilgili servise iletir. Bu üç seçenekten herhangi biri, dört farklı self-hosted uygulamayı tek bir genel IP adresi arkasında çalıştırmanızı sağlar; hepsi de uygulamalarınızın darboğaz oluşturmayacağı kadar hızlıdır. Farklılık, her birinin TLS (transport layer security) sertifikasını nasıl edindiği ve her yeni uygulama için ne kadar yapılandırma maliyeti çıkardığı noktasında ortaya çıkar. Diğer fark ise, yaygın rehberlerin atladığı özel bir ihtiyacınız olduğunda belirginleşir.

HTTPS işlemlerinin sizin yerinize halledilmesini istiyorsanız ve servisleriniz standart web uygulamalarıysa Caddy'yi seçin. Her şey Docker Compose üzerinde çalışıyorsa ve birkaç haftada bir yeni bir servis ekliyorsanız Traefik'i seçin. Eğer halihazırda Nginx kullanıyorsanız veya response caching, client certificates, raw TCP forwarding gibi özelliklere ya da yeniden yazmak istemediğiniz kapsamlı bir yapılandırmaya ihtiyacınız varsa Nginx'i seçin.

Her biri TLS sertifikasını nasıl alır?

Çoğu kullanıcı için karar aşaması burasıdır, bu yüzden işe buradan başlayın. Üçü de aynı otoriteden aynı sertifikayı alır. Ancak bu noktaya ulaşmak için yapılan işlemler farklıdır.

Caddy, bir ana makine adı belirttiğiniz için sertifikayı talep eder. Bir site adresi olarak app.example.com yazın; Caddy, ACME (otomatik sertifika yönetim ortamı) üzerinden Let's Encrypt'ten sertifika talep eder, başarısız olursa ZeroSSL'e geçer, 80 numaralı porttaki HTTP'den HTTPS'e yönlendirmeyi yapar ve sertifikayı otomatik olarak yeniler. İkinci bir araç veya kontrol zamanlayıcısı yoktur. Sertifikalar, paket kurulumunda /var/lib/caddy/.local/share/caddy dizininde bulunan caddy kullanıcısının veri dizininde saklanır; bu nedenle bu yolu yedeklerinize ekleyin veya yeniden kurulumdan sonra yeni bir sertifika oluşturulmasını kabul edin. Genel ağa açık olmayan bir ana makine adı için tls internal, bunun yerine Caddy'nin kendi yerel sertifika yetkilisiyle imzalama yapar. Bu, Ubuntu üzerinde kendinden imzalı sertifika oluşturma ile aynı sonucu verir, ancak yenileme işlemi sizin yerinize halledilir.

Nginx'in yerleşik bir ACME istemcisi yoktur. Certbot sertifikayı alır ve --nginx eklentisi, 443 dinleyicisini ve yönlendirmeyi eklemek için sunucu bloğunuzu yeniden yazar. Yenileme, paketin yüklediği bir systemd zamanlayıcısı üzerinden çalışır; bu nedenle iki hareketli parça ve doğrulanması gereken iki nokta vardır: systemctl list-timers | grep certbot zamanlayıcının var olduğunu gösterir, sudo certbot renew --dry-run ise yenileme yolunun hala çalıştığını kanıtlar. Adım adım talimatlar Nginx ile Ubuntu 24.04 üzerinde Certbot başlığında yer alır; aynı araç, listelemek istediğinizden daha fazla alt alan adınız olduğunda DNS-01 sınaması ile wildcard sertifikası almak için de kullanılır.

Traefik kendi ACME istemcisini barındırır. Statik yapılandırmada bir sertifika çözümleyici yapılandırırsınız ve her yönlendirici bunu kullanabilir. Hesap anahtarı ve sertifikalar dahil tüm durum, tek bir acme.json dosyasında tutulur. Traefik, bu dosya sahibi dışında herhangi biri tarafından okunabilir durumdaysa dosyayı kullanmayı reddeder ve çözümleyiciyi devre dışı bırakmadan önce sizi uyarır:

The ACME resolver "le" is skipped from the resolvers list because: unable to get ACME account: permissions 660 for /letsencrypt/acme.json are too open, please use 600

Bir dizini mount edin ve dosyanın Traefik tarafından oluşturulmasına izin verin. Dosyayı önce touch ile oluşturursanız, umask değerinizi devralır; çoğu kullanıcı bu hatayla bu şekilde karşılaşır.

Üçü için de geçerli olan bir kural vardır. HTTP-01 sınaması, sertifika yetkilisi geri bağlantı kurduğu için internetten 80 numaralı porta erişilebilmesini gerektirir. Yalnızca 443 numaralı portu açarsanız, sertifika düzenleme işlemi DNS hatası gibi görünen bir şekilde başarısız olur.

Üç farklı yapılandırmada aynı iki uygulamalı yönlendirme görevi

Görev: app.example.com, 127.0.0.1:8080 üzerindeki bir servise; files.example.com ise 127.0.0.1:8081 üzerindeki bir servise, her ikisi de HTTPS üzerinden yönlendirilecektir. Söz konusu yapılandırmaların tamamı aşağıda sunulmuştur; böylece söz konusu karmaşıklık farkı iddia edilmek yerine doğrudan görülebilir.

Nginx

# /etc/nginx/sites-available/app.example.com
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

Ardından bağlantıyı oluşturun, test edin, yeniden yükleyin ve sertifikayı ekleyin.

sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d app.example.com

nginx -t komutu ile syntax is ok ve test is successful çıktılarını almak, her yeniden yükleme öncesinde yapılması gereken kontroldür. İkinci uygulama, ana makine adı ve port değiştirilmiş aynı bloktan oluşur. proxy_set_header satırları süsleme değildir: proxy_pass bir adres belirttiğinde, Nginx varsayılan olarak Host: 127.0.0.1:8080 değerini upstream'e gönderir; bu nedenle Host başlığından mutlak URL'ler oluşturan bir uygulama, kullanıcılarınızı localhost adresine yönlendirecektir.

Caddy

app.example.com {
	reverse_proxy 127.0.0.1:8080
}

files.example.com {
	reverse_proxy 127.0.0.1:8081
}

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Dosyanın tamamı bundan ibarettir. reverse_proxy; X-Forwarded-For, X-Forwarded-Proto ve X-Forwarded-Host değerlerini kendisi ayarlar ve varsayılan olarak istemcinin bu başlıklarda gönderdiği değerleri yok sayar; böylece bir istek, arka uç servisine nereden geldiği konusunda yanlış bilgi veremez. Sertifikalar, 80 numaralı port yönlendirmesi ve yenileme işlemleri, iki site adresi üzerinden otomatik olarak gerçekleşir. Dosyada bunlar için başka bir komut gerekmez.

Traefik

Traefik, herhangi bir yönlendirme yapmadan önce statik bir yapılandırmaya ihtiyaç duyar. Bir Compose servisi olarak, Ağustos 2026 itibarıyla güncel olan imaj etiketiyle:

services:
  traefik:
    image: traefik:v3.7
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.email=you@example.com"
      - "--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

Her uygulama, kendi yönlendirme ayarlarını kendi compose dosyası içerisindeki etiketler (labels) üzerinde taşır:

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"
      - "traefik.http.routers.app.entrypoints=websecure"
      - "traefik.http.routers.app.tls.certresolver=le"
      - "traefik.http.services.app.loadbalancer.server.port=8080"

loadbalancer.server.port, container içindeki portu ifade eder; yayınlanan bir port değildir, çünkü Traefik container'a paylaşımlı bir Docker ağı üzerinden erişir. Uygulamanın herhangi bir ports: satırına ihtiyacı yoktur ve asıl avantaj da budur: yalnızca Traefik dış dünyaya açılır. Paylaşımlı ağ ve yönlendirme ara katmanı (middleware) dahil olmak üzere tam kurulum, Traefik ve Docker Compose ile birden fazla uygulama yönlendirme rehberinde yer almaktadır.

Her ek uygulama ne kadar yapılandırma maliyeti getirir?

[
  {
    "tool": "Nginx",
    "proxy_setup_lines": 0,
    "lines_per_app": 11
  },
  {
    "tool": "Caddy",
    "proxy_setup_lines": 0,
    "lines_per_app": 3
  },
  {
    "tool": "Traefik",
    "proxy_setup_lines": 17,
    "lines_per_app": 5
  }
]

Yukarıdaki bloklardan hesaplandığında; Nginx sunucu bloğu boş olmayan 11 satırdan oluşur ve bunu her ana makine adı (hostname) için tekrar yazarsınız. Caddy site bloğu 3 satırdır. Traefik, tek bir isteği karşılamadan önce 17 satırlık statik yapılandırma gerektirir, ardından her uygulama için 5 etiket eklenir.

Kazananı değil, takası değerlendirin. Traefik, ilk uygulamadan önce en yüksek maliyeti, sonraki her uygulama için ise en düşük maliyeti getirir; bu iki toplam yaklaşık üçüncü sitede kesişir. Bu sayının altında, statik yapılandırma gereksiz bir yüktür. Üzerinde ise etiketler öne geçer ve arayı açmaya devam eder, çünkü yönlendirme, yönlendirdiği servisin yanında yer alır. Servisi sildiğinizde rotası da onunla birlikte silinir; merkezi bir yapılandırma dosyasının zayıf olduğu nokta budur: aylar önce varlığı sona ermiş uygulamalara ait güncelliğini yitirmiş sunucu blokları.

Satır sayısı Nginx'i olduğundan daha iyi gösterir. Bu blokların her biri bir sembolik bağ (symlink), bir nginx -t, bir yeniden yükleme (reload) ve bir certbot çalıştırma işlemi gerektirirken; Caddy düzenlemesi tek bir yeniden yükleme, Traefik düzenlemesi ise hiçbir komut gerektirmez. Her üçü de canlı bağlantıları koparmadan yeniden yükleme yapabilir. Aradaki fark, gece yarısı hatırlamanız gereken ayrı adımların sayısıdır.

Kapsayıcılarınız hakkında hangisi bilgi sahibidir?

Traefik, Docker soketini izler ve kapsayıcılar başlatılıp durduruldukça kapsayıcı etiketlerinden yönlendiriciler oluşturur. Burada başka hiçbir araç bunu yapmaz. Nginx ve Caddy, yeni bir kapsayıcı ortaya çıktığında yapılandırma düzenlemesi ve yeniden yükleme gerektirir; ayrıca ulaşabilecekleri bir adrese ihtiyaç duyarlar: ya loopback üzerinde yayınlanan bir port ya da proxy'nin bağlı olduğu paylaşımlı bir Docker ağı.

Bu özelliğin bir bedeli vardır ve bunu açıkça belirtmek gerekir. Traefik, /var/run/docker.sock dosyasını okur. Bu soketle iletişim kurabilen herkes, ana makine dosya sisteminin içine mount edildiği bir kapsayıcı başlatabilir; bu da ana makinede root yetkisi demektir. Salt okunur (read-only) olarak mount etmek, riski tamamen ortadan kaldırmasa da azaltır. Tehdit modeliniz için bu durum önemliyse, araya yalnızca Traefik'in ihtiyaç duyduğu kapsayıcı listesi uç noktalarını dışa açan bir soket proxy yerleştirin.

Caddy, bir topluluk eklentisi aracılığıyla etiket tabanlı keşif yapabilir; ancak Caddy eklentileri derleme aşamasında dahil edildiğinden, özel bir binary veya xcaddy ile özel bir imaj oluşturmanız gerekir; bu durumda da söz konusu derlemenin ve güncellemelerinin sorumluluğu size geçer. Üç veya dört servis için bir Caddyfile düzenlemek daha az iş yükü gerektirir.

Websocket ve streaming: ne bozulur ve neden

Yardıma ihtiyacı olan Nginx'tir. Bir WebSocket bağlantısı, Upgrade: websocket taşıyan bir HTTP isteği olarak başlar ve siz belirtmediğiniz sürece Nginx, hop-by-hop başlıklarını upstream tarafına iletmez.

# /etc/nginx/conf.d/upgrade-map.conf
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Ardından, location bloğu içinde, tamamının bulunması gereken üç satır vardır:

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

Bunları çıkarırsanız tarayıcı konsolu WebSocket connection to 'wss://app.example.com/ws' failed çıktısı verirken, backend loglarınızda sıradan bir GET isteği görünür. map değişkeni, sabit kodlanmış bir Connection: upgrade değerinin, close demesi gereken düz istekler de dahil olmak üzere her istekte gönderilmesini önlemek için kullanılır.

İki Nginx varsayılanı daha sorun yaratır. proxy_read_timeout değeri 60 saniyedir ve upgrade işleminden sonra tünel için geçerli olur; bu nedenle bir dakika boyunca trafik almayan bir websocket bağlantısı proxy tarafından kapatılır. Ayrıca, proxy_buffering off; ayarını ilgili location bloğunda yapmadığınız sürece, server-sent events (SSE) geç ulaşır veya kesik kesik gelir; çünkü Nginx, sayfanız yanıtı beklerken veriyi kendi tampon belleğinde (buffer) tutar.

Caddy, upgrade işlemini gerçekleştirir ve hiçbir direktif gerektirmeden bağlantıyı çift yönlü bir tünele dönüştürür. Ayrıca yanıt text/event-stream olduğunda veya bilinen bir uzunluğa sahip olmadığında veriyi hemen iletir (flush), bu sayede streaming hiçbir ek ayar gerektirmeden çalışır. Traefik, upgrade isteklerini doğrudan iletir ve siz kendi buffering middleware'inizi eklemediğiniz sürece yanıtları tamponlamaz. Servisleriniz sohbet, web terminali, log takibi veya canlı paneller içeriyorsa, bu durum yazacağınız ve hata ayıklayacağınız yapılandırma miktarı açısından ciddi bir fark yaratır.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name app.example.com;
    client_max_body_size 64m;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        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;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

Sıra dışı bir gereksinim olduğunda ne olur?

Nginx'in fazladan satır yazmayı gerektirdiği durumlar tam olarak bunlardır.

• İstemci sertifikaları, diğer adıyla mTLS (karşılıklı TLS); burada istemcinin de bir sertifika sunması gerekir. Nginx, server bloğu içerisinde ssl_client_certificate /etc/ssl/ca.pem; ve ssl_verify_client on; direktiflerini gerektirir. Caddy, tls içerisinde bir client_auth bloğu ister. Traefik etiketleri (labels) bunu doğrudan ifade edemez: bir dosya sağlayıcısında (file provider) TLS seçeneği tanımlamanız ve traefik.http.routers.app.tls.options=mtls@file ile yönlendiriciyi (router) buna işaret etmeniz gerekir. "Her şey etiketlerde" modeli, buna ihtiyaç duyduğunuz ilk anda bir istisna ile karşılaşır.
• Büyük dosya yüklemeleri. Nginx, istek gövdesini varsayılan olarak 1 MB ile sınırlar. Daha büyük bir yükleme 413 Request Entity Too Large hatası döndürür ve hata günlüğünde client intended to send too large body mesajı görülür. client_max_body_size değerini yükseltin. Caddy ve Traefik varsayılan olarak bir gövde sınırı koymaz, bu nedenle istek doğrudan uygulamanıza ulaşır ve sınır uygulamanızın kendi ayarına göre belirlenir.
• Yanıt önbellekleme (Response caching). Nginx, proxy_cache modülüne sahiptir ve bu modül oldukça olgundur. Caddy, derlenmiş bir eklenti gerektirir. Traefik'in açık kaynaklı sürümünde ise hiçbir HTTP önbelleği bulunmaz; bu durum, her proxy'nin önbellekleme yaptığını varsayan kullanıcılar için şaşırtıcı olabilir.
• Ham TCP veya UDP, bir veritabanı portu veya oyun sunucusu için. Nginx, stream modülüne sahiptir. Traefik, kendi giriş noktalarında (entrypoints) TCP ve UDP yönlendiricilerine sahiptir. Caddy ise başka bir eklenti, dolayısıyla özel bir derleme gerektirir.
• Proxy arkasında halihazırda çalışan bir web sunucusu. Eğer servis klasik bir PHP uygulaması ise, Ubuntu 24.04 üzerinde bir LAMP yığını zaten Apache içerir. Bir proxy'yi bunun önüne koymak, başlıkları (headers) ayarlayan ve URL'leri yeniden yazabilen iki farklı katman oluşturur. TLS sonlandırmasını hangisinin yapacağına karar verin, ardından diğerini loopback üzerinde çalışan düz HTTP'de tutun.

Bu seçimi takip eden güvenlik duvarı tuzağı

Reverse proxy kullanmanın temel amacı, yalnızca 80 ve 443 numaralı portların dış dünyaya açık olmasıdır. Docker ise bu durumu sessizce geçersiz kılar. -p 8080:80 ile bir portu dışarıya açtığınızda, Docker nat tablosuna bir DNAT kuralı yazar. Bu kural, ufw tarafından yönetilen INPUT kurallarından önce değerlendirilir; dolayısıyla ufw deny 8080 bu trafiği engellemez ve uygulamanız, özenle yapılandırdığınız proxy'nin yanında doğrudan genel internete açık hale gelir. Yayınlanan portları 127.0.0.1:8080:80 kullanarak loopback arayüzüne bağlayın veya ports: kullanımını tamamen bırakıp proxy'nin konteynere bir Docker ağı üzerinden erişmesini sağlayın; yukarıdaki Traefik örneğinde uygulanan yöntem budur. Mekanizma ve çözüm Docker tarafından yayınlanan portların ufw'yi neden bypass ettiği başlığında açıklanmıştır.

Test işlemini VPS dışındaki bir makineden gerçekleştirin; çünkü sunucunun kendi üzerinden yapılan bir kontrol her zaman başarılı sonuç verecektir:

curl --max-time 5 http://your.server.address:8080

Connection refused veya bir zaman aşımı hatası almanız gereken sonuçtur. Bir HTTP yanıtı alıyorsanız, uygulama proxy üzerinden geçmeden erişilebilir durumdadır ve yukarıda yapılandırdığınız her şey sadece görsel bir detaydan ibarettir.

Hangi proxy'yi seçmelisiniz?

Çoğunlukla statik siteler ve bir iki uygulama: Caddy. Otomatik HTTPS, en büyük tekrarlayan iş yükünüzü ortadan kaldırır. Yapılandırma, tek bir ekranda okunabilecek kadar kısa kalır ve statik bir site, aynı site bloğu içinde bir root satırı ve bir file_server satırından ibarettir. Bunun bedeli, sıra dışı bir sorunla karşılaşıldığında kopyala-yapıştır yapılabilecek çözüm havuzunun daha küçük olmasıdır.

Sürekli ekleme yaptığınız bir docker-compose homelab: Traefik. Üçüncü servisten sonra, etiketler (labels) merkezi bir dosyayı düzenlemekten daha az iş yükü getirir ve silinen bir servis, rotasını da beraberinde götürür. İlk kurulum için bir öğleden sonranızı ayırın; çünkü entrypoints, routers, services ve middlewares kavramları yeni bir terminolojidir. Etiketteki bir yazım hatası genellikle uygulamanın çalışmadığı izlenimini verse de Traefik tarafında 404 hatası olarak görünür; bu nedenle uygulamanın bozuk olduğunu varsaymadan önce ayrıştırma hatası için docker logs traefik dosyasını inceleyin.

Mevcut bir Nginx yapılandırması veya yukarıdaki listeden herhangi bir gereksinim: Nginx. Yanıt önbellekleme ve istemci sertifikaları için zaten hazır bir çözümü vardır ve neredeyse tüm üçüncü taraf kılavuzlar Nginx varsayımıyla hazırlanmıştır. Bunun bedeli, sertifikaların ve WebSocket desteğinin size hazır sunulması yerine sizin tarafınızdan yapılandırılmasıdır.

Hangisini seçerseniz seçin, tek bir kural geçerlidir: Halka açık arayüzde yalnızca tek bir süreç dinleme yapar; diğer her şey loopback adresi veya özel bir Docker ağı üzerinde çalışır.

FAQ

Tek bir VPS üzerinde birkaç Docker uygulaması için en iyi reverse proxy hangisidir?

Ara sıra ekleme yaptığınız üç veya dört servis için Traefik, her uygulamanın kendi yönlendirme etiketlerini taşıması ve merkezi bir dosyada düzenleme gerektirmemesi nedeniyle verimlidir. Servisler kararlıysa ve temel amacınız HTTPS yönetimini kolaylaştırmaksa, Caddy öğrenmesi daha kolay ve hata payı daha düşük bir seçenektir. Nginx'i ise halihazırda biliyorsanız veya yanıt önbellekleme ya da düz TCP dinleyici gibi diğer ikisinde bulunmayan bir özelliğe ihtiyaç duyuyorsanız tercih edin.

Caddy gerçekten hiçbir sertifika yapılandırması gerektirmiyor mu?

Normal durumlar için evet. Site adresi olarak herkese açık bir ana makine adı belirtmek yapılandırmanın tamamıdır: Caddy, ACME üzerinden sertifika talebinde bulunur, 80 numaralı porttan yönlendirmeyi yapar ve süre dolmadan yenileme işlemini gerçekleştirir. İki koşulun sağlanması gerekir. HTTP-01 sınaması için 80 numaralı portun internetten erişilebilir olması ve ana makine adının DNS A veya AAAA kaydının halihazırda VPS'i işaret etmesi gerekir; çünkü sertifika yetkilisi ismi çözümler ve ona geri bağlanır.

Aynı VPS üzerinde Nginx ve Traefik çalıştırabilir miyim?

Aynı portlar üzerinde çalıştıramazsınız. İkinci başlatılan servis portu bağlayamaz; Nginx bind() to 0.0.0.0:443 failed (98: Address already in use) hatası verirken, Traefik benzer bir bağlama hatası ile günlük kaydı oluşturur ve kapanır. 80 ve 443 numaralı portlarda tek bir proxy çalıştırın ve diğer her şeyi onun arkasına alın. Taşıma yapıyorsanız, ana makine adlarını tek tek taşıyın: son site taşınana kadar ön proxy'nin trafiği loopback portu üzerinden eski proxy'ye iletmesini sağlayın.

Nginx arkasındaki WebSocket bağlantılarım neden 60 saniye sonra kopuyor?

proxy_read_timeout varsayılan olarak 60 saniyedir ve yükseltme (upgrade) tamamlandığında tünel için geçerli olur; bu nedenle bir dakika boyunca trafik akışı olmayan bir bağlantı, uygulamanız tarafından değil proxy tarafından kapatılır. İlgili konum bloğunda proxy_read_timeout 3600s; değerini artırın veya uygulamanın her 30 saniyede bir ping çerçevesi göndermesini sağlayın. Caddy ve Traefik, yükseltilmiş boşta duran bağlantıları bir dakikalık zamanlayıcı ile kapatmaz; bu nedenle aynı uygulama, Nginx arkasında kararsız görünürken bu proxy'ler arkasında kararlı çalışabilir.