Caddy

Caddy; Go dili ile yazılmış, tek dosya olarak dağıtılan bir web sunucusu ve reverse proxy’dir. Kendisini diğer sunuculardan ayıran özellik, HTTPS’i varsayılan kabul etmesidir: yapılandırmada bir alan adı tanımlandığı anda sertifikayı ACME üzerinden alır, süresi dolmadan yeniler ve HTTP trafiğini HTTPS’e yönlendirir.

Sertifika bilgilerini yerel depolama alanında yönetir ve yenileme sürecini otomatikleştirir. HTTP/1.1 ve HTTP/2 desteğinin yanında HTTP/3 de uygun listener ve ağ koşulları sağlandığında etkinleştirilebilir; protokol seçimi istemci uyumluluğu ve edge tasarımıyla doğrulanır.

Caddy, Nginx ve Traefik: bakım modeli farkı

Caddy’nin temel avantajı yalnızca kısa konfigürasyon değildir; HTTPS yaşam döngüsünün web sunucusuyla birlikte yönetilmesidir. Sertifika alma ve yenilemenin ayrı betiklere dağıldığı ortamlarda bu yaklaşım işletimi sadeleştirebilir. Ancak mevcut Nginx yapılandırmasında özel modüller, karmaşık cache kuralları veya uygulamanın bağımlı olduğu yönlendirmeler varsa geçişin maliyeti ayrıca hesaplanır.

Öne çıkan özellikler

• Otomatik HTTPS: Let’s Encrypt ve ZeroSSL ile ACME (HTTP-01, TLS-ALPN-01, DNS-01) doğrulaması; otomatik yenileme ve yönlendirme.
• Sade yapılandırma: Onlarca satırlık bir Nginx server bloğunun karşılığı, Caddyfile’da genellikle birkaç satırdır.
• Çalışma anında yeniden yapılandırma: 2019 portundaki admin API veya yerel CLI üzerinden bağlantılar kesilmeden konfigürasyon değişimi.
• Eklenti mimarisi: xcaddy ile Caddy derlenirken eklenti eklenir; DNS sağlayıcı modülleri, layer4 ile TCP/UDP proxy, Redis/Consul sertifika depoları, WAF modülleri gibi eklentiler mevcuttur.
• Dahili CA: İç ağ servisleri için kendi sertifika otoritesini çalıştırabilir; geliştirme ortamında localhost bile HTTPS ile sunulur.
• Gözlemlenebilirlik: Prometheus uyumlu /metrics çıktısı ve yapılandırılmış (JSON) erişim logları.

Mono’da kullanım alanları

• Çok alan adlı reverse proxy: Çok sayıda müşteri alan adının tek noktadan, elle sertifika işlemi olmaksızın sunulması. Talep anında sertifika üretimi (on_demand_tls) sayesinde alan adı listesinin önceden bilinmesi gerekmez.
• Statik site ve dokümantasyon sunumu: Hugo ile üretilen çıktının doğrudan servis edilmesi; file_server ve önceden sıkıştırılmış dosya desteği.
• PHP projeleri: FrankenPHP Caddy üzerine kuruludur; PHP uygulamaları ayrı bir PHP-FPM katmanı olmadan çalıştırılabilir.
• Geliştirme ve canlı ortamları: Kurulum maliyeti düşük olduğu için geliştirme ve canlı ortamlarda benzer TLS davranışı sağlanır.
• İç servislerin önü: Grafana, Zabbix, Harbor gibi arayüzlerin kimlik doğrulama ve TLS ile yayınlanması.

Otomatik HTTPS’in sınırları ve güvenlik koşulları

Otomatik sertifika yönetimi, alan adı sahipliğinin doğrulanması gereğini ortadan kaldırmaz. DNS kaydı, kullanılan challenge türü, dış erişim ve sertifika otoritesinin kotaları dikkate alınır. İnternete kapalı bir servis için kontrol edilen genel alan adında DNS-01 kullanılabilir; kurum içi adlarda dahili CA tercih edildiğinde istemcilere güven kökü dağıtılmalıdır.

Çok kiracılı sistemlerde on-demand TLS sınırsız açılmaz. Yalnızca kuruma veya kayıtlı müşterilere ait alan adlarının sertifika talep edebilmesini sağlayan bir yetkilendirme mekanizması gerekir. DNS sağlayıcı anahtarı kullanılacaksa yetki alanı mümkün olduğunca dar tutulur; anahtar konfigürasyon deposuna yazılmaz.

