Yuk, Pasang Nginx Reverse Proxy di VPS Plus HTTPS Gratis Pakai Certbot

Halo Sobat Online! Bayangkan sebuah gedung kantor dengan satu resepsionis di pintu depan. Tamu tidak boleh langsung masuk ke ruangan mana pun; mereka melapor dulu, lalu diarahkan ke lantai yang tepat. Kurang lebih begitulah tugas Nginx reverse proxy di VPS: satu titik masuk yang mengarahkan setiap permintaan ke aplikasi yang benar di belakangnya.

Tanpa reverse proxy, setiap aplikasi harus punya portnya sendiri — http://IP-VPS:5678 untuk n8n, http://IP-VPS:3001 untuk dashboard monitoring, dan seterusnya. Alamat seperti itu tidak enak dibuka, tidak punya HTTPS, dan tiap port terbuka adalah pintu yang bisa diketuk siapa saja. Dengan reverse proxy, semua aplikasi berbagi satu pintu bernama port 443 dan dibedakan lewat nama subdomain.

Yang lebih enak: HTTPS-nya bisa gratis. Kita tinggal memakai Certbot untuk mengambil sertifikat Let’s Encrypt, lalu memperbaruinya otomatis. Mari kita kerjakan langkah demi langkah.

Apa Itu Nginx Reverse Proxy di VPS dan Kenapa Dipakai?

Reverse proxy adalah server yang menerima permintaan dari pengunjung, lalu meneruskannya ke server lain di belakang. Kata “reverse” dipakai karena arahnya berlawanan dengan forward proxy yang biasanya dipakai klien untuk menyembunyikan diri saat menjelajah.

Alurnya sederhana:

Browser membuka https://app.domainmu.com.
DNS sudah menunjuk ke IP VPS-mu, dan Nginx menerima permintaan itu di port 443.
Nginx melihat nama subdomainnya, lalu meneruskan permintaan ke aplikasi lokal, misalnya http://127.0.0.1:3000.
Jawaban aplikasi dikirim balik ke browser oleh Nginx.

Keuntungan yang paling terasa di dunia nyata:

Satu port untuk banyak aplikasi. Cukup buka port 80 dan 443 di firewall, sisanya tidak perlu.
HTTPS terpusat. Sertifikat diurus di Nginx, aplikasi di belakangnya boleh tetap berjalan sebagai HTTP biasa.
Aplikasi tidak perlu tahu dunia luar. Backend cukup bind ke 127.0.0.1, jadi tidak ada alamat yang bisa diakses langsung dari internet.
Gampang ganti isi. Mau tukar backend dari aplikasi A ke B? Ubah satu baris proxy_pass, lalu reload. Domain dan sertifikat tidak berubah.
Satu tempat untuk log, kompresi, dan pembatasan. Nginx bisa menambahkan gzip, rate limit, sampai menyembunyikan header yang tidak perlu.

Yang Perlu Disiapkan Sebelum Mulai

Persiapan di bawah ini singkat, tapi tiga poin pertama wajib:

VPS Linux (Ubuntu/Debian) dengan akses SSH dan hak sudo. Perintah di artikel ini memakai keluarga Debian.
Domain atau subdomain yang A record-nya sudah menunjuk ke IP VPS. Misalnya app.domainmu.com → IP publik VPS. Kalau DNS-nya masih salah, langkah HTTPS pasti gagal.
Satu aplikasi yang sudah jalan di localhost. Contoh paling gampang: aplikasi Node.js di http://127.0.0.1:3000. Uji dulu dengan curl -I http://127.0.0.1:3000 — kalau dari dalam VPS saja belum menyala, reverse proxy tidak akan menolong.
Firewall yang mengizinkan port 80 dan 443. Di UFW cukup satu perintah: sudo ufw allow 'Nginx Full'.
Aplikasi tidak boleh bentrok dengan Nginx. Kalau aplikasimu memakai port 80, pindahkan dulu ke port lain, karena port itu akan dipakai Nginx.

Langkah 1: Pasang Nginx dan Pastikan Port 80 Hidup

Mulai dari paket resmi distro, jangan dari skrip acak di internet:


sudo apt update
sudo apt install -y nginx
sudo systemctl enable --now nginx
nginx -v
curl -I http://127.0.0.1

Perintah terakhir harus menjawab HTTP/1.1 200 OK dari halaman selamat datang Nginx. Kalau sudah begitu, artinya web server berdiri dan port 80 hidup di dalam server.

Satu catatan supaya tidak bingung nanti: Nginx di paket Ubuntu versi stabil biasanya masih rilis 1.24 atau 1.26, sedangkan rilis mainline sudah jauh di depan. Nomor versi ini penting untuk satu baris konfigurasi yang kita bahas di Langkah 2.

Langkah 2: Tulis Konfigurasi Nginx Reverse Proxy

