Caddy vs Nginx di VPS: Perbandingan File Konfigurasi

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;
}

Baris TLS di blok Nginx mengasumsikan Certbot sudah dijalankan. Untuk upstream HTTP seperti di atas, Caddy meneruskan header Host yang masuk dan menetapkan X-Forwarded-For, X-Forwarded-Proto, dan X-Forwarded-Host secara default. Dengan Nginx, Anda biasanya menambahkan header proxy secara eksplisit ketika upstream membutuhkan host asli, skema, dan rantai alamat klien. Itulah trade-off dalam skala kecil: Caddy hadir dengan default proxy yang praktis, sementara Nginx membuat lebih banyak dari perilaku itu menjadi eksplisit.

Penyajian file statis:

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, melindungi semuanya di balik username dan password:

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;
    }
}

Kedua alat meng-hash password secara terpisah. Caddy menggunakan caddy hash-password; Nginx menggunakan htpasswd untuk membangun file .htpasswd. Direktifnya adalah basic_auth di Caddy saat ini, omong-omong. Sebelumnya basicauth sampai v2.8.0 menamainya ulang, sebagaimana dicatat dalam dokumentasi basic_auth Caddy, dan tutorial lama masih membuat orang tersandung karenanya.

Tips Pro: Hash di Caddyfile itu bukan password. Itu adalah output bcrypt dari caddy hash-password. Jalankan perintahnya, tempel apa yang dicetaknya. Caddy menolak password plaintext dalam konfigurasi, yang merupakan default yang benar dan sedikit kejutan pada awalnya.

Konfigurasinya berbicara sendiri. Caddy melipat TLS, header proxy yang masuk akal, dan pengalihan ke dalam beberapa baris; Nginx eksplisit dan bertele-tele serta memberi Anda setiap kenop. Jika Anda telah menghabiskan bertahun-tahun di Nginx, verbositasnya adalah refleks dan kontrol itulah intinya. Jika belum, Caddyfile adalah konfigurasi yang bisa Anda simpan di kepala. Poin praktisnya sederhana: konfigurasi Caddy lebih mudah dibaca sekilas, sementara Nginx memberi Anda kontrol yang lebih eksplisit.

Performa dan Memori: Membaca Benchmark dengan Cermat

Pengujian yang dipublikasikan menunjuk ke arah umum yang sama: Nginx biasanya menggunakan lebih sedikit memori dan sering unggul pada throughput mentah, tetapi besarnya keunggulan itu sangat bergantung pada lingkungan.

In satu pengujian VM empat-core dari pihak ketiga, Nginx mencapai sekitar 48.000 request per detik, dibandingkan dengan sekitar 42.000 untuk Caddy. Pengujian yang sama melaporkan latensi HTTPS p99 sebesar 2,1 ms untuk Nginx dan 2,4 ms untuk Caddy. Perlakukan itu sebagai hasil dari satu penyiapan, bukan margin performa universal.

Rentang memori dalam tabel perbandingan berasal dari pengujian VPS terpisah. Pengujian sintetis lain pada 50.000 koneksi bersamaan melaporkan 145 MB untuk Nginx dan 520 MB untuk Caddy, tetapi pengujian itu menggunakan kondisi perangkat keras dan beban kerja yang sangat berbeda. Angka absolutnya tidak boleh dibandingkan langsung dengan angka VPS di atas.

Kesimpulan yang dapat diandalkan lebih sempit: Nginx umumnya memiliki jejak memori yang lebih kecil dan cenderung unggul pada beban kerja throughput tinggi atau konkurensi tinggi. Untuk reverse proxy VPS kecil-hingga-menengah biasa, keduanya umumnya cukup cepat, sehingga kesederhanaan operasional sering kali menjadi faktor penentu yang lebih berguna.

Inti bagian ini: pilih berdasarkan operasional kecuali server Anda terbatas memori atau uji beban Anda sendiri menunjukkan bahwa throughput proxy adalah hambatannya.

Catatan Penting Sertifikat Wildcard (Caddy Tidak Selalu Zero-Config)

Caddy dapat mengotomatiskan sertifikat wildcard, tetapi tidak dengan challenge HTTP-01 atau TLS-ALPN-01 default-nya. Sertifikat untuk *.example.com memerlukan validasi DNS-01, yang diwajibkan Let's Encrypt untuk sertifikat wildcard. Itu berarti plugin penyedia DNS (dibangun ke dalam biner Caddy Anda melalui xcaddy) plus token API untuk host DNS Anda, dikonfigurasi dalam blok tls. Ini bukan cerita ketik-satu-baris-lalu-tinggalkan yang dipasarkan Caddy.

Ini menggigit pengguna homelab yang menempatkan banyak layanan di bawah domain nyata yang mereka kendalikan, seperti *.home.example.com, dan mengasumsikan penerbitan wildcard seotomatis app.example.com. Untuk nama yang murni internal seperti *.homelab.internal, perlakukan itu sebagai wilayah PKI lokal/internal, bukan wildcard Let's Encrypt publik. Supaya tepat: Caddy menangani wildcard dengan baik, ia hanya tidak melakukannya dengan challenge default, dan penyiapannya satu tingkat lebih rumit daripada kasus domain tunggal. Nginx berada dalam situasi yang sama di sini, karena persyaratan DNS-01 berasal dari Let's Encrypt, bukan dari server.

