Nginx Proxy Manager Adalah: Fungsi, Port 81 & SSL Otomatis

Satu server virtual yang sudah berjalan beberapa bulan biasanya tidak berisi satu aplikasi saja. Ada panel pemantau di port 19999, alat otomatisasi di port 5678, dan brankas kata sandi di port 8080. Semuanya hidup dan bisa dibuka, tetapi alamatnya berupa deretan angka yang tidak seorang pun sanggup menghafalnya.

Persoalannya bukan sekadar susah diingat. Alamat berupa IP dan nomor port tidak bisa dipasangi sertifikat keamanan, sehingga lalu lintasnya berjalan tanpa enkripsi. Jalan keluar bakunya menempatkan satu perantara di depan semua aplikasi itu, lalu membiarkan perantara tersebut yang memegang domain dan sertifikat. Perantara semacam ini disebut reverse proxy (perwakilan sisi server), dan menyiapkannya berarti menulis berkas konfigurasi Nginx satu per satu.

Bagian terakhir itulah yang membuat banyak orang berhenti di tengah jalan. Nginx Proxy Manager lahir untuk memotong langkah tersebut.

Nginx Proxy Manager Adalah Antarmuka Web di Atas Nginx

Nginx Proxy Manager adalah aplikasi berbasis web untuk mengatur Nginx sebagai reverse proxy lewat formulir. Anda tidak menyentuh satu baris pun berkas konfigurasi. Anda mengisi nama domain, alamat tujuan, dan nomor port. Aplikasi ini yang menuliskan konfigurasinya, meminta sertifikat, lalu memuat ulang Nginx.

Perlu ditegaskan sejak awal: ia bukan web server baru dan bukan pengganti Nginx, melainkan lapisan pengelola yang duduk di atasnya. Mesinnya tetap Nginx, hanya saja yang menuliskan aturannya bukan lagi Anda.

Proyek ini dirilis sebagai citra Docker siap pakai berlisensi MIT, dikembangkan terbuka sejak 20 Desember 2017. Saat artikel ini ditulis, repositorinya mengumpulkan 34.117 bintang di GitHub dan citranya di Docker Hub sudah diunduh 274.718.844 kali. Angka kedua menjelaskan posisinya dengan jujur: ia menjadi pilihan bawaan bagi pengelola banyak layanan di server sendiri.

Singkatan NPM dipakai dua produk yang sama sekali berbeda. Di ekosistem JavaScript, npm adalah Node Package Manager, pengelola paket untuk Node.js. Di kalangan pengguna server pribadi, NPM berarti Nginx Proxy Manager. Keduanya tidak berhubungan, dan konteks percakapanlah yang menentukan maksudnya.

Cara Kerja Nginx Proxy Manager: Formulir Jadi Berkas Konfigurasi

Yang terjadi setelah Anda menekan tombol Save dapat dirunut dalam empat langkah. Isian formulir disimpan lebih dulu ke basis data. Dari data itu, sebuah templat dirender menjadi berkas konfigurasi Nginx yang sesungguhnya dan ditaruh di /data/nginx/proxy_host/. Nginx kemudian dimuat ulang agar membaca berkas baru tersebut. Sejak detik itu, domain Anda sudah dilayani.

Alur permintaan pengunjung berjalan terpisah dari itu. DNS mengarahkan domain ke alamat IP server Anda, lalu permintaan masuk ke port 80 atau 443 milik container. Nginx mencocokkan nama domain tersebut dengan daftar Proxy Host, kemudian meneruskannya ke alamat tujuan yang tertulis di sana.

Ada satu detail teknis yang menjelaskan banyak gejala di kemudian hari. Baris penerusannya ditulis begini:

proxy_pass $forward_scheme://$server:$port;