Di Debian/Ubuntu, konfigurasi tiap situs sebaiknya berada di sites-available, bukan ditumpuk di nginx.conf. Buat file baru, misalnya /etc/nginx/sites-available/app.domainmu.com:


server {
    listen 80;
    listen [::]:80;
    server_name app.domainmu.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        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;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        proxy_read_timeout 300s;
        client_max_body_size 64m;
    }
}

Baris yang tidak boleh hilang

proxy_pass menentukan alamat aplikasi di belakang. Arahkan ke 127.0.0.1, bukan ke IP publik VPS.
proxy_set_header Host $host membuat aplikasi tahu nama domain yang dipanggil pengunjung. Tanpa ini, banyak framework membangun URL yang salah.
X-Forwarded-For dan X-Real-IP menyelamatkan log dan fitur keamananmu: tanpa keduanya, semua pengunjung tercatat berasal dari 127.0.0.1.
X-Forwarded-Proto memberi tahu aplikasi bahwa aslinya pengunjung datang lewat HTTPS. Laravel, WordPress, dan Next.js sering butuh ini supaya tidak salah menulis alamat http://.
proxy_read_timeout 300s memperpanjang batas diam dari 60 detik (nilai bawaan Nginx) untuk permintaan yang memang lama, misalnya laporan atau impor data.
client_max_body_size 64m menaikkan batas ukuran unggahan. Bawaan Nginx hanya 1 MB, jadi unggahan gambar atau PDF bisa ditolak dengan error 413 kalau baris ini tidak ada.

WebSocket dan rahasia `map $connection_upgrade`

Baris Connection $connection_upgrade di atas belum ada isinya sampai kita mendefinisikan variabelnya. Tambahkan blok map berikut di konteks http, misalnya file baru /etc/nginx/conf.d/upgrade-map.conf:


map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Kenapa tidak langsung menulis Connection "upgrade"? Karena header Upgrade dan Connection adalah header hop-by-hop: Nginx sengaja tidak meneruskannya ke backend. Kalau Connection: upgrade dipaksa di semua permintaan, permintaan HTTP biasa pun ikut “naik kelas” dan keep-alive jadi kacau. Blok map membuat nilainya pintar: ada header Upgrade → kirim upgrade, tidak ada → kirim close. Ini yang membuat satu location bisa melayani halaman biasa dan WebSocket sekaligus.

Catatan versi Nginx yang baru berubah

Selama bertahun-tahun, Nginx berbicara ke backend dengan HTTP/1.0 secara bawaan, sehingga proxy_http_version 1.1 wajib ditulis untuk WebSocket. Sejak Nginx 1.29.7, nilai bawaannya sudah berubah menjadi 1.1 — dokumentasi resminya kini menandai baris itu sebagai “sebelum versi 1.29.7”. Karena mayoritas paket distro masih 1.2x, tetap tulis baris itu secara eksplisit: aman di versi baru, wajib di versi lama.

Langkah 3: Aktifkan Situs, Uji Konfigurasi, dan Baca Log

Sekarang hubungkan file tadi ke folder sites-enabled, lalu uji dan muat ulang:


sudo ln -s /etc/nginx/sites-available/app.domainmu.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
curl -I http://127.0.0.1 -H "Host: app.domainmu.com"
sudo tail -n 30 /var/log/nginx/error.log

Urutannya penting: nginx -t dulu, baru reload. Kalau konfigurasinya salah, reload tidak akan merusak situs yang sedang jalan. Perintah curl dengan header Host membuktikan Nginx sudah mengarahkan ke aplikasi yang benar tanpa perlu menunggu DNS.

Kalau muncul 502 Bad Gateway, hampir selalu penyebabnya aplikasi di belakang tidak jalan atau portnya salah. Cek dengan ss -lntp | grep 3000 — kalau kosong, nyalakan dulu aplikasinya. Kalau halaman Nginx selamat datang masih muncul, ada situs default yang menang rebutan; hapus symlink-nya dari sites-enabled lalu reload.

Langkah 4: Pasang HTTPS Gratis dengan Certbot

Situs sudah hidup di HTTP. Sekarang kita minta sertifikat Let’s Encrypt. Cara yang direkomendasikan Certbot adalah paket snap, karena versinya selalu terbaru dan punya izin yang dibutuhkan untuk membaca konfigurasi Nginx:


sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
sudo snap set certbot trust-plugin-with-root=ok
certbot --version

Kalau sebelumnya ada paket certbot dari apt, hapus dulu (sudo apt remove certbot) supaya perintah certbot tidak menunjuk versi lama. Setelah itu, ambil sekaligus pasang sertifikatnya:


sudo certbot --nginx -d app.domainmu.com

Certbot akan menanyakan surel untuk notifikasi kedaluwarsa, meminta persetujuan, lalu mengubah blok server-mu sendiri: menambah listen 443 ssl, menunjuk ke file di /etc/letsencrypt/live/, dan menawarkan pengalihan otomatis dari HTTP ke HTTPS (pilih opsi redirect supaya semua pengunjung masuk lewat jalur aman).

