Second Brain

Cloudflare Tunnel vs Nginx

5 menit baca

What It Is

Kerangka untuk memutuskan lapisan mana yang dipakai saat mengekspos service. Titik awalnya: nginx sering memainkan dua peran sekaligus, dan Cloudflare Tunnel hanya menggantikan salah satunya.

  • Peran 1 — ingress publik (edge): menerima trafik dari internet, terminasi TLS, arahkan ke backend. Ini yang Tunnel gantikan.
  • Peran 2 — router internal: membagi trafik ke banyak service di dalam (path routing, rewrite, load balancing antar replika, health check). Ini yang Tunnel tidak gantikan.

Karena satu nginx bisa merangkap keduanya, pertanyaan “Tunnel atau nginx?” sering salah bentuk. Yang benar: lapisan mana yang sedang dibicarakan.

How To Use

Empat pertanyaan yang menentukan pilihan:

  1. Siapa yang harus menjangkau apa? Internet → service publik (Tunnel/nginx edge). Hanya perangkat sendiri (Tailscale).
  2. Di mana TLS berakhir? Di edge Cloudflare, di nginx, atau di aplikasi.
  3. Ada IP publik dan DMZ? Ada → nginx edge tetap wajar. Tidak ada → Tunnel menghapus seluruh kebutuhan itu.
  4. Trafiknya utara-selatan atau timur-barat? Dari luar ke dalam = urusan edge. Antar-service di dalam = urusan router internal, Cloudflare tidak ikut campur.
SituasiAlat
Service publik, tanpa IP publik / tidak mau buka portCloudflare Tunnel
Service publik, ada IP publik + kontrol firewall sendiringinx di edge
Beberapa service di satu hostname (path routing)bisa Tunnel (field Path), atau Caddy/nginx
Butuh rewrite path / manipulasi headernginx atau Caddy — Tunnel tidak bisa
Load balancing antar replika + health checknginx, Caddy, Traefik
Non-HTTP (SSH, RDP, DB)Tunnel (+ Access), atau Tailscale
Antar-service internal (timur-barat)Docker DNS, service mesh, nginx internal
Akses berbasis identitas, bukan aturan IPCloudflare Access, Tailscale ACL

Details

Kapan Tunnel yang tepat

  • Tidak ada IP publik, atau sengaja tidak mau membukanya
  • Mau nol port terbuka — origin tidak bisa dijangkau langsung dari internet, jadi permukaan serangnya mengecil secara struktural
  • Ingin akses ditentukan identitas (Access: email/SSO), bukan aturan IP
  • Butuh protokol non-HTTP: SSH, RDP, TCP, Unix socket
  • Skala kecil-menengah, satu host, banyak subdomain

Yang sudah dipindahkan dari nginx ke edge Cloudflare

  • Terminasi TLS (Universal SSL gratis, auto-renew)
  • WAF, DDoS protection, caching
  • Rate limiting, header via Transform Rules
  • Autentikasi via Access

Artinya alasan lama “perlu nginx untuk kompresi / rate limit / header keamanan” sebagian besar sudah tersedia gratis di depan tunnel.

Yang tetap tidak bisa dilakukan Tunnel

  • Rewrite path — /api di klien tidak bisa diubah menjadi / di backend; Location header tidak bisa dimanipulasi
  • Load balancing dengan health check antar replika
  • Multiplexing protokol di satu port
  • Kontrol L7 detail: timeout per-route, proxy_protocol, mTLS antar internal

Kompromi memakai Cloudflare

  • Trafik melewati pihak ketiga (untuk data internal sensitif, ini sering alasan sah untuk tidak memakainya)
  • Ada batas paket gratis dan biaya per-request untuk fitur lanjutan
  • Dependensi vendor, dan debug dilakukan lewat dashboard, bukan langsung di mesin
  • Trafik internal yang tidak boleh keluar jaringan sendiri tidak boleh dirutekan lewat sini

Pola paling umum di produksi

Internet → Cloudflare edge (WAF, TLS, cache, Access)
              ↓ tunnel (koneksi keluar, tanpa port terbuka)
           nginx/Caddy di dalam (routing, rewrite, LB)
              ↓
           aplikasi

Yang berubah dibanding arsitektur kantor bukan kemampuan nginx, tapi titik terminasi TLS dan titik kepercayaan.

Kenapa kantor memakai nginx — alasan yang tetap sah

  • Sudah punya IP publik dan kontrol firewall, jadi edge sendiri lebih murah dan tanpa dependensi tambahan
  • Data tidak melewati pihak ketiga
  • Kemampuan debug langsung (nginx -T, log lokal, tcpdump)
  • Ops sudah punya ototnya; mengganti berarti melatih ulang tim untuk manfaat yang tidak sepadan

Peta alat per kategori

  • Edge / TLS / WAF: Cloudflare, nginx, AWS ALB
  • Ingress publik tanpa IP publik: Cloudflare Tunnel, Tailscale Funnel, ngrok
  • Router internal / path routing / LB: nginx, Caddy, Traefik, Envoy
  • Mesh antar-service (timur-barat): Istio, Linkerd, Tailscale, Consul
  • Akses berbasis identitas: Cloudflare Access, Tailscale ACL, zero-trust VPN

Istilah yang perlu dikuasai

  • North-south vs east-west: trafik masuk-keluar vs antar-service. Beda pemilik, beda alat.
  • TLS termination: titik di mana enkripsi dilepas. Menentukan siapa yang melihat isi trafik.
  • Origin: server sebenarnya di belakang proxy/edge.
  • Perimeter vs zero-trust: kepercayaan berbasis lokasi jaringan vs berbasis identitas tiap request.

Examples

Latihan bertahap di lab sendiri (urutan ini mengajarkan paling banyak)

  1. Tahap 1 — tunnel → satu service (uptime-kuma). Satu hostname, nol port terbuka. Yang dipelajari: ingress publik tanpa exposur.
  2. Tahap 2 — tambah aplikasi kedua di subdomain lain. Perhatikan: tidak ada konfigurasi baru di sisi server selain satu entry dashboard. Yang dipelajari: satu tunnel melayani banyak hostname.
  3. Tahap 3 — paksa dua service masuk satu hostname dengan path (/kuma, /app). Di sini akan menabrak batas: aplikasi mengharapkan path yang berbeda dan tunnel tidak bisa rewrite. Solusinya Caddy atau nginx di belakang tunnel. Setelah mengalami sendiri, konsep “edge vs router” jadi konkret.

Pola yang dipakai di lab ini

  • Setiap aplikasi = satu direktori /srv/apps/<nama> + satu subdomain di tunnel
  • Service URL di tunnel memakai nama container, bukan localhost, kalau cloudflared berada di network Docker yang sama
  • Port service tetap dipublikasikan ke 127.0.0.1 saja; jalan masuk satu-satunya adalah tunnel

Catatan teknis Cloudflare Tunnel

  • Satu tunnel melayani banyak hostname — bukan satu tunnel per aplikasi
  • Ingress rule dievaluasi dari atas ke bawah; tidak ada yang cocok → 404
  • Rule bisa mencocokkan hostname dan path (regex Go), jadi path routing sederhana bisa tanpa nginx
  • DNS dibuat otomatis: CNAME ke <UUID>.cfargotunnel.com
  • cloudflared tunnel login memakai callback ke localhost, jadi gagal di VPS headless — untuk server, pakai tunnel remotely-managed dari dashboard dan jalankan dengan token

Tampilan Grafik

Tautan Balik