Site Address #
Site address adalah bagian pertama dari setiap blok site di Caddyfile — ia mendefinisikan untuk request mana konfigurasi tersebut berlaku. Site address yang ditulis dengan benar menentukan apakah Caddy akan mengaktifkan HTTPS otomatis, di port mana ia akan listen, dan bagaimana request dicocokkan dengan blok site yang tepat.
Memahami semua format site address yang valid dan implikasinya adalah fondasi yang penting, karena kesalahan di sini bisa menyebabkan Caddy gagal mendapatkan sertifikat, atau request tidak diarahkan ke handler yang tepat.
Format Dasar #
Site address bisa ditulis dalam beberapa format, dan setiap format memiliki implikasi yang berbeda terhadap perilaku Caddy:
# Format 1: Nama domain saja
# Caddy OTOMATIS mengaktifkan HTTPS
# Listen di :80 (redirect) dan :443 (HTTPS)
example.com {
file_server
}
# Format 2: Domain dengan port eksplisit
# Port 443 → Caddy mengaktifkan HTTPS
example.com:443 {
file_server
}
# Format 3: Domain dengan port non-standar
# Caddy mengaktifkan HTTPS di port 8443
example.com:8443 {
file_server
}
# Format 4: Domain dengan port 80 eksplisit
# Caddy TIDAK mengaktifkan HTTPS (HTTP only, port 80)
example.com:80 {
file_server
}
# Format 5: IP address
# Tidak ada HTTPS otomatis (tidak ada domain)
192.168.1.100 {
file_server
}
# Format 6: IP dengan port
192.168.1.100:8080 {
file_server
}
# Format 7: Hanya port (listen di semua interface)
# Cocok untuk semua request yang masuk ke port ini
:80 {
respond "HTTP server"
}
:443 {
# Perlu konfigurasi TLS manual karena tidak ada domain
tls internal
respond "HTTPS server (self-signed)"
}
# Format 8: localhost
# Caddy otomatis menggunakan internal CA untuk HTTPS
# Tidak perlu koneksi internet, tidak butuh ACME
localhost {
file_server
}
Aturan HTTPS Otomatis Berdasarkan Site Address #
Ini adalah salah satu hal yang paling penting dipahami:
Site Address HTTPS Otomatis? Keterangan
──────────────────────────────────────────────────────────────────
example.com YA Domain tanpa port = HTTPS
example.com:443 YA Port 443 = HTTPS
example.com:8443 YA Port custom = HTTPS juga
example.com:80 TIDAK Port 80 = HTTP only
192.168.1.100 TIDAK IP tanpa domain = no HTTPS
192.168.1.100:443 TIDAK* IP + port 443, tapi tidak ada domain
:443 TIDAK Hanya port, tidak ada domain
localhost YA (internal CA) Special case — Caddy buat CA sendiri
Catatan untuk *: Caddy akan mencoba HTTPS dengan sertifikat yang ada di storage atau self-signed jika tidak ada, tapi tidak ada ACME request karena tidak ada domain.
Wildcard Domain #
Caddy mendukung wildcard domain (*.example.com) untuk mencocokkan semua subdomain:
# Wildcard — cocok dengan SEMUA subdomain satu level
# blog.example.com, app.example.com, api.example.com, dll
*.example.com {
# Untuk HTTPS wildcard, WAJIB menggunakan DNS-01 challenge
# karena Let's Encrypt tidak bisa verifikasi wildcard via HTTP-01
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
reverse_proxy localhost:3000
}
# Wildcard TIDAK cocok dengan domain apex (example.com itu sendiri)
# Kamu perlu blok terpisah untuk itu
example.com {
reverse_proxy localhost:3000
}
Wildcard untuk Multi-Tenant #
Pattern yang umum untuk platform multi-tenant:
{
on_demand_tls {
ask http://localhost:3000/check-domain
interval 2m
burst 5
}
}
# Terima semua domain, dapatkan sertifikat on-demand saat pertama kali diakses
:443 {
tls {
on_demand
}
reverse_proxy localhost:3000
}
Multiple Site Address dalam Satu Blok #
Satu blok bisa berlaku untuk beberapa alamat:
# Cara 1: Dipisah koma di satu baris
example.com, www.example.com {
redir https://example.com{uri} permanent
}
# Cara 2: Setiap address di baris terpisah (lebih mudah dibaca)
example.com
www.example.com
api.example.com {
reverse_proxy localhost:3000
}
# Cara 3: Campuran domain dan port
example.com:80, example.com:443 {
# Blok ini berlaku untuk HTTP dan HTTPS
}
Path Prefix sebagai Bagian dari Address #
Site address bisa menyertakan path prefix untuk membuat routing berbasis path tingkat teratas:
# Hanya cocok dengan request ke /api/*
example.com/api/* {
reverse_proxy localhost:8080
}
# Semua request lain ke example.com ditangani di sini
example.com {
root * /var/www/html
file_server
}
Path prefix di site address adalah untuk routing tingkat teratas yang membagi traffic ke blok site berbeda. Untuk routing yang lebih granular di dalam satu blok site (misalnya/adminke backend A,/apike backend B), gunakan matcher yang dibahas di artikel tersendiri. Path prefix di site address lebih jarang digunakan karena matcher lebih fleksibel.
Binding ke Interface Jaringan Tertentu #
Secara default, Caddy listen di semua interface jaringan (0.0.0.0). Untuk membatasi ke interface tertentu, sertakan IP di site address:
# Listen hanya di interface dengan IP 192.168.1.100
192.168.1.100:80 {
respond "Hanya bisa diakses dari jaringan internal"
}
# Listen hanya di localhost
127.0.0.1:8080 {
# Admin interface yang hanya bisa diakses dari localhost
reverse_proxy localhost:9000
}
# Listen di semua interface (default, tidak perlu ditulis)
# Sama dengan tidak menyertakan IP
:80 {
respond "Bisa diakses dari mana saja"
}
Ini berguna untuk memisahkan traffic publik dan internal di server yang memiliki beberapa interface jaringan.
Protokol Eksplisit #
Site address bisa menyertakan protokol secara eksplisit, meski ini jarang diperlukan:
# HTTP eksplisit — tidak ada HTTPS, tidak ada redirect
http://example.com {
respond "HTTP only server"
}
# HTTPS eksplisit — sama dengan example.com (dengan port 443 default)
https://example.com {
file_server
}
# HTTPS di port non-standar
https://example.com:8443 {
file_server
}
Penggunaan http:// eksplisit berguna ketika kamu ingin memastikan tidak ada HTTPS apapun untuk domain tersebut — misalnya untuk endpoint internal yang diakses via reverse proxy lain yang sudah menangani TLS.
Site Address dengan Variabel Environment #
# Gunakan env variable untuk site address
# Berguna untuk Caddyfile yang sama dipakai di berbagai environment
{env.PRIMARY_DOMAIN} {
reverse_proxy {env.BACKEND_URL}
}
# Dengan port dari environment
{env.APP_DOMAIN}:{env.APP_PORT} {
reverse_proxy localhost:3000
}
# Set environment variables sebelum menjalankan Caddy
export PRIMARY_DOMAIN=example.com
export BACKEND_URL=localhost:3000
caddy run --config /etc/caddy/Caddyfile
Prioritas saat Multiple Blok Cocok #
Ketika ada beberapa blok site dan sebuah request bisa cocok dengan lebih dari satu, Caddy menggunakan aturan prioritas berikut:
Urutan prioritas (dari tertinggi ke terendah):
1. Blok dengan site address yang paling spesifik
2. Blok yang menyertakan path prefix (lebih panjang = lebih prioritas)
3. Blok wildcard yang lebih spesifik
Contoh:
Request ke: api.example.com/v1/users
Kandidat blok:
a. api.example.com/v1/users → Paling spesifik, prioritas tertinggi
b. api.example.com/v1/ → Lebih spesifik dari wildcard
c. api.example.com → Exact domain match
d. *.example.com → Wildcard subdomain
e. example.com → Hanya domain apex, tidak cocok
Dalam praktiknya, konflik ini jarang terjadi karena setiap domain biasanya hanya memiliki satu blok site.
Pola Umum Site Address #
Redirect HTTP ke HTTPS #
# Pola 1: Caddy otomatis menambahkan redirect HTTP → HTTPS
# Ketika kamu tulis domain tanpa http://, Caddy otomatis handle redirect
example.com {
# Redirect HTTP ke HTTPS sudah otomatis
# Tidak perlu konfigurasi tambahan
file_server
}
# Pola 2: Redirect manual ke domain canonical
http://example.com, http://www.example.com {
redir https://example.com{uri} permanent
}
Development dengan Berbagai Local Domain #
# Semua domain .localhost otomatis menggunakan internal CA
app.localhost {
reverse_proxy localhost:3000
}
api.localhost {
reverse_proxy localhost:8080
}
# localhost tanpa subdomain
localhost {
file_server browse
}
Server dengan Multiple Network Interface #
# Traffic publik — dari interface publik
203.0.113.1:443 {
# Site address dengan IP publik
reverse_proxy localhost:3000
}
# Traffic internal — dari interface private
10.0.0.1:443 {
# Site address dengan IP private
# Bisa berbeda konfigurasi dari yang publik
reverse_proxy localhost:9000
}
# Admin yang hanya bisa diakses lokal
127.0.0.1:8443 {
tls internal
reverse_proxy localhost:9999
}
Troubleshooting Site Address #
Caddy Tidak Mendapatkan Sertifikat #
# Gejala: HTTPS tidak bekerja untuk domain tertentu
# Diagnosa 1: Cek apakah domain bisa di-resolve
dig +short example.com # Harus return IP server kamu
# Diagnosa 2: Cek log ACME
sudo journalctl -u caddy | grep -i "acme\|certificate\|tls"
# Diagnosa 3: Cek apakah site address ditulis dengan benar
# http://example.com atau example.com:80 = TIDAK akan dapat HTTPS
# Harus: example.com atau example.com:443
Request Tidak Masuk ke Blok yang Diharapkan #
# Gunakan caddy adapt untuk melihat routing yang sebenarnya
caddy adapt --config /etc/caddy/Caddyfile | jq .apps.http.servers
# Cek apakah ada blok yang saling tumpang tindih
# atau site address yang tidak sesuai ekspektasi
Port Sudah Digunakan #
# Error: "listen tcp :443: bind: address already in use"
# Temukan proses yang menggunakan port tersebut
sudo ss -tlnp | grep ':443'
sudo lsof -i :443
Ringkasan #
- Domain tanpa port (
example.com) otomatis mengaktifkan HTTPS via ACME — ini adalah format yang paling umum dan direkomendasikan.- Port 80 eksplisit (
example.com:80) menonaktifkan HTTPS otomatis — hanya HTTP.- Wildcard domain (
*.example.com) membutuhkan DNS-01 challenge — tidak bisa menggunakan HTTP-01 karena keterbatasan protokol ACME.localhostadalah special case — Caddy menggunakan internal CA, tidak perlu internet atau domain publik.- IP address sebagai site address tidak mendapatkan HTTPS otomatis — perlu konfigurasi TLS manual jika dibutuhkan.
- Gunakan variabel environment (
{env.DOMAIN}) untuk site address yang berbeda per environment.caddy adaptadalah tool terbaik untuk debug routing — lihat JSON yang dihasilkan untuk memahami apa yang sebenarnya dikonfigurasi.