Reverse Proxy: Kenapa Hampir Semua Setup Self-Hosted Butuh Ini

Setiap kali saya mulai self-host aplikasi baru — baik itu Laravel, dashboard internal, atau layanan AI yang jalan lokal — pertanyaan pertama yang saya jawab bukan "bagaimana cara jalankan aplikasinya", tapi "bagaimana cara mengeksposnya ke jaringan dengan aman". Godaan paling gampang adalah langsung buka port aplikasi itu ke publik: docker run -p 8080:80, arahkan DNS, selesai. Tapi begitu ada lebih dari satu aplikasi, atau setup itu mulai serius dipakai orang lain, pola ini cepat berantakan. Di sinilah reverse proxy masuk, dan menurut saya ini salah satu konsep infrastruktur yang paling underrated buat developer yang baru mulai self-host.

Apa itu reverse proxy, sederhananya

Reverse proxy adalah server yang duduk di depan aplikasi-aplikasi Anda dan menerima semua request dari luar atas nama mereka. Klien di internet tidak pernah bicara langsung ke Laravel, Node, atau container apa pun — mereka bicara ke reverse proxy, lalu proxy itu yang meneruskan request ke aplikasi yang tepat di belakangnya, berdasarkan domain, path, atau header tertentu. Nginx, Traefik, dan Caddy adalah contoh yang paling sering dipakai untuk peran ini.

Bedakan dengan forward proxy: forward proxy mewakili klien (misalnya VPN kantor yang menyamarkan siapa yang mengakses internet), sedangkan reverse proxy mewakili server — ia menyembunyikan berapa banyak dan seperti apa server di baliknya.

Kenapa ini lebih baik daripada expose port langsung

Kalau setiap aplikasi expose portnya sendiri ke publik, ada beberapa masalah yang muncul bertahap seiring setup Anda tumbuh:

Satu titik masuk, bukan banyak celah. Firewall cukup buka port 80/443 saja, bukan satu per satu untuk tiap aplikasi. Semakin sedikit port terbuka ke publik, semakin kecil permukaan serangan.
TLS terpusat. Sertifikat HTTPS diurus di satu tempat (reverse proxy), bukan diimplementasikan ulang di setiap aplikasi. Ini juga berarti aplikasi Anda sendiri tidak perlu tahu cara handle TLS — cukup jalan sebagai HTTP biasa di jaringan internal.
Banyak aplikasi, satu IP. Anda bisa host beberapa domain atau subdomain di satu server yang sama, dengan reverse proxy yang merutekan berdasarkan nama domain (namanya virtual hosting). Ini yang bikin satu VPS kecil bisa melayani banyak proyek sekaligus.
Topologi internal tersembunyi. Port aplikasi, versi framework, struktur container — semua itu tidak perlu terlihat dari luar. Yang publik lihat hanya reverse proxy.

Contoh sederhana dengan Docker

Di setup berbasis Docker, pola yang umum saya pakai adalah: container aplikasi tidak mem-publish port ke host sama sekali, cukup terhubung ke satu Docker network yang sama dengan container reverse proxy. Reverse proxy yang satu-satunya container dengan port terbuka ke host.

services:
  proxy:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    networks: [edge]

  app:
    build: ./app
    networks: [edge]
    # tidak ada "ports:" di sini — app hanya bisa diakses lewat proxy

Konfigurasi nginx-nya cukup merutekan berdasarkan nama domain ke nama service Docker (yang otomatis resolve lewat DNS internal Docker), misalnya proxy_pass http://app:80;. Aplikasi tidak pernah "terlihat" dari luar network itu sendiri.

Manfaat tambahan yang sering baru disadari belakangan

Selain alasan keamanan dan kepraktisan di atas, reverse proxy juga jadi tempat yang tepat untuk hal-hal lintas aplikasi: rate limiting, logging akses terpusat, kompresi response, sampai load balancing kalau suatu saat aplikasi butuh lebih dari satu instance. Semua ini bisa diatur satu kali di level proxy, tanpa menyentuh kode aplikasi sama sekali.

Takeaway

Kalau Anda baru mulai self-host dan masih terbiasa expose port langsung, reverse proxy bukan fitur opsional yang bisa ditunda — anggap saja itu lapisan dasar yang sebaiknya ada sejak aplikasi pertama Anda online, bukan sesuatu yang ditambahkan belakangan setelah "kepepet" butuh banyak domain atau kena insiden keamanan.