Yeni bir VPS, ona yönlendirilmiş bir alan adı ve çalışan bir web sunucusundan bir komut uzakta. Yazacağınız bir sonraki şey ya Caddy ya da Nginx kurar ve o tek karar, makinenin ömrü boyunca TLS'e ne kadar zaman harcayacağınızı şekillendirir. Yani: bir VPS'te Caddy ve Nginx, hangisini kurarsınız?
Aşağıdakiler, her iki araçta da yapılandırılmış aynı üç kurulumdur, yan yana, raporlanan bellek rakamları, wildcard sertifika püf noktası ve zaten Nginx kullanıyorsanız pratik geçiş notlarıyla birlikte.
Kısa Versiyon
- Sonuç: Çoğu yeni VPS iş yükü için Caddy, özellikle bağımsız geliştiriciler, küçük ekipler ve kur-unut TLS için. Modül ekosistemine, açık ayarlamaya, mevcut ekip uzmanlığına veya mümkün olan en küçük bellek ayak izine ihtiyaç duyduğunuzda Nginx'i seçin.
- Otomatik HTTPS: Caddy sertifikaları kendisi alır ve yeniler. Certbot yok, cron yok, reload hook'u yok. Nginx, Certbot'a (veya başka bir ACME istemcisine) ve onun etrafındaki yenileme otomasyonuna ihtiyaç duyar.
- Bellek: Nginx, Go yerine C sayesinde daha yalındır. Bu fark modern bir planda nadiren bir şeyi belirler; rakamlar aşağıdaki tabloda.
- Püf noktası: Caddy, wildcard'lar için sıfır yapılandırma değildir. *.example.com gibi bir ad bir DNS challenge gerektirir, bu da bir eklenti ve bir API token anlamına gelir.
Tüm karşılaştırma tek bir ekranda:
| Caddy | Nginx | |
|---|---|---|
| Dil | Go | C |
| Otomatik HTTPS | Yerleşik (Let's Encrypt + ZeroSSL) | Yok; Certbot'a veya başka bir ACME istemcisine ihtiyaç duyar |
| Yapılandırma ayrıntı düzeyi | Minimal (site başına birkaç satır) | Açık ve ayrıntılı |
| HTTP/3 | HTTPS ile varsayılan olarak açık | 1.25.0'dan beri mevcut; Nginx yapılandırmasında etkinleştirilmesi gerekir. Kaynak derlemeleri şunu gerektirir: --with-http_v3_module. |
| Raporlanan boştaki bellek | 15-25 MB | 2-8 MB |
| 1.000 bağlantıda raporlanan bellek | 80-120 MB | 50-80 MB |
| Modül ekosistemi | Daha küçük, xcaddy ile genişletilir | Büyük ve olgun |
| Lisans | Apache 2.0 | BSD-2-Clause |
Bellek aralıkları şuradan gelir: bir üçüncü taraf VPS testi ve evrensel gereksinimler yerine yön gösterici olarak değerlendirilmelidir. Gerçek kullanım yazılım sürümlerine, etkinleştirilen modüllere, günlük kaydına, trafiğe ve test metodolojisine bağlıdır. Sürüm ve lisans bilgileri projelerin resmi depolarından gelir.
Caddy'nin Otomatik HTTPS'si (ve Aslında Neyin Yerine Geçtiği)
Caddy, TLS sertifikalarını kendi başına alır ve yeniler. Makineye herkese açık bir alan adı yönlendirin, Caddy'yi çalıştırın ve Let's Encrypt veya ZeroSSL'den bir sertifika alır, ardından arka planda yeniler. Certbot yok, cron işi yok, yenileme sonrası reload hook'u yok. Bu, tek cümlede Caddy otomatik HTTPS'sidir ve insanların geçiş yapmasının tüm nedenidir.
Perde arkasında, Caddy şunu kullanır: HTTP-01 (port 80) veya TLS-ALPN-01 (port 443) challenge alan adı sahipliğini kanıtlamak için, ardından herhangi bir ikinci araç olmadan sertifikayı güncel tutar.
Nginx eşdeğeri ayrı bir ACME istemcisi kullanır. Yaygın certbot --nginx iş akışıyla, Certbot sertifikayı alıp kurabilir, ardından yenileme sırasında aynı eklentiyi ve kaydedilen seçenekleri yeniden kullanabilir. Çoğu Certbot kurulumu ayrıca şunu çalıştıran zamanlanmış bir görev içerir: certbot renew otomatik olarak.
Şunu kullanırsanız: certbot certonly veya yenilenen dosyaları yalnızca diske yazan başka bir ACME istemcisi, şunu ekleyin: deploy hook başarılı bir yenilemeden sonra Nginx'i yeniden yükleyen. Bu kurulum işe yarar, ancak yine de Caddy'den daha fazla hareketli parça bırakır: web sunucusu, ACME istemcisi, yenileme zamanlayıcısı ve herhangi bir dağıtım hook'u ayrı bileşenler olarak kalır.
Caddy'nin operasyonel avantajı, sertifika verme, dağıtma, yenileme ve HTTP'den HTTPS'ye yönlendirmelerin sunucunun kendisine entegre edilmiş olmasıdır. Varsayılan olarak, Caddy yaklaşık olarak şu durumda yenileme denemeye başlar: bir sertifikanın ömrünün üçte biri kaldığında, 90 günlük bir sertifika için 30 gün, sertifika otoritesi farklı bir yenileme penceresi belirtmedikçe.
Profesyonel İpucu: Caddy'nin varsayılan ACME challenge'ları port 80 veya 443'te herkese açık erişilebilirlik gerektirir: HTTP-01 port 80'i kullanırken TLS-ALPN-01 port 443'ü kullanır. Port 80 engellenmiş ancak 443 açıksa, TLS-ALPN yine de çalışabilir; makine internete dönük değilse, aşağıdaki wildcard sertifikalarla aynı şekilde DNS-01 kullanın.
Yapılandırma Dosyaları, Yan Yana
İşte her iki araç için yazılmış üç yaygın VPS kurulumu: bir HTTPS ters proxy, statik dosya sunumu ve basic authentication. Caddy örnekleri otomatik HTTPS içerir. Nginx örnekleri bir sertifikanın zaten sağlandığını varsayar ve statik dosya ile basic-auth örnekleri yalnızca HTTPS sunucu bloğunu gösterir. Eşdeğer HTTP'den HTTPS'ye davranış istiyorsanız ilk örnekteki port 80 yönlendirme bloğunu yeniden kullanın.
Port 3000'deki yerel bir uygulamaya ters proxy:
Caddyfile
example.com {
reverse_proxy localhost:3000
}
nginx.conf
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
proxy_pass http://localhost:3000;
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;
}
}
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
Nginx bloğundaki TLS satırları Certbot'un zaten çalıştığını varsayar. Yukarıdaki gibi bir HTTP upstream için Caddy, gelen Host başlığını geçirir ve şunu ayarlar: X-Forwarded-For, X-Forwarded-Proto, ve X-Forwarded-Host varsayılan olarak. Nginx ile, upstream orijinal host, scheme ve istemci adresi zincirine ihtiyaç duyduğunda proxy başlıklarını normalde açıkça eklersiniz. Bu, ödünleşimin küçük ölçekli hâlidir: Caddy pratik proxy varsayılanları sunarken, Nginx o davranışın daha fazlasını açık hâle getirir.
Statik dosya sunumu:
Caddyfile
example.com {
root * /var/www
file_server
}
nginx.conf
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
Basic auth, her şeyi bir kullanıcı adı ve parola arkasında koruyarak:
Caddyfile
example.com {
basic_auth {
Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
}
reverse_proxy localhost:3000
}
nginx.conf
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
location / {
proxy_pass http://localhost:3000;
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;
}
}
Her iki araç da parolayı bant dışında hash'ler. Caddy şunu kullanır: caddy hash-password; Nginx şunu kullanır: htpasswd .htpasswd dosyasını oluşturmak için. Direktif, basic_auth güncel Caddy'de bu arada. Şuydu: basicauth v2.8.0 onu yeniden adlandırana kadar, şurada belirtildiği gibi: Caddy basic_auth dokümantasyonu, ve eski öğreticiler bu konuda insanları hâlâ yanıltıyor.
Profesyonel İpucu: Caddyfile'daki o hash parola değildir. Şu komuttan gelen bcrypt çıktısıdır:
caddy hash-password. Komutu çalıştırın, yazdırdığı şeyi yapıştırın. Caddy, yapılandırmada düz metin parolaları reddeder; bu doğru varsayılandır ve ilk seferinde küçük bir sürprizdir.
Yapılandırmalar kendi savunmasını yapar. Caddy, TLS'yi, makul proxy başlıklarını ve bir yönlendirmeyi birkaç satıra katlar; Nginx açık ve ayrıntılıdır ve size her düğmeyi verir. Nginx'te yıllar geçirdiyseniz, ayrıntı düzeyi kas hafızasıdır ve kontrol asıl amaçtır. Geçirmediyseniz, Caddyfile kafanızda tutabileceğiniz bir yapılandırmadır. Pratik nokta basittir: Caddy'nin yapılandırması bir bakışta okumak daha kolaydır, Nginx ise size daha açık kontrol verir.
Performans ve Bellek: Kıyaslamaları Dikkatlice Okumak
Yayımlanan testler aynı genel yönü işaret eder: Nginx genellikle daha az bellek kullanır ve çoğu zaman ham verimlilikte önde gelir, ancak bu avantajın büyüklüğü büyük ölçüde ortama bağlıdır.
In bir üçüncü taraf dört çekirdekli VM testi, Nginx saniyede yaklaşık 48.000 isteğe ulaştı, Caddy'nin yaklaşık 42.000'ine kıyasla. Aynı test, Nginx için 2,1 ms ve Caddy için 2,4 ms HTTPS p99 gecikmesi bildirdi. Bunları evrensel bir performans farkı yerine tek bir kurulumdan gelen sonuçlar olarak değerlendirin.
Karşılaştırma tablosundaki bellek aralıkları şuradan gelir: ayrı bir VPS testi. Başka bir 50.000 eşzamanlı bağlantıda sentetik test Nginx için 145 MB ve Caddy için 520 MB bildirdi, ancak o test önemli ölçüde farklı donanım ve iş yükü koşulları kullandı. Mutlak rakamları yukarıdaki VPS rakamlarıyla doğrudan karşılaştırılmamalıdır.
Güvenilir sonuç daha dardır: Nginx genellikle daha küçük bellek ayak izine sahiptir ve yüksek verimlilik veya yüksek eşzamanlılık iş yükleri altında önde gelme eğilimindedir. Sıradan küçükten orta ölçeğe bir VPS ters proxy'si için, ikisi de genellikle yeterince hızlıdır, bu yüzden operasyonel basitlik çoğu zaman daha kullanışlı belirleyici faktördür.
Bölümün özeti: sunucunuz bellek kısıtlı değilse veya kendi yük testleriniz proxy verimliliğinin darboğaz olduğunu göstermediği sürece operasyonlara göre seçin.
Wildcard Sertifika Püf Noktası (Caddy Her Zaman Sıfır Yapılandırma Değildir)
Caddy wildcard sertifikaları otomatikleştirebilir, ancak varsayılan HTTP-01 veya TLS-ALPN-01 challenge'larıyla değil. Şunun için bir sertifika: *.example.com DNS-01 doğrulaması gerektirir, Let's Encrypt'in wildcard sertifikalar için zorunlu kıldığı. Bu, tls bloğunda yapılandırılmış, bir DNS sağlayıcı eklentisi (xcaddy aracılığıyla Caddy binary'nize gömülü) artı DNS host'unuz için bir API token anlamına gelir. Bu, Caddy'nin pazarladığı tek satır yaz ve uzaklaş hikayesi değildir.
Bu, sahip oldukları gerçek bir alan adı altına birçok hizmet koyan homelab kullanıcılarını zorlar, örneğin *.home.example.com, ve wildcard sertifika vermenin şu kadar otomatik olduğunu varsayanları: app.example.com. Yalnızca dahili adlar için, örneğin *.homelab.internal, bunu herkese açık bir Let's Encrypt wildcard'ı olarak değil, yerel/dahili PKI bölgesi olarak değerlendirin. Kesin olmak gerekirse: Caddy wildcard'ları gayet iyi yapar, sadece bunları varsayılan challenge'larla yapmaz ve kurulum, tek alan adı durumundan bir adım üsttedir. Nginx burada aynı durumdadır, çünkü DNS-01 gereksinimi sunucudan değil Let's Encrypt'ten gelir.
Bir GUI İstiyorsanız: Nginx Proxy Manager (Kısa Bir Ayrıntı)
Nginx Proxy Manager, yukarıdaki iki araçtan farklı bir şeydir ve adı insanların kafasını karıştırdığı için bir paragrafı hak eder. NPM, Nginx üzerinde bir GUI sarmalayıcısıdır: ters proxy kurallarını ve Let's Encrypt sertifikalarını port 81'deki bir web arayüzü aracılığıyla yönetir. Nginx çekirdeği değildir ve Nginx çekirdeğinin yapılandırıldığı şekilde yapılandırılmaz.
Ödünleşim, alışılmış tıkla-veya-yapılandır ödünleşimidir. NPM, mutlu yoldan ayrılana kadar kolay düğmedir. Yapılandırması, tek bir elle düzenlenen yapılandırma dosyası yerine bir uygulama veritabanı aracılığıyla yönetilir. varsayılan Docker kurulumu şunu kullanır: SQLite, MySQL/MariaDB ve PostgreSQL ise desteklenen harici veritabanı seçenekleridir. Bu fark taşınabilirliği de etkiler: bir Caddy kurulumu genellikle şunu kopyalayarak taşınabilir: tek bir Caddyfile, oysa bir Nginx Proxy Manager kurulumu şunun korunmasını gerektirir: uygulama verileri ve veritabanı . NPM, tıklamayı düzenlemeye gerçekten tercih ediyorsanız ve kurulumunuz basit kalıyorsa iyi bir seçimdir. Kod-olarak-altyapı iş akışı için yanlış seçimdir.
Nginx'ten Caddy'ye Geçiş (Neyin Karşılığı Var, Neyin Yok)
Zaten Nginx kullanıyorsanız ve geçişi değerlendiriyorsanız, otomasyon konusundaki beklentilerinizi düşürerek başlayın: bir Caddy NGINX yapılandırma adaptörü vardır, ancak eksiktir ve güvenilir bir tek seferlik geçiş yolu olarak değerlendirilmemelidir. Nginx'ten Caddy'ye geçiş çoğunlukla elle yeniden yazmadır ve çoğu kısalır.
Neyin karşılığı olduğu ve basitleştiği, şuna göre: Caddy topluluğunun dönüştürme rehberi:
- HTTP upstream'ler için,
reverse_proxygelen şunu geçirir:Hostbaşlığını geçirir ve standart X-Forwarded-* başlıklarını varsayılan olarak ayarlar, bu yüzden oproxy_set_headersatırların çoğu ortadan kalkar. - PHP, şunu içeren bir location bloğundan
try_filesartıfastcgi_passartı bir yığın parametreden tek bir şeye çöker:php_fastcgidirektif. - WebSocket işleme Caddy v2'de otomatiktir. Bir öğretici size ayrı bir şey eklemenizi söylüyorsa:
websocketdirektif, bu bir Caddy v1 kalıntısıdır. Görmezden gelin.
Otomatik olarak karşılığı olmayanlar: Caddy'nin sahip olmadığı belirli bir Nginx modülüne bağlı her şey, taşımak yerine yeniden düşünmeniz gereken karmaşık rewrite ve location mantığı ve sizi yukarıdaki bölümdeki DNS challenge kurulumuna geri götüren wildcard sertifika kurulumları. Modüller ve rewrite'lar için bütçe ayırın; geri kalanı genellikle satır sayısında net bir azalmadır.
Hangisini Kurmalısınız? (Karar)
Yapılandırmaları, rakamları, wildcard püf noktasını ve geçiş maliyetini gördünüz, işte sonuç burada. Bağımsız bir geliştirici veya küçük bir ekipseniz, bu yeni bir VPS kurulumuysa, kur-unut TLS istiyorsanız, basit yönlendirmeyle Docker çalıştırıyorsanız veya sadece kas hafızasına sığan bir yapılandırma istiyorsanız Caddy'yi kurun. Bu, bunu okuyan çoğu kişidir.
İnce ayarlı kontrole veya olgun ekosisteminden belirli bir modüle ihtiyacınız varsa, bellek kısıtlı bir sunucudan performans sıkıştırıyorsanız, yüksek eşzamanlılıkta statik dosya sunumu yapıyorsanız veya ekibiniz zaten derin Nginx uzmanlığına ve bir yığın çalışan yapılandırmaya sahipse Nginx'i kurun. Bunlar sağlam nedenlerdir ve bunlardan biri sizinse, Nginx doğru karardır. Bu, eski aracın yanlış araç olduğu bir durum değildir.
Hangisine karar verirseniz verin, bir sonraki adım onu makineye koymaktır. Her ikisi de Caddy ve Nginx marketplace'imizde tek tıkla kurulum olarak mevcuttur, böylece kurulum işini atlayabilir ve doğrudan Caddyfile'a veya sunucu bloğuna geçebilirsiniz. 1 GB'lık bir VPS, düşük trafikli tek siteli bir kurulum için makul bir başlangıç noktasıdır, ancak sunucuyu yalnızca proxy için değil, proxy'nin arkasındaki uygulama ve trafik için boyutlandırın. Caddy'yi kendi kendine barındırılan hizmetler için ön kapı olarak kullanıyorsanız, şunun önünde yer alabilir: Prometheus ve Grafana izleme yığını veya bir Uptime Kuma kurulumu ayrı TLS araçları gerektirmeden.
Bölümün özeti: Nginx'e işaret eden belirli bir nedeniniz olmadıkça Caddy'yi seçin.
Sıkça Sorulan Sorular
Caddy, Certbot'un Yerine Geçer mi?
Evet. Caddy, wildcard sertifikalar dahil olmak üzere herkese açık sertifikaları kendisi alıp yenileyebilir, bu yüzden Certbot gerekli değildir. Wildcard'lar DNS-01 doğrulaması gerektirir, bu da uyumlu bir DNS sağlayıcı modülü ve API kimlik bilgilerinin yapılandırılması anlamına gelir.
Caddy, Nginx'ten Daha Az Bellek mi Kullanır?
Hayır. Nginx genellikle daha küçük bir bellek ayak izine sahiptir. Bir üçüncü taraf VPS testi Nginx için boştayken 2-8 MB ve Caddy için 15-25 MB bildirdi, ancak bu rakamlar sabit bellek gereksinimleri yerine iş yüküne özgüdür. Fark en çok, birkaç hizmet çalıştıran bellek kısıtlı sunucularda önemlidir.
Caddy, Nginx'ten Daha mı Hızlı?
İş yüküne bağlıdır. İkisi de normalde tipik VPS ters proxy trafiği için yeterince hızlıdır. atıfta bulunulan testlerde, Nginx ham verimlilik ve bellek verimliliğinde önde geldi, ancak farkın büyüklüğü şuna göre önemli ölçüde değişti: donanım, trafik deseni ve eşzamanlılık düzeyi. Her kuruluma uygulanan tek bir yüzde yoktur.
Caddy, Wildcard SSL Sertifikalarını Destekler mi?
Evet. Şunun gibi bir wildcard: *.example.com DNS-01 doğrulaması gerektirir. Caddy uyumlu bir DNS sağlayıcı modülüne ve API kimlik bilgilerine sahip olduğunda, wildcard sertifikayı otomatik olarak alıp yenileyebilir.
Nginx Proxy Manager, Nginx ile Aynı mı?
Hayır. Nginx Proxy Manager, yapılandırmasını bir uygulama veritabanında saklayan, port 81'de bir web UI kullanan ve ters proxy host'larını ve sertifikaları o arayüz aracılığıyla yöneten, Nginx üzerinde bir GUI sarmalayıcısıdır. Nginx çekirdeği metin dosyalarıyla yapılandırılır ve kendine ait bir GUI'si yoktur.
Caddy Yerine Ne Zaman Nginx Kullanmalıyım?
İnce ayarlı kontrole, olgun ekosisteminden belirli bir modüle, bellek kısıtlı bir sunucuda son MB'ye kadar tasarrufa, yüksek eşzamanlılıkta statik dosya sunumuna ihtiyaç duyduğunuzda veya ekipte zaten derin Nginx uzmanlığınız olduğunda Nginx'i seçin.