Birden fazla Caddy örneğinde sertifika depolaması ve yenileme koordinasyonu planlanmalıdır. Ortak bir depolama eklentisi seçildiğinde eklentinin sürümü, kilitleme davranışı ve erişim yetkileri doğrulanır. Depolama kesintisinin mevcut ve yeni TLS bağlantılarına etkisi ayrıca test edilir. Her node’un bağımsız sertifika üretmesini rastlantısal biçimde çalışmaya bırakmak sürdürülebilir bir HA stratejisi değildir.

Nginx’ten Caddy’ye geçiş nasıl doğrulanır?

Önce alan adları, yönlendirmeler, upload sınırları ve proxy başlıkları çıkarılır. Kuralın yeni söz diziminde yazılmış olması yeterli değildir: path yeniden yazımı, trailing slash, WebSocket ve uygulamanın HTTPS algısı aynı davranışı üretmelidir. Gerçek istemci IP’si yalnızca güvenilen proxy zincirinden alınır.

Pilot uygulamada sertifika yenileme, backend erişilemezliği ve konfigürasyon geri dönüşü denenir. Başarı; sertifikanın ilk kez alınması değil, yenileme ve arıza anında da sürecin yönetilebilir kalmasıdır. Admin API erişimi uygulama trafiğinden ayrılır; API üzerinden yapılan değişikliklerin sürümlenen Caddyfile ile çelişmemesi için tek bir konfigürasyon sahipliği tanımlanır.

Mono’nun yaklaşımı

• Konfigürasyon kaynağı tek: Caddyfile sürüm kontrolünde tutulur, sunucuda elle düzenleme yapılmaz. Değişiklikler caddy validate sonrası dağıtılır.
• Depolama dizini yedeklenir: /var/lib/caddy altındaki sertifika ve hesap anahtarları yedekleme kapsamına alınır; gereksiz ACME trafiği ve kesinti demektir.
• Admin API kapalı ya da kısıtlı: Canlı ortamlarda admin arayüzü tamamen kapatılır veya yalnızca localhosta bağlanır; uzaktan yönetim gerekiyorsa karşılıklı TLS ile korunur.
• Ayrıcalıksız çalışma: Servis caddy kullanıcısıyla çalışır; 80/443 portlarına bağlanabilmek için CAP_NET_BIND_SERVICE yetkisi verilir, root kullanılmaz.
• Loglar merkezîdir: JSON erişim logları Loki veya OpenSearch gibi yapılara aktarılır; yetkilendirme başlıkları ve çerezler loglanmaz.

Yaygın sorunlar ve çözümler

• Sertifika alınamıyor: HTTP-01 doğrulaması için 80, TLS-ALPN-01 için 443 portu internetten erişilebilir olmalıdır. Portlar kapalıysa ya da alan adı henüz sunucuya çözümlenmiyorsa doğrulama başarısız olur; bu durumda DNS-01 kullanılır.
• Let’s Encrypt kotasına takılma: Aynı alan adı için tekrarlanan başarısız denemeler kotayı tüketir. Yeni yapılandırmalar önce acme_ca ile Let’s Encrypt staging ortamına yönlendirilerek denenir.
• Cluster paylaşımlı sertifika: Ortak sertifika deposu tanımlanmayan çok örnekli kurulumlarda her düğüm ayrı sertifika ister. Çözüm, Redis/Consul/S3 depolama eklentisiyle depoyu paylaşmaktır.
• Yeniden başlatmada sertifikaların kaybı: Konteynerli kurulumlarda veri dizini kalıcı bir birime bağlanmazsa her yeniden başlatmada sertifikalar sıfırdan alınır.
• Reverse proxy arkasında yanlış istemci IP’si: Önde CDN veya L4 yük dengeleyici varsa trusted_proxies tanımlanmalıdır; aksi hâlde loglarda ve hız sınırlamada proxy’nin IP’si görünür.
• Uzun süren isteklerde zaman aşımı: reverse_proxy altındaki okuma/yazma zaman aşımları uygulamanın p99 süresine göre ayarlanır; büyük dosya yüklemelerinde varsayılanlar yetersiz kalabilir.

İlgili hizmetlerimiz

Sıkça sorulan sorular