Alamat tujuannya berupa variabel, bukan teks tetap. Konsekuensinya, nama tujuan baru diterjemahkan menjadi alamat IP saat permintaan datang, bukan saat Nginx menyala. Inilah sebabnya Nginx Proxy Manager tetap hidup meski salah satu aplikasi di belakangnya sedang mati. Ia baru mengeluh belakangan, dalam bentuk halaman error kepada pengunjung.

Selain meneruskan, ia menambahkan header X-Forwarded-For dan X-Real-IP. Tanpa keduanya, aplikasi Anda akan mencatat seluruh pengunjung sebagai satu alamat yang sama.

Enam Hal yang Bisa Anda Atur dari Panelnya

Menu di panel terbagi menjadi enam jenis pekerjaan. Mengetahui pembagiannya lebih dahulu menghemat waktu, karena banyak kebingungan pemula bermula dari memilih menu yang salah.

1. Proxy Host: meneruskan sebuah domain ke aplikasi di belakang. Ini menu yang paling sering dipakai, dan di sinilah sakelar HTTP/2, WebSocket, serta penyaring eksploitasi umum berada.
2. Redirection Host: mengalihkan satu domain ke alamat lain, lengkap dengan pilihan kode pengalihan. Cocok untuk memindahkan domain lama ke domain baru.
3. 404 Host: menjawab domain yang mengarah ke server Anda tetapi tidak Anda kenali, dengan halaman kosong alih-alih isi situs lain.
4. Streams: meneruskan koneksi TCP atau UDP mentah, bukan lalu lintas web. Modul stream Nginx inilah yang dipakainya, sehingga SSH, server permainan, atau basis data bisa dijangkau dari luar.
5. Access Lists: membatasi siapa yang boleh membuka sebuah Proxy Host, lewat daftar alamat IP, nama pengguna dan kata sandi, atau keduanya sekaligus.
6. Certificates: tempat seluruh sertifikat dikelola, baik yang diterbitkan Let's Encrypt maupun yang Anda unggah sendiri.

Menu Streams menyimpan satu jebakan yang sering memakan waktu berjam-jam. Menambahkan stream di panel tidak otomatis membuka port tersebut di container. Port itu harus Anda publikasikan sendiri di docker-compose.yml, lalu container dijalankan ulang. Selama belum, stream akan tampak sudah dibuat tetapi tidak pernah menjawab.

Dua batas lain perlu diketahui. Satu entri stream hanya menangani satu nomor port, jadi rentang port harus didaftarkan satu per satu. Dan bila stream diberi sertifikat, koneksinya diakhiri di Nginx Proxy Manager — fitur SSL passthrough tidak tersedia di sini.

Tiga Port Nginx Proxy Manager: 80, 443, dan 81

Container ini membuka tiga port sekaligus, dengan tugas yang berbeda jauh. Ketiganya adalah nomor default dan bisa diubah.

Port 80 wajib terbuka bukan hanya untuk melayani pengunjung. Let's Encrypt membuktikan kepemilikan domain Anda dengan mengunjungi port itu, sehingga menutupnya berarti mematikan penerbitan sertifikat otomatis.

Port 81 kasusnya kebalikan. Di situ berdiri panel yang menguasai seluruh domain di server Anda, dijangkau lewat HTTP biasa tanpa enkripsi. Membiarkannya terbuka ke internet sama saja memajang kunci di depan pintu. Tiga cara yang lebih aman: batasi lewat firewall, akses lewat terowongan SSH, atau proksikan panel itu ke domain ber-HTTPS milik Anda sendiri.

Bila angka 81 bentrok dengan layanan lain, nomor itu dapat diganti lewat variabel lingkungan NPM_ADMIN_PORT. Port penggantinya wajib ikut dipublikasikan di docker-compose.yml.

Satu hal perlu diperiksa sebelum memasang: pastikan port 80 dan 443 belum dipakai web server lain. Apache atau Nginx bawaan sistem yang menempati keduanya akan membuat container gagal menyala.

Memasang Nginx Proxy Manager Lewat Docker Compose

