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

Nginx, Caddy ve Traefik: kısa cevap

Nginx, Caddy ve Traefik, reverse proxy olarak aynı işi yapar: 443 numaralı portu dinler, gelen her istekteki ana makine adını (hostname) okur ve isteği VPS üzerindeki ilgili servise iletir. Bu üç seçenekten herhangi biri, dört adet self-hosted uygulamayı tek bir genel IP adresi arkasında çalıştırmanızı sağlar ve hepsi, uygulamalarınızın yavaş kalacağı kadar hızlıdır. Farklılık, her birinin TLS (transport layer security) sertifikasını nasıl aldığı ve her yeni uygulamanın size ne kadar yapılandırma maliyeti çıkardığıdır. Diğer fark ise, yaygın rehberlerin atladığı bir şeye ihtiyaç duyduğunuz gün ortaya çıkar.

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 kullanıyorsanız veya yanıt önbellekleme (response caching), istemci sertifikaları, ham TCP yönlendirme ya da yeniden yazmak istemeyeceğiniz kapsamlı bir mevcut yapılandırmanı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. Her üçü 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 sertifika talep eder. Site adresi olarak app.example.com yazın; Caddy, ACME (otomatik sertifika yönetim ortamı) üzerinden Let's Encrypt'ten sertifika ister, başarısız olursa ZeroSSL'e geçer, 80 numaralı portta HTTP'den HTTPS'e yönlendirmeyi yapar ve sertifikayı otomatik olarak yeniler. İkinci bir araca veya kontrol zamanlayıcısına gerek 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 kurulum sonrası sertifikanın yeniden oluşturulmasını kabul edin. Herkese açık olmayan bir ana makine adı için tls internal, Caddy'nin kendi yerel sertifika yetkilisi ile 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 işlemi, paketin kurduğu bir systemd zamanlayıcısı üzerinden çalışır; dolayısıyla 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 rehberinde mevcuttur; 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 (resolver) 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 dosya umask değerinizi devralır; çoğu kullanıcı bu hata ile bu şekilde karşılaşır.

Her üçü için de geçerli olan bir kural vardır. HTTP-01 sınaması, sertifika yetkilisi geri bağlantı kuracağı için 80 numaralı portun internete açık olmasını 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 söz dizimi yoğunluğu farkı, iddia edilmek yerine doğrudan görülebilir hale gelmiştir.

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ısını almak, her yeniden yükleme öncesinde yapılması gereken kontroldür. İkinci uygulama, ana bilgisayar adı ve port değiştirilmiş aynı bloktan ibarettir. 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. Bu dört başlığın her birinin ne işe yaradığı ve proxy_pass üzerindeki eğik çizginin (trailing slash) uygulamanızın aldığı yolu neden sessizce değiştirdiği, bu Nginx server bloğu incelemesinde yönerge yönerge açıklanmıştır.

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 ayarlarını kendisi yapar ve varsayılan olarak istemcinin bu başlıklarda gönderdiği değerleri dikkate almaz; böylece bir istek, arka uç servisinize nereden geldiği konusunda yanıltıcı 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 ayar yapılması 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 compose dosyası içerisindeki etiketler (labels) aracılığıyla kendi yönlendirme ayarını 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 ulaşır. 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 uygulamayı 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 hesaplanmıştır. Nginx sunucu bloğu 11 boş olmayan satırdan oluşur ve bunu her ana makine adı 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, ardından uygulama başına 5 etiket gerektirir.

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; iki toplam yaklaşık üçüncü sitede kesişir. Bunun altında, statik yapılandırma ihtiyaç duymadığınız bir ek yüktür. Bunun üzerinde ise etiketler öne geçer ve önde kalmaya 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 başarısız olduğu nokta budur: aylar önce varlığı sona ermiş uygulamalar için kalan eski sunucu blokları.

Satır sayısı Nginx'i olduğundan daha iyi gösterir. Bu blokların her biri bir sembolik bağlantı, bir nginx -t, bir yeniden yükleme 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ı düşürmeden yeniden yükleme yapar. Aradaki fark, gece saat birde hatırlamanız gereken ayrı adımların sayısıdır.

Konteynerleriniz hakkında hangisi bilgi sahibidir?

Traefik, Docker soketini izler ve konteynerler başlatılıp durduruldukça konteyner etiketlerinden yönlendiriciler oluşturur. Bu işlevi burada başka hiçbir araç yapmaz. Nginx ve Caddy, yeni bir konteyner ortaya çıktığında yapılandırma dosyası 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 makinenin dosya sistemini içine mount edilmiş bir konteyner başlatabilir; bu da ana makinede root yetkisi demektir. Soketi salt okunur (read-only) olarak mount etmek, riski tamamen ortadan kaldırmasa da azaltır. Eğer bu durum tehdit modeliniz için önemliyse, araya yalnızca Traefik'in ihtiyaç duyduğu konteyner listesi uç noktalarını dışarı açan bir soket proxy'si yerleştirin.

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

Websocket ve akış: ne bozulur ve neden

Nginx, yardım gerektiren taraftır. 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 yer alı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 hatası verirken, arka uç günlüğünüzde sıradan bir GET isteği görünür. map değişkeni gereklidir çünkü sabit kodlanmış bir Connection: upgrade, close içermesi gereken düz istekler dahil her istekte gönderilirdi.