Pengecekan sesudahnya:


sudo nginx -t
systemctl status nginx --no-pager
sudo certbot certificates
curl -I https://app.domainmu.com

Perintah certbot certificates menampilkan daftar sertifikat beserta tanggal kedaluwarsanya — simpan kebiasaan ini, karena sertifikat adalah benda yang punya masa berlaku.

Satu catatan penting untuk validasi: Certbot memakai metode HTTP-01 lewat port 80. Jadi port 80 tidak boleh ditutup total sebelum sertifikat pertama didapat. Kalau VPS-mu memang tidak boleh membuka port apa pun, jalur yang cocok adalah DNS challenge atau Cloudflare Tunnel — pola “tanpa buka port” itu kita bahas di artikel Cloudflare Tunnel di VPS.

Langkah 5: Perpanjangan Otomatis (dan Kenapa Ini Makin Penting)

Certbot tidak menyelesaikan pekerjaannya sekali saja, tapi memasang penjadwal perpanjangan: bisa berupa cron job di /etc/cron.*/ atau systemd timer. Ia hanya memperbarui sertifikat ketika masa berlakunya sudah mendekati habis, jadi jangan heran kalau perintah certbot renew menjawab “not yet due”.

Cek dulu penjadwalnya benar-benar ada, lalu lakukan latihan perpanjangan:


systemctl list-timers | grep -i certbot
sudo certbot renew --dry-run

Perintah --dry-run melakukan semua langkah perpanjangan memakai server uji Let’s Encrypt, jadi tidak ada kuota produksi yang terpakai. Kalau latihan ini hijau, kamu bisa tidur tenang.

Sekarang bagian yang sering terlewat: umur sertifikat publik sedang dipangkas bertahap. Let’s Encrypt mengumumkan bahwa sertifikat 90 hari akan dipendekkan lewat profil ACME mereka — profil classic beralih ke 64 hari pada 10 Februari 2027, lalu ke 45 hari pada 16 Februari 2028. Masa pakai otorisasi domain juga menyusut, dari 30 hari menuju 7 jam. Artinya, penjadwalan manual seperti “perbarui tiap 60 hari” akan segera salah; satu-satunya cara aman adalah membiarkan Certbot memakai ACME Renewal Information (ARI) yang menghitung sendiri kapan harus memperbarui. Karena itu, cukup pasang Certbot versi terbaru dan jangan matikan penjadwal otomatisnya.

Masalah yang Paling Sering Muncul

Kumpulan gejala dan obatnya, biar tidak perlu menebak:

502 Bad Gateway → backend mati atau portnya salah. Cek ss -lntp | grep <port>.
400 atau 426 saat memakai WebSocket → blok map $http_upgrade belum dimuat, atau baris proxy_http_version 1.1 hilang.
413 Request Entity Too Large → naikkan client_max_body_size sesuai kebutuhan aplikasi.
Sertifikat gagal diterbitkan → DNS belum menunjuk ke IP VPS, atau port 80 tertutup firewall.
Semua permintaan dijawab halaman selamat datang Nginx → situs default masih aktif, atau server_name salah ketik.
Perubahan tidak terasa → lupa sudo systemctl reload nginx. Perubahan konfigurasi tidak berlaku sebelum diuji nginx -t dan dimuat ulang.
Jangan mengedit file di sites-enabled → folder itu berisi symlink; sunting yang asli di sites-available, supaya tidak ada dua sumber kebenaran.

Satu trik kecil yang berguna: kalau ingin membedakan masalah di Nginx atau di aplikasi, buka langsung http://127.0.0.1:3000 dari dalam VPS. Berhasil di situ tapi gagal lewat domain berarti masalahnya ada di lapisan proxy atau DNS, bukan di aplikasimu.

Kesimpulan: Satu Pintu, Banyak Aplikasi

Nginx reverse proxy di VPS mengubah cara kita menata server: tidak lagi “satu aplikasi satu port”, tetapi “satu pintu dengan banyak ruangan”. Setelah Nginx berdiri, menambah aplikasi berikutnya cuma butuh satu file konfigurasi baru dan satu subdomain — dan itu termasuk alasan n8n self-hosted maupun dashboard monitoring terasa jauh lebih rapi saat dipasang di belakang proxy.

Sobat Online, luangkan 15 menit hari ini untuk memindahkan satu aplikasi ke belakang Nginx, lalu jalankan sudo certbot --nginx. Setelah gembok kecil muncul di address bar, kamu akan sadar bahwa HTTPS gratis itu bukan hal yang rumit — dan setelah itu, menambah subdomain kedua dan ketiga terasa seperti mengisi rak, bukan membangun gedung baru. Selamat mencoba, dan bagikan hasilnya di kolom komentar!