Belajar Caddy - Reverse Proxy Basics

#Pendahuluan

Reverse proxy adalah salah satu alasan utama orang memakai Caddy di production. Daripada aplikasi (Node.js, Django, Flask, atau container) terpapar langsung ke internet dengan port acak, Caddy berdiri di depan, menangani TLS dan domain, lalu meneruskan request ke aplikasi di belakangnya.

Episode 6 memperkenalkan directive reverse_proxy dari dasar: sintaks, backend URL, header manipulation, pola-pola umum, hingga transport options. Ini fondasi yang akan kita perluas ke load balancing (episode 14), sticky sessions (episode 15), dan failover (episode 16).

Setelah episode ini, kalian bisa mengekspos aplikasi apa pun ke internet dengan aman dan cepat hanya dalam beberapa baris Caddyfile.

#Directive reverse_proxy

#Sintaks Dasar

Bentuk paling sederhana meneruskan semua request ke satu backend:

app.example.com {
    reverse_proxy localhost:8080
}

Sekarang semua request ke app.example.com diteruskan ke aplikasi di localhost:8080. Backend URL bisa berupa localhost:port, 127.0.0.1:port, nama host, atau bahkan http://backend:3000.

#Multiple Backend dan Load Balancing

Satu directive bisa menerima beberapa backend — Caddy otomatis mendistribusikan request:

app.example.com {
    reverse_proxy localhost:8080 localhost:8081 localhost:8082
}

Default-nya memakai policy round_robin. Detail semua policy load balancing akan kita bedah di episode 14.

#Header Manipulation

#Header ke Upstream (header_up)

Kadang aplikasi butuh informasi tentang klien asli — bukan IP Caddy. Caddy menambahkan header X-Forwarded-* secara default, tapi kalian bisa mengatur header yang dikirim ke upstream:

app.example.com {
    reverse_proxy localhost:8080 {
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up Host {host}
    }
}

header_up X-Real-IP {remote_host} memberi tahu aplikasi alamat IP asli klien. Nama header_up mengikuti arah: header yang dikirim ke upstream (backend).

#Header ke Downstream (header_down)

Header respons dari backend bisa diubah sebelum dikembalikan ke klien:

app.example.com {
    reverse_proxy localhost:8080 {
        header_down -Server
        header_down X-App-Version v2.4
    }
}

header_down -Server menghapus header Server yang bocor dari aplikasi; header_down X-App-Version v2.4 menambahkan header kustom. Ini berguna untuk menghapus informasi backend yang sensitif — kita akan lanjutkan di episode 20.

#Pola Umum Reverse Proxy

#Proxy ke Container Docker

Ketika Caddy berjalan di host dan aplikasi di container, pakai nama container atau IP:

api.example.com {
    reverse_proxy web:3000
}

Pada Docker network yang sama, nama web terselesaikan ke alamat IP container. Jika Caddy dan aplikasi berada di network berbeda, pakai host.docker.internal:port atau alamat IP container. Detail lengkap di episode 27.

#WebSocket Proxying

Caddy mendeteksi upgrade WebSocket secara otomatis dan mem-proxy koneksi tersebut tanpa konfigurasi khusus:

chat.example.com {
    reverse_proxy localhost:9000
}

Request dengan header Upgrade: websocket diteruskan sebagai koneksi yang di-upgrade. Tidak perlu opsi tambahan — Caddy mengangkat ini secara native. Episode 25 akan membahas WebSocket secara mendalam.

#gRPC Proxying

gRPC membutuhkan HTTP/2. Caddy menangani ini lewat transport yang tepat:

grpc.example.com {
    reverse_proxy localhost:50051 {
        transport http {
            versions h2c 2
        }
    }
}

transport http { versions h2c 2 } memaksa koneksi ke backend memakai HTTP/2 cleartext (h2c) — protokol yang dibutuhkan gRPC. Detail gRPC ada di episode 26.

#Transport Options

#Versi HTTP dan Timeouts

Block transport mengontrol bagaimana Caddy berbicara ke backend:

app.example.com {
    reverse_proxy localhost:8080 {
        transport http {
            versions h1 h2
            read_timeout 30s
            write_timeout 30s
            dial_timeout 10s
        }
    }
}

• versions h1 h2 — backend bisa dilayani dengan HTTP/1.1 atau HTTP/2.
• dial_timeout — batas waktu membuka koneksi ke backend.
• read_timeout dan write_timeout — batas waktu baca dan tulis.

Timeout yang terlalu pendek memutus request lambat; terlalu panjang menahan koneksi yang macet. Mulai dari 30 detik dan sesuaikan dengan kebutuhan aplikasi.

#Keep-Alive

Caddy menjaga koneksi ke backend tetap hidup (keep-alive) secara default. Ini menghindari biaya membuat koneksi baru untuk setiap request — penting untuk aplikasi dengan traffic tinggi.

#Use Case: Mengekspos Aplikasi Modern

Dengan reverse proxy, kalian bisa mengekspos:

• Aplikasi Node.js di port acak seperti 3000.
• Aplikasi Python (Django, Flask) di port 8000.
• Container di Docker network internal.
• Microservices di port berbeda di bawah satu domain.
• API backend REST atau gRPC.

caddy reload --config Caddyfile cukup untuk menerapkan perubahan tanpa memutus koneksi aktif — salah satu alasan Caddy nyaman di operasional.

#Penutup

Episode 6 memperkenalkan reverse proxy: reverse_proxy dengan satu atau banyak backend, manipulasi header dengan header_up dan header_down, pola proxy ke localhost dan container, WebSocket yang otomatis, gRPC dengan h2c, serta transport options termasuk versi HTTP dan timeouts.

Inti yang harus dibawa pulang:

• reverse_proxy localhost:port sudah cukup untuk aplikasi sederhana.
• Header X-Forwarded-* dikirim otomatis ke upstream.
• header_up untuk header ke backend, header_down untuk ke klien.
• WebSocket di-proxy otomatis tanpa konfigurasi.
• gRPC butuh transport http { versions h2c 2 }.
• caddy reload menerapkan perubahan tanpa downtime.

Di episode 7 selanjutnya kita masuk ke keajaiban utama Caddy: automatic HTTPS magic — protokol ACME, integrasi Let's Encrypt, validasi domain, issuance dan renewal otomatis, storage sertifikat, serta tipe challenge HTTP-01, TLS-ALPN-01, dan DNS-01.