İki Nginx varsayılanı daha sorun yaratır. proxy_read_timeout değeri 60 saniyedir ve yükseltme sonrası tünel için geçerlidir; bu nedenle bir dakika boyunca trafik almayan bir websocket, proxy tarafından kapatılır. Ayrıca, ilgili location bloğunda proxy_buffering off; ayarını yapmadığınız sürece, sunucu tarafından gönderilen olaylar (SSE) geç veya kesik kesik ulaşır; çünkü nginx, sayfanız yanıtı beklerken veriyi kendi arabelleğinde tutar.

Caddy, yükseltme işlemini gerçekleştirir ve herhangi bir yönergeye gerek duymadan 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, bu sayede akış işlemleri herhangi bir müdahale gerektirmeden çalışır. Traefik, yükseltme isteklerini doğrudan iletir ve siz kendi buffering ara katman yazılımınızı eklemediğiniz sürece yanıtları arabelleğe almaz. Servisleriniz sohbet, web terminali, günlük 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ırları hak ettiği yer burasıdır.

• İstemci sertifikaları, diğer adıyla mTLS (karşılıklı TLS); burada istemcinin de bir sertifika sunması gerekir. Nginx, server bloğu içinde ssl_client_certificate /etc/ssl/ca.pem; ve ssl_verify_client on; direktiflerini ister. Caddy, tls içinde bir client_auth bloğu gerektirir. Traefik etiketleri bunu doğrudan ifade edemez: bir dosya sağlayıcısında TLS seçeneği tanımlamanız ve traefik.http.routers.app.tls.options=mtls@file ile yönlendiriciyi 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, varsayılan olarak istek gövdelerini 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ı yer alır. client_max_body_size değerini artırmanız gerekir. 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. Nginx, proxy_cache özelliğine sahiptir ve bu özellik oldukça olgundur. Caddy, derlenmiş bir eklenti gerektirir. Traefik'in açık kaynak sürümünde ise hiçbir HTTP önbelleği bulunmaz; bu durum, her proxy'nin önbellekleme yaptığını varsayan kullanıcıları şaşırtır.
• Ham TCP veya UDP, veritabanı portu veya oyun sunucusu için. Nginx, stream modülüne sahiptir. Traefik, kendi giriş noktalarında 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ıysa, Ubuntu 24.04 üzerinde bir LAMP yığını zaten Apache içerir. Önüne bir proxy eklemek, başlıkları ayarlayan ve URL'leri yeniden yazan iki farklı katman oluşturur. TLS sonlandırmasını hangisinin yapacağına karar verin, ardından diğerini loopback üzerinde düz HTTP ile çalışacak şekilde bırakın.

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, bu durumu sessizce geçersiz kılar. -p 8080:80 ile bir portu dışarıya açtığınızda, nat tablosuna bir DNAT kuralı yazılır. 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 ile 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 yapılan yöntem budur. Mekanizma ve çözüm yolu Docker tarafından yayınlanan portların neden ufw'yi baypas ettiği başlığında açıklanmıştır.

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

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

Connection refused veya bir zaman aşımı hatası, elde etmek istediğiniz sonuçtur. Bir HTTP yanıtı alıyorsanız, uygulama proxy'nizden geçmeden erişilebilir durumdadır ve yukarıda yapılandırdığınız her şey sadece bir süsten 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 kopyalayıp yapıştırabileceğiniz çö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 başlamaması yerine Traefik'ten gelen bir 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 (response caching) ve istemci sertifikaları için halihazırda bir çözümü vardır ve neredeyse tüm üçüncü taraf kılavuzlar Nginx'i temel alır. Bunun bedeli, sertifikaların ve WebSocket desteğinin size hazır sunulması yerine sizin yapılandırmanız gereken unsurlar olmasıdır.

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

FAQ

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

Ara sıra yeni servisler eklediğiniz üç veya dört uygulama için Traefik, her uygulamanın kendi yönlendirme etiketlerini taşıması ve merkezi bir dosyada düzenleme gerektirmemesi nedeniyle verimlidir. Servisleriniz kararlıysa ve temel amacınız HTTPS yönetimini kolaylaştırmaksa, Caddy öğrenmesi daha kolay ve hata yapma 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 kullanım senaryolarında evet. Site adresi olarak herkese açık bir alan adı tanımlamak yapılandırmanın tamamıdır: Caddy, ACME üzerinden sertifika talebinde bulunur, 80 numaralı porttan yönlendirmeyi yapar ve süresi dolmadan önce yeniler. Ancak iki koşulun sağlanması gerekir. HTTP-01 sınaması için 80 numaralı portun internetten erişilebilir olması ve sertifika otoritesi ismi çözümleyip geri bağlantı kuracağı için alan adının DNS A veya AAAA kaydının halihazırda VPS'i işaret ediyor olması şarttır.

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

Aynı portlar üzerinde çalıştıramazsınız. Hangisi ikinci olarak başlarsa 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ıyla günlüğe kayıt düşer ve kapanır. Bir proxy'yi 80 ve 443 portlarında çalıştırın ve diğer her şeyi onun arkasına alın. Eğer taşıma yapıyorsanız, alan adlarını tek tek taşıyın: son site taşınana kadar ön taraftaki 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) işlemi 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 location bloğunda proxy_read_timeout 3600s; değerini artırın veya uygulamanızı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 yüzden aynı uygulama bu proxy'lerin arkasında kararlı çalışırken Nginx arkasında kararsız görünebilir.