Jika Anda Menginginkan GUI: Nginx Proxy Manager (Sebuah Selingan Singkat)

Nginx Proxy Manager adalah hal yang sama sekali berbeda dari dua alat di atas, dan layak diberi satu paragraf karena namanya membingungkan orang. NPM adalah pembungkus GUI di atas Nginx: ia mengelola aturan reverse-proxy dan sertifikat Let's Encrypt melalui antarmuka web di port 81. Ini bukan Nginx inti, dan tidak dikonfigurasi dengan cara Nginx inti dikonfigurasi.

Trade-off-nya adalah yang biasa antara klik-versus-konfigurasi. NPM adalah tombol mudah sampai Anda keluar dari jalur yang mulus. Konfigurasinya dikelola melalui database aplikasi alih-alih satu file konfigurasi yang diedit manual. Penyiapan Docker default menggunakan SQLite, sementara MySQL/MariaDB dan PostgreSQL adalah opsi database eksternal yang didukung. Perbedaan itu juga memengaruhi portabilitas: penyiapan Caddy sering kali dapat dipindahkan dengan menyalin satu Caddyfile tunggal, sementara deployment Nginx Proxy Manager memerlukan data aplikasi dan database-nya untuk dipertahankan. NPM adalah pilihan yang baik jika Anda benar-benar lebih suka mengklik daripada mengedit dan penyiapan Anda tetap sederhana. Ini adalah pilihan yang salah untuk alur kerja infrastructure-as-code.

Migrasi dari Nginx ke Caddy (Apa yang Terkonversi dan Apa yang Tidak)

Jika Anda sudah menggunakan Nginx dan mempertimbangkan perpindahan, mulailah dengan menurunkan ekspektasi Anda soal otomatisasi: ada adapter konfigurasi NGINX untuk Caddy, tetapi tidak lengkap dan tidak boleh diperlakukan sebagai jalur migrasi sekali-jalan yang andal. Migrasi dari Nginx ke Caddy sebagian besar adalah penulisan ulang manual, dan sebagian besarnya menjadi lebih ringkas.

Apa yang terkonversi dan menjadi lebih sederhana, menurut panduan konversi komunitas Caddy:

• Untuk upstream HTTP, reverse_proxy meneruskan header Host yang masuk dan menetapkan header X-Forwarded-* standar secara default, sehingga sebagian besar baris proxy_set_header tersebut menghilang.
• PHP menyusut dari blok location dengan try_files tambah fastcgi_pass plus tumpukan parameter menjadi satu direktif php_fastcgi tunggal.
• Penanganan WebSocket otomatis di Caddy v2. Jika sebuah tutorial menyuruh Anda menambahkan direktif websocket terpisah, itu adalah peninggalan Caddy v1. Abaikan saja.

Apa yang tidak terkonversi secara otomatis: apa pun yang terikat pada modul Nginx spesifik yang tidak dimiliki Caddy, logika rewrite dan location kompleks yang perlu Anda pikirkan ulang alih-alih dipindahkan, dan penyiapan sertifikat wildcard, yang membawa Anda kembali ke penyiapan DNS-challenge dari bagian di atas. Sisihkan waktu untuk modul dan rewrite; sisanya biasanya merupakan pengurangan baris secara keseluruhan.

Mana yang Harus Anda Pasang? (Keputusannya)

Anda telah melihat konfigurasinya, angka-angkanya, catatan penting soal wildcard, dan biaya migrasi, jadi inilah kesimpulannya. Pasang Caddy jika Anda developer perorangan atau tim kecil, ini adalah deployment VPS baru, Anda menginginkan TLS yang set-and-forget, Anda menjalankan Docker dengan routing sederhana, atau Anda hanya ingin konfigurasi yang bisa diingat secara refleks. Itulah sebagian besar orang yang membaca ini.

Pasang Nginx jika Anda membutuhkan kontrol terperinci atau modul spesifik dari ekosistemnya yang matang, Anda memeras performa dari server yang terbatas memori, Anda melakukan penyajian file statis dengan konkurensi tinggi, atau tim Anda sudah memiliki keahlian Nginx yang mendalam dan tumpukan konfigurasi yang berfungsi. Itu adalah alasan yang kuat, dan jika salah satunya milik Anda, Nginx adalah pilihan yang tepat. Ini bukan kasus di mana alat yang lebih lama adalah alat yang salah.

Apa pun pilihan Anda, langkah berikutnya adalah memasangnya di box. Keduanya Caddy dan Nginx tersedia sebagai deployment sekali klik di marketplace kami, jadi Anda dapat melewati pekerjaan instalasi dan langsung ke Caddyfile atau blok server. VPS 1 GB adalah titik awal yang masuk akal untuk deployment situs tunggal dengan traffic rendah, tetapi sesuaikan ukuran server dengan aplikasi dan traffic di balik proxy alih-alih hanya proxy itu sendiri. Jika Anda menggunakan Caddy sebagai pintu depan untuk layanan self-hosted, ia bisa berada di depan stack pemantauan Prometheus dan Grafana atau deployment Uptime Kuma tanpa memerlukan perkakas TLS terpisah.

Inti bagian ini: pilih Caddy kecuali Anda memiliki alasan spesifik yang mengarah ke Nginx.

Pertanyaan yang Sering Diajukan