Satu-satunya cara resmi menjalankannya adalah lewat Docker. Dengan mengemas Nginx, Certbot, dan seluruh kelengkapannya dalam satu citra, pengembangnya memastikan semua orang menjalankan versi komponen yang sama persis.

Seluruh proses install Nginx Proxy Manager terdiri dari dua langkah. Buat sebuah folder kosong, lalu simpan berkas docker-compose.yml berikut di dalamnya:

services:
  app:
    image: 'jc21/nginx-proxy-manager:2.15.1'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Jalankan dengan perintah berikut dari folder yang sama:

docker compose up -d

Dua volume di atas adalah bagian terpenting. Folder data menampung basis data, konfigurasi Nginx yang dihasilkan, dan log; folder letsencrypt menampung sertifikat. Kehilangan keduanya berarti kehilangan seluruh pengaturan Anda, jadi dua folder inilah yang wajib masuk jadwal pencadangan.

Basis data bawaannya adalah SQLite, berupa satu berkas di folder data, dan untuk pemakaian biasa sudah memadai. MariaDB dan PostgreSQL tersedia lewat variabel lingkungan, tetapi baru masuk akal bila Anda sudah menjalankan server basis data terpisah.

Penyalaan pertama membutuhkan satu sampai dua menit. Selama itu container membuat kunci penandatangan, menyiapkan struktur tabel, lalu menyalakan Nginx. Panel di port 81 belum menjawab sebelum ketiganya selesai, dan ini normal.

Bila server Anda tidak mengaktifkan IPv6, tambahkan variabel lingkungan DISABLE_IPV6: 'true'. Tanpa itu, log akan dipenuhi pesan "Address family not supported by protocol" dan sebagian Proxy Host bisa gagal dimuat.

Login Pertama Kini Lewat Setup Wizard, Bukan Kata Sandi Bawaan

Cara masuk pertama kali sudah berubah, dan perbedaannya cukup mendasar.

Sampai versi 2.12.6, container membuat sendiri satu pengguna administrator dengan alamat admin@example.com dan kata sandi changeme. Anda masuk memakai keduanya, lalu diminta menggantinya.

Sejak versi 2.13.0 yang terbit 4 November 2025, perilaku itu dihapus dari kode. Tidak ada lagi pengguna bawaan. Yang muncul saat panel pertama kali dibuka adalah layar pembuatan administrator: Anda mengisi sendiri nama, alamat surel, dan kata sandi. Perubahan ini datang bersama antarmuka baru, dan alasannya jelas — akun dengan kata sandi yang sudah diketahui seluruh internet adalah risiko yang tidak perlu ada.

Jalur lama masih disediakan untuk pemasangan otomatis. Bila kedua variabel lingkungan berikut diisi, administrator pertama dibuat langsung tanpa melewati layar tersebut:

environment:
  INITIAL_ADMIN_EMAIL: admin@domainanda.com
  INITIAL_ADMIN_PASSWORD: sandiRahasia123

Perlu diperhatikan, keduanya hanya berlaku saat basis data masih kosong. Mengubah nilainya pada instalasi yang sudah berjalan tidak berpengaruh.

Lalu bagaimana bila kata sandi terlupa? Panel ini tidak menyediakan fitur reset password lewat surel, jadi jalurnya lewat berkas. Hentikan container, buka data/database.sqlite dengan perkakas SQLite, lalu perbarui baris kata sandi pada tabel autentikasi. Bila instalasi Anda masih baru, menghapus berkas basis data lalu mengulang dari layar pembuatan administrator biasanya lebih cepat.

Perlu dicatat juga, identitas pengguna di sini berupa alamat surel, bukan username terpisah. Tidak ada kolom nama pengguna di halaman masuk.

SSL Otomatis Nginx Proxy Manager: Yang Diurus dan Yang Tidak

Penerbitan sertifikat adalah alasan utama orang memilih aplikasi ini. Ada baiknya memisahkan dengan tegas mana yang otomatis dan mana yang tetap menjadi tanggung jawab Anda.

