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 yanıtlarını önbelleğe alır ve yenileme hatalarında yedek sertifika sağlayıcısına geçer. HTTP/1.1, HTTP/2 ve HTTP/3 desteği varsayılan olarak etkindir.

Ö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ı.

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