Yang diurus sendiri olehnya:

1. Permintaan sertifikat ke Let's Encrypt: dilakukan lewat Certbot yang sudah tertanam di dalam citra, memakai metode pembuktian lewat berkas di port 80.
2. Pemilihan jenis kunci: sertifikat memakai kunci ECDSA kurva secp384r1, bukan RSA. Kunci ini lebih pendek dengan keamanan setara, sehingga jabat tangan TLS sedikit lebih ringan.
3. Pemeriksaan berkala: sebuah pengatur waktu di dalam aplikasi berjalan setiap satu jam memeriksa seluruh sertifikat yang tersimpan.
4. Perpanjangan: sertifikat yang masa berlakunya tersisa kurang dari 30 hari diperbarui otomatis. Anda tidak perlu menyiapkan penjadwal tugas apa pun di sistem operasi.
5. Pemasangan ulang: setelah sertifikat baru diterima, berkas konfigurasi diperbarui dan Nginx dimuat ulang tanpa memutus koneksi yang sedang berjalan.

Yang tetap menjadi tanggung jawab Anda:

1. Domain harus sudah mengarah ke server. Selama catatan A domain menunjuk alamat lain, permintaan sertifikat akan gagal.
2. Port 80 harus dapat dijangkau dari internet. Firewall yang menutupnya, atau penyedia yang memblokirnya, membuat pembuktian kepemilikan mustahil diselesaikan.
3. Sertifikat wildcard membutuhkan cara lain. Sertifikat untuk *.domainanda.com hanya bisa diterbitkan lewat pembuktian melalui catatan DNS, sehingga Anda perlu memilih penyedia DNS dan memasukkan kunci APInya.
4. Plugin DNS dirawat pihak lain. Modul tiap penyedia DNS dikembangkan terpisah dari Certbot dan tidak semuanya mengikuti versi terbaru. Memakai dua penyedia DNS berbeda pada satu instalasi berpeluang menimbulkan bentrok dependensi.

Protokol di balik semua ini adalah ACME, standar yang sama untuk sebagian besar penerbitan sertifikat SSL otomatis saat ini.

Satu hal membuat kegagalan sertifikat terasa membingungkan: pesan di panel sering hanya berbunyi Internal Error, tanpa keterangan apa pun. Kalimat itu adalah jawaban umum untuk kesalahan yang tidak ditandai aman ditampilkan. Kabar baiknya, khusus urusan sertifikat rincian aslinya tetap disertakan. Buka log container dengan docker compose logs -f, lalu cari baris dari Certbot. Di situlah sebab sesungguhnya tertulis: domain belum mengarah ke server, port 80 tertutup, atau kunci API penyedia DNS ditolak.

502 Bad Gateway: Penyebab Tersering dan Cara Memastikannya

Kode 502 berarti Nginx berhasil menerima permintaan pengunjung, tetapi gagal mendapat jawaban dari aplikasi yang Anda tunjuk. Masalahnya hampir selalu ada di antara container, bukan di Nginx. Berikut penyebabnya, diurutkan dari yang paling sering terjadi.

Pertama, alamat tujuan diisi localhost atau 127.0.0.1. Keliru karena alasan yang tidak kasat mata: di dalam container, 127.0.0.1 menunjuk ke container itu sendiri, bukan ke server Anda. Nginx Proxy Manager yang diberi tujuan 127.0.0.1:3000 mencari aplikasi di dalam dirinya sendiri dan tidak menemukan apa pun. Isi dengan nama container tujuan atau alamat IP jaringan Docker.

Kedua, kedua container tidak berada di jaringan yang sama. Nama container hanya bisa diterjemahkan menjadi alamat kalau keduanya bergabung ke jaringan Docker yang sama. Buat satu jaringan bersama, lalu daftarkan kedua layanan ke sana:

docker network create proxy-net

Ketiga, nomor port yang diisi adalah port sisi server, bukan port di dalam container. Aplikasi yang dipetakan 8080:80 berarti port 80 di dalam container. Karena penerusan terjadi antar-container, angka yang benar adalah 80, bukan 8080.

Keempat, skema tertukar. Aplikasi yang hanya melayani HTTP tetapi dituju dengan https akan menolak koneksi, dan sebaliknya.

Memastikannya tidak perlu menebak. Jalankan satu perintah dari dalam container Nginx Proxy Manager untuk menghubungi tujuan:

docker exec <nama-container-npm> \
  curl -I http://nama-tujuan:3000

Bila perintah itu mengembalikan baris status HTTP, jaringan sudah benar dan kesalahan ada pada isian di panel. Bila yang muncul pesan gagal terhubung atau nama tidak dikenal, masalahnya di jaringan Docker — mengutak-atik panel tidak akan menolong.

Dua keadaan berikut punya sebab yang berbeda dan tidak perlu ditangani dengan cara di atas. Kode 502 yang muncul tepat saat Anda membuka panel untuk pertama kali biasanya hanya berarti container belum selesai menyala. Tunggu satu sampai dua menit, lalu muat ulang halaman. Kode 502 yang muncul setelah pembaruan container biasanya berarti aplikasi di belakangnya mendapat alamat IP baru dan belum siap menerima koneksi.

Halaman errornya berbunyi "openresty", bukan "nginx", dan ini bukan tanda ada perangkat lunak asing di server Anda. Citra Nginx Proxy Manager dibangun di atas OpenResty, yaitu Nginx yang dipaketkan bersama penerjemah Lua. Halaman error bawaannya memang menyebut nama itu.

Batas Bawaan Nginx Proxy Manager yang Jarang Disadari

Sejumlah nilai sudah ditetapkan di dalam citra dan tidak terlihat di mana pun pada panel. Mengetahuinya menghemat waktu penelusuran saat sesuatu berhenti bekerja tanpa pesan yang jelas.

Angka 2000 MB jauh lebih longgar daripada bawaan Nginx biasa yang hanya 1 MB. Artinya, kegagalan mengunggah berkas besar hampir pasti berasal dari batas milik aplikasi di belakangnya, bukan dari perantaranya.

Batas waktu 90 detik menjelaskan gejala lain. Aplikasi yang mengerjakan proses panjang seperti pembuatan laporan atau impor data besar akan dijawab dengan kode 504 begitu melewati angka itu. Prosesnya sendiri tetap berjalan sampai selesai di belakang.

Sakelar Cache Assets pada Proxy Host juga sering disalahpahami. Menyalakannya membuat berkas CSS, JavaScript, gambar, dan font disimpan di sisi server selama 30 menit, sementara jawaban berkode 404 disimpan satu menit. Untuk situs yang berkasnya jarang berubah ini menguntungkan. Selama pengembangan tampilan, justru menyusahkan.

Bila salah satu nilai di atas perlu diubah, tersedia dua jalur untuk menuliskan konfigurasi kustom. Tab Advanced pada tiap Proxy Host menyediakan kolom Custom Nginx Configuration, yang isinya disisipkan langsung ke blok konfigurasi domain tersebut. Berkas potongan di folder /data/nginx/custom/ berlaku untuk seluruh domain sekaligus — server_proxy.conf, misalnya, ikut disertakan pada setiap Proxy Host.

Jalur yang sama dipakai untuk mengganti halaman error bawaan. Direktif error_page beserta lokasi berkas HTML Anda sendiri di kolom Advanced membuat halaman 404 dan 502 tampil sesuai tampilan situs Anda.

Access List dan Efek Sampingnya pada Login Aplikasi

Access List adalah cara membatasi siapa yang boleh membuka sebuah domain. Isinya dapat berupa daftar alamat IP yang diizinkan atau ditolak, nama pengguna beserta kata sandi, atau keduanya sekaligus. Inilah fasilitas yang Anda pakai untuk melindungi sebuah situs dengan kata sandi tanpa menyentuh aplikasinya sama sekali.

Saat keduanya dipakai bersamaan, ada satu pilihan yang menentukan segalanya:

• Satisfy Any: cukup salah satu syarat terpenuhi. Pengunjung dari alamat IP yang terdaftar langsung diterima tanpa diminta kata sandi, sementara pengunjung dari luar tetap bisa masuk dengan kata sandi.
• Satisfy All: kedua syarat wajib terpenuhi. Alamat IP harus terdaftar dan kata sandi harus benar.

Salah memilih di antara keduanya adalah penyebab paling umum halaman 403 Forbidden yang muncul padahal Anda merasa sudah memasukkan username dan kata sandi yang benar.

Efek samping berikutnya lebih halus dan didokumentasikan resmi. Bila aplikasi di belakang Proxy Host juga punya halaman login sendiri, keduanya memperebutkan header Authorization yang sama. Standar HTTP pada RFC 7230 melarang satu header muncul dua kali dengan nilai berbeda. Akibatnya salah satu login pasti rusak — biasanya login aplikasinya.

Sakelar Pass Auth to Host mengatur perilaku ini. Saat dimatikan, Nginx menghapus header tersebut sebelum meneruskan permintaan, sehingga aplikasi di belakang tidak pernah melihatnya. Aturan praktisnya sederhana: jangan menumpuk Access List berkata sandi di atas aplikasi yang sudah punya login sendiri. Untuk aplikasi semacam itu, batasi dengan daftar alamat IP saja.

Kelemahan Nginx Proxy Manager yang Perlu Anda Pertimbangkan

Kemudahan yang ditawarkannya datang bersama sejumlah batas yang perlu Anda ketahui sebelum memutuskan.

1. Docker bukan pilihan, melainkan syarat. Tidak ada paket untuk dipasang langsung di sistem operasi, dan dokumentasinya menyatakan hal itu tanpa ruang tafsir. Server dengan kebijakan yang melarang container otomatis gugur.
2. Tidak ada pembagian beban bawaan. Satu Proxy Host hanya menerima satu alamat tujuan. Untuk membagi permintaan ke beberapa server, Anda harus menuliskan sendiri blok upstream lewat berkas potongan — persis pekerjaan manual yang ingin Anda hindari. Bila kebutuhan utama Anda memang load balancing, perkakas lain lebih tepat.
3. Tidak mendukung HTTP/3. Yang tersedia hanya sakelar untuk mengaktifkan HTTP/2. Bila HTTP/3 menjadi kebutuhan, Anda perlu menaruh lapisan lain di depannya.
4. Perangkat ARM lama sudah ditinggalkan. Dukungan armv7 dicabut sejak versi 2.14.0, sehingga Raspberry Pi generasi lama tertahan di versi 2.13.7 dan tidak lagi menerima pembaruan keamanan terbaru.
5. Ia menjadi satu titik kegagalan. Semua domain Anda melewati satu container. Ketika container itu bermasalah, seluruh layanan di belakangnya ikut tidak terjangkau sekaligus.
6. Sebagian kemampuan Nginx tidak terjangkau dari panel. Pembatasan laju permintaan, aturan penulisan ulang alamat yang rumit, atau pengaturan cache yang lebih halus tetap harus ditulis tangan di kolom Advanced.

Nginx Proxy Manager vs Traefik, Caddy, dan Nginx Manual

Pembanding yang paling berguna bukan soal kecepatan. Keempatnya sanggup melayani jauh lebih banyak permintaan daripada yang dibutuhkan sebagian besar server pribadi. Yang benar-benar membedakan adalah siapa yang menulis aturannya.

Traefik mengambil pendekatan berlawanan: ia membaca label pada tiap container dan menyusun rutenya sendiri. Container baru yang menyala langsung punya domain tanpa seorang pun membuka panel. Keunggulan itu terasa ketika container Anda sering naik dan turun. Untuk sepuluh layanan yang jarang berubah, ia hanya menambah konsep yang harus dipelajari.

Caddy memakai satu berkas konfigurasi yang jauh lebih ringkas daripada Nginx dan mengurus sertifikat sendiri. Pilihan bagus bila Anda tidak keberatan menyunting berkas, tetapi menolak kerumitan tata bahasa Nginx.

Nginx manual memberi kendali penuh tanpa menambah lapisan apa pun. Harganya waktu: tiap domain baru berarti menulis berkas, menguji konfigurasi, memuat ulang layanan, dan mengurus sertifikat lewat perkakas terpisah.

Dua nama lain kerap muncul saat orang mencari alternatifnya. NPMplus adalah percabangan Nginx Proxy Manager dengan pengetatan keamanan dan komponen yang lebih baru, 2.329 bintang, lisensi AGPL-3.0. Karena mengubah cukup banyak bagian, ia bukan sekadar versi yang lebih baru. Pangolin berada di kategori lain: ia memadukan reverse proxy dengan terowongan jaringan, sehingga layanan di rumah dapat dijangkau tanpa membuka port di router.

Peta Versi Nginx Proxy Manager dan Batas Dukungannya

Riwayat rilisnya panjang, tetapi hanya beberapa titik yang benar-benar mengubah cara Anda memakainya.

Versi 2.15.0 layak diberi perhatian khusus. Pembaruan basis sistem dan Certbot di dalamnya membuat sebagian plugin DNS berperilaku berbeda, dan catatan rilisnya memperingatkan hal itu secara terbuka. Bila sertifikat Anda diterbitkan lewat pembuktian DNS, sediakan waktu memeriksanya setelah memperbarui.

Pembaruannya sendiri sederhana. Dari folder yang sama, tarik citra baru lalu jalankan ulang:

docker compose pull
docker compose up -d

Perpindahan struktur basis data dikerjakan sendiri oleh aplikasi saat menyala. Meski begitu, mencadangkan folder data dan letsencrypt lebih dulu tetap praktik yang bijak.

Satu saran terakhir: tuliskan nomor versi di docker-compose.yml, jangan memakai penanda latest. Dengan nomor versi yang jelas, Anda tahu persis apa yang sedang berjalan dan bisa kembali ke versi sebelumnya saat ada yang berubah tidak seperti harapan.

Kapan Nginx Proxy Manager Masuk Akal, Kapan Tidak

Ia masuk akal bila Anda menjalankan kira-kira 3 sampai 15 layanan pada satu atau dua server. Syarat lainnya: layanan itu relatif menetap, kebutuhan HTTPS Anda standar, dan Anda lebih suka mengisi formulir daripada menyunting berkas. Untuk pola seperti ini, menambah domain baru memakan waktu di bawah dua menit.

Ia kurang masuk akal dalam empat keadaan. Bila Anda hanya punya satu aplikasi, container perantara hanya menambah satu hal lagi yang bisa rusak. Bila container Anda naik-turun otomatis mengikuti beban, perkakas yang membaca sendiri kondisi infrastruktur lebih hemat tenaga. Bila permintaan perlu dibagi ke beberapa server sekaligus, pilih perkakas yang dirancang untuk itu. Dan bila kebijakan tempat Anda bekerja melarang container, pilihannya tertutup sejak awal.

Yang dibutuhkan untuk menjalankannya adalah server dengan akses root dan Docker terpasang, misalnya sebuah VPS. Shared hosting gugur sejak syarat pertama karena tidak mengizinkan container sama sekali. Bila server Anda masih berupa shared hosting, layanan VPS adalah langkah nol yang harus dilewati lebih dulu. Kebutuhan sumber dayanya sendiri kecil: container ini berjalan nyaman pada memori 1 GB, karena beban sesungguhnya ada pada aplikasi di belakangnya.

Pertanyaan Seputar Nginx Proxy Manager

Apakah Nginx Proxy Manager gratis dan ada batas jumlah domainnya?

Gratis sepenuhnya dengan lisensi MIT, termasuk untuk keperluan komersial. Tidak ada edisi berbayar dan tidak ada fitur yang dikunci. Jumlah Proxy Host, Stream, maupun sertifikat yang boleh Anda buat juga tidak dibatasi.

Bisakah Nginx Proxy Manager dijalankan tanpa Docker?

Tidak bisa. Dokumentasi resminya menjawabnya secara langsung: begitulah proyek ini dikemas. Tujuannya agar versi Nginx dan seluruh komponen pendukung di dalamnya seragam bagi semua pengguna, sehingga laporan masalah dapat ditelusuri.

Apa kata sandi bawaan Nginx Proxy Manager?

Sejak versi 2.13.0 yang terbit 4 November 2025, tidak ada lagi kata sandi bawaan. Panel menampilkan layar pembuatan administrator saat pertama kali dibuka, dan Anda menentukan sendiri surel serta kata sandinya. Pasangan admin@example.com dan changeme hanya berlaku pada versi 2.12.6 ke bawah.

Bisakah Nginx Proxy Manager dipakai bersama Cloudflare?

Bisa, dan sebagian penyesuaiannya sudah disiapkan. Saat menyala, aplikasi ini mengunduh daftar alamat IP Cloudflare dan CloudFront, lalu menuliskannya sebagai daftar sumber tepercaya di konfigurasi Nginx. Daftar itu disegarkan setiap enam jam. Hasilnya, IP asli pengunjung tetap tercatat benar meski lalu lintas melewati Cloudflare lebih dulu. Dua hal perlu Anda perhatikan. Pertama, bila mode proksi Cloudflare aktif, terbitkan sertifikat lewat pembuktian DNS agar tidak bergantung pada port 80. Kedua, kode 522 yang muncul di layar pengunjung berasal dari Cloudflare, bukan dari server Anda. Artinya Cloudflare gagal menghubungi Nginx Proxy Manager, jadi yang perlu diperiksa adalah firewall dan port 443.

Di mana log Nginx Proxy Manager disimpan?

Seluruhnya ada di folder /data/logs/ di dalam container, yang berarti folder data di sisi server Anda. Tiap Proxy Host punya sepasang berkasnya sendiri: satu untuk log akses, satu untuk log error. Berkas ini dirotasi mingguan, dengan empat salinan tersimpan untuk log akses dan sepuluh untuk log error.

Bisakah satu domain diarahkan ke beberapa aplikasi sekaligus?

Bisa, asalkan pembagiannya berdasarkan jalur alamat, bukan berdasarkan beban. Fitur Custom Locations pada Proxy Host memungkinkan /api diteruskan ke satu aplikasi sementara sisanya ke aplikasi lain. Yang tidak bisa dilakukan dari panel adalah membagi permintaan yang sama ke beberapa server bergantian.

Kesimpulan

Nginx Proxy Manager adalah antarmuka web di atas Nginx yang mengubah pekerjaan menulis konfigurasi reverse proxy menjadi pengisian formulir. Sertifikat Let's Encrypt diterbitkan dan diperpanjang sendiri. Untuk server berisi beberapa aplikasi yang masing-masing ingin punya domain dan HTTPS, ia memotong pekerjaan yang tadinya memakan sore hari menjadi hitungan menit.

Dua hal perlu Anda bawa pulang. Pertama, panel di port 81 memegang kendali atas seluruh domain Anda dan tidak boleh dijangkau dari internet. Kedua, ia hanya meneruskan permintaan ke satu tujuan per domain. Begitu kebutuhan Anda bergeser ke pembagian beban atau ke lingkungan yang berubah sendiri, perkakas lain lebih menghemat tenaga.

Semoga artikel ini membantu.