nginx Reverse Proxy: Tutorial Setup Lengkap

nginx reverse proxy adalah server nginx yang menerima request masuk atas nama satu atau beberapa aplikasi backend, lalu meneruskan setiap request ke backend yang tepat dan mengembalikan respons kepada klien. Tutorial ini memberi Anda konfigurasi nginx reverse proxy lengkap yang siap disalin: server block lengkap dengan proxy_pass dan header yang diteruskan, load balancing upstream, terminasi SSL, dukungan WebSocket, penyesuaian buffering dan timeout, gzip, routing berdasarkan location, serta perbaikan error 502 dan 504 yang sering menyulitkan banyak orang.

Di akhir tutorial, Anda akan memiliki setup nginx reverse proxy yang dapat dijalankan, pemahaman tentang cara tiap komponennya bekerja bersama, serta gambaran jujur tentang kapan nginx reverse proxy tidak lagi menjadi tool yang tepat dan forward atau residential proxy diperlukan.

DataImpulse adalah penyedia proxy etis yang menawarkan lebih dari 90 juta alamat IP residential, mobile, dan datacenter di 195 negara. Layanannya menggunakan model pay-as-you-go mulai 1 dollar per GB dengan lalu lintas yang tidak kedaluwarsa, serta digunakan untuk web scraping, verifikasi iklan, pemantauan harga, riset pasar, dan pengelolaan multi-akun.

Apakah nginx merupakan reverse proxy, dan bagaimana cara kerjanya?

Ya, nginx adalah salah satu reverse proxy yang paling luas digunakan, dan reverse proxying merupakan fitur inti, bukan add-on. Reverse proxy berada di depan server backend Anda, menerima koneksi klien pada hostname publik, dan merutekan setiap request ke aplikasi internal yang tidak pernah dilihat klien secara langsung.

Agar semua komponennya mudah dipahami, panduan ini menggunakan model bernama sederhana. Sebut saja model nginx reverse-proxy 5 lapis, dan setiap konfigurasi yang berfungsi di bawah ini hanyalah lapisan-lapisan tersebut yang disusun berurutan:

• Listener. Direktif listen dan server_name menentukan request mana yang ditangani blok ini (port 80, port 443, hostname mana).
• Routing location. Blok location memisahkan path masuk sehingga /api/, /static/, dan / masing-masing dapat diarahkan ke tempat berbeda.
• Upstream. Blok upstream memberi nama pool server backend dan metode load balancing.
• Header. Baris proxy_set_header mempertahankan Host asli dan IP klien agar backend melihat request sebenarnya, bukan nginx.
• TLS. ssl_certificate pada listen 443 mengakhiri HTTPS di nginx sehingga backend dapat menggunakan HTTP biasa secara internal.

Jika Anda masih mempertimbangkan dua arah proxy, penjelasan kami tentang reverse proxy vs forward proxy membahas konsepnya secara lengkap. Artikel ini hanya membahas kasus reverse. Untuk setup outbound di sisi klien, lihat panduan pendamping nginx forward proxy.

Apa yang Anda perlukan sebelum memulai?

Anda memerlukan server Linux dengan nginx terpasang, setidaknya satu aplikasi backend yang mendengarkan pada port lokal, serta sertifikat TLS untuk HTTPS. Reverse proxying hanya menggunakan build nginx standar, jadi tidak diperlukan modul khusus atau kompilasi ulang.

Pastikan nginx tersedia dan konfigurasi Anda valid sebelum mengubah apa pun:

nginx -v
sudo nginx -t

Pengujian nginx -t mem-parsing seluruh konfigurasi dan melaporkan error sintaks dengan nama file dan nomor baris. Jalankan setelah setiap perubahan dalam tutorial ini, karena nginx akan menolak memuat ulang config yang rusak dan membiarkan config lama tetap berjalan. Letakkan server block reverse-proxy Anda di /etc/nginx/conf.d/ atau /etc/nginx/sites-available/ sesuai distribusi Anda, lalu muat ulang dengan sudo nginx -s reload setelah pengujian berhasil. Siapkan juga alamat backend, misalnya aplikasi Node atau Python pada 127.0.0.1:3000, karena itulah tujuan proxy_pass.

Bagaimana cara menyiapkan nginx reverse proxy langkah demi langkah?

Mulailah dengan satu server block yang mendengarkan di port 80, meneruskan setiap request ke satu backend melalui proxy_pass, dan menetapkan header yang diteruskan. Kemudian tambahkan load balancing, TLS, WebSockets, buffering, dan gzip. Blok pertama ini adalah setup nginx reverse proxy minimal yang berfungsi:

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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;
    }
}

Keempat baris proxy_set_header tersebut tidak opsional. Tanpanya, backend melihat nginx sebagai klien, mencatat IP yang salah, dan dapat membuat URL redirect yang rusak. Host mempertahankan hostname yang diminta, X-Real-IP dan X-Forwarded-For membawa alamat klien sebenarnya, sedangkan X-Forwarded-Proto memberi tahu aplikasi apakah request asli menggunakan HTTP atau HTTPS.

Tambahkan load balancing upstream. Untuk berada di depan beberapa instance backend, definisikan blok upstream dan arahkan proxy_pass ke namanya. Metode least_conn mengirim setiap request ke instance dengan koneksi aktif paling sedikit:

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 backup;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Server backup hanya menerima lalu lintas ketika server utama tidak aktif. Ganti dengan ip_hash, bukan least_conn, jika Anda membutuhkan klien yang sama tetap terhubung ke backend yang sama untuk sticky session.

Akhiri SSL di port 443. Reverse proxy produksi harus menyajikan HTTPS dan mengalihkan HTTP biasa. nginx menangani TLS agar backend Anda dapat tetap menggunakan HTTP biasa secara internal:

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

Dukung WebSockets. Koneksi WebSocket dimulai sebagai HTTP lalu melakukan upgrade, sehingga nginx perlu meneruskan header Upgrade dan Connection serta menggunakan HTTP/1.1. Berikan path real-time location sendiri:

location /ws/ {
    proxy_pass http://app_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;
    proxy_read_timeout 3600s;
}

proxy_read_timeout yang panjang menjaga socket idle agar tidak ditutup di tengah sesi, penyebab umum koneksi live terputus.

Sesuaikan buffering dan timeout. Nilai default bersifat konservatif; backend lambat mendapat manfaat dari nilai eksplisit agar nginx tidak menutup koneksi sebelum aplikasi merespons:

location / {
    proxy_pass http://app_backend;
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;
    proxy_buffering       on;
    proxy_buffers         16 16k;
    proxy_buffer_size     32k;
}

Aktifkan gzip. Mengompresi respons yang diproksikan mengurangi bandwidth untuk aset teks. Letakkan ini di blok http agar berlaku di seluruh situs:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 5;

Rutekan berdasarkan path. Satu reverse proxy dapat berada di depan beberapa layanan dengan mencocokkan prefix location yang berbeda ke upstream yang berbeda, serta menyajikan file statis langsung dari disk tanpa menyentuh backend:

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }

    location /static/ {
        root /var/www/assets;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

Bagaimana memverifikasi nginx reverse proxy berfungsi?

Muat ulang nginx, lalu kirim request ke hostname publik dan pastikan respons berasal dari backend Anda, bukan halaman nginx default. Uji config terlebih dahulu agar salah ketik tidak membuat situs web tidak dapat diakses:

sudo nginx -t && sudo nginx -s reload
curl -I http://app.example.com

200 atau redirect yang diharapkan dalam header respons berarti routing berfungsi. Untuk membuktikan backend menerima header yang diteruskan, periksa access log-nya atau endpoint echo dan pastikan backend melihat IP klien sebenarnya dari X-Forwarded-For, bukan 127.0.0.1. Anda juga dapat melewati DNS dan menargetkan proxy secara langsung sambil memalsukan hostname:

curl -H "Host: app.example.com" http://127.0.0.1

Untuk HTTPS, jalankan curl -I https://app.example.com dan pastikan sertifikat diterima serta request tidak diturunkan versinya. Jika backend merender link atau redirect dengan skema yang salah, hampir selalu penyebabnya adalah header X-Forwarded-Proto yang tidak ada, bukan masalah TLS.

Bagaimana menangani error 502 dan 504?

502 Bad Gateway berarti nginx mencapai upstream tetapi memperoleh respons tidak valid atau ditolak, sedangkan 504 Gateway Timeout berarti upstream menerima koneksi tetapi tidak menjawab tepat waktu. Keduanya adalah masalah upstream, bukan bug nginx, dan error log menyebutkan penyebab tepatnya. Pantau secara langsung saat Anda mereproduksi request:

sudo tail -f /var/log/nginx/error.log
# [error] connect() failed (111: Connection refused) while connecting to upstream

Periksa penyebab umum berikut secara berurutan:

• 502, connection refused. Backend tidak berjalan atau mendengarkan alamat atau port yang berbeda dari target proxy_pass. Konfirmasi dengan curl http://127.0.0.1:3000 pada server itu sendiri.
• 502, SELinux atau firewall. Pada sistem keluarga RHEL, SELinux memblokir nginx untuk membuka koneksi outbound sampai Anda menjalankan setsebool -P httpd_can_network_connect 1.
• 504, backend lambat. Aplikasi membutuhkan waktu lebih lama daripada proxy_read_timeout untuk merespons. Tingkatkan timeout untuk location tersebut atau perbaiki query yang lambat, alih-alih menutupinya secara global.
• 502, header besar. Backend yang mengirim header respons besar dapat melampaui buffer proxy. Tingkatkan proxy_buffer_size dan proxy_buffers.
• Upstream yang salah dipilih. Jika satu server dalam pool upstream tidak aktif, nginx menandainya tidak sehat dan mencoba server berikutnya, sehingga 502 yang muncul sesekali sering menunjukkan satu backend yang tidak sehat.

Reverse proxy mana yang sesuai, dan kapan Anda memerlukan proxy lain?

Gunakan nginx reverse proxy ketika Anda mengakhiri TLS, melakukan load balancing, atau merutekan path di depan server milik Anda sendiri; gunakan forward atau residential proxy ketika tugasnya adalah mengirim request outbound dari banyak IP. nginx sangat baik untuk tugas inbound dan tidak dirancang untuk tugas outbound. Berikut matriks keputusannya:

• Gunakan nginx reverse proxy ketika Anda meng-host backend, menginginkan satu endpoint HTTPS publik untuk beberapa layanan internal, membutuhkan load balancing antar-instance, atau menginginkan caching dan gzip di edge.
• Hindari nginx sebagai proxy Anda ketika tujuannya adalah request outbound yang harus terlihat berasal dari banyak IP atau negara berbeda, karena reverse proxy keluar dari satu IP server Anda dan tidak dapat melakukan rotating alamat.

Khusus di antara reverse proxy, nginx, Caddy, dan HAProxy memiliki trade-off yang berbeda:

Untuk otomatisasi outbound yang berat, panduan praktik terbaik web scraping kami membahas rotation dan kontrol rate, sedangkan datacenter proxies atau mobile proxies sesuai untuk tugas ketika biaya atau IP carrier lebih penting daripada kesetiaan residential.

Apa keterbatasan dan risiko nginx reverse proxy?

nginx reverse proxy sangat andal untuk lalu lintas inbound, tetapi memiliki batas nyata: tidak dapat melakukan rotating IP outbound, header yang salah konfigurasi dapat membocorkan atau menyembunyikan klien, dan menambahkan komponen operasional yang harus Anda patch serta pantau. Memahami hal ini membuat ekspektasi tetap realistis.

• Satu IP keluar. Setiap request outbound dari proxy keluar melalui IP server itu sendiri, sehingga reverse proxy tidak dapat membantu tugas yang membutuhkan banyak alamat sumber.
• Kesalahan header tidak terlihat. Lupa menyertakan X-Forwarded-For menyembunyikan IP klien sebenarnya dari aplikasi dan rate limiting Anda; lupa X-Forwarded-Proto merusak redirect HTTPS. nginx tidak akan memperingatkan Anda.
• Perawatan TLS dan sertifikat. Sertifikat kedaluwarsa, jadi Anda bertanggung jawab atas perpanjangan dan reload, biasanya melalui certbot dan cron job atau systemd timer.
• Titik kegagalan baru. Proxy kini berada di jalur kritis; jika tidak aktif, semua backend di belakangnya tidak dapat dijangkau, itulah sebabnya health check dan monitoring penting.
• Bukan tool anonimitas outbound. Reverse proxy tidak dibuat untuk menyamarkan asal request. Itu tugas forward proxy.

nginx bukan produk DataImpulse, dan DataImpulse tidak menjual scraping API terkelola atau web proxy gratis. Jalankan nginx sendiri ketika sesuai; ketika Anda memerlukan skala outbound, DataImpulse mendapatkan IP-nya sebagai ethical proxies dari pengguna yang setuju dan menerima kompensasi. Terakhir diperbarui: 2026-07-22.

Pertanyaan yang sering diajukan

Panduan terkait

• NGINX Forward Proxy
• Cloudflare Reverse Proxy
• Docker Reverse Proxy

Memerlukan IP outbound yang tidak dapat dirotasi nginx?

Reverse proxy menangani lalu lintas inbound, tetapi ketika tugas Anda membutuhkan request outbound dari banyak IP nyata, DataImpulse menambahkan lebih dari 90 juta IP rotating residential, mobile, dan datacenter di 195 negara, pay-as-you-go mulai satu dollar per GB dengan lalu lintas yang tidak kedaluwarsa. Buat akun untuk mendapatkan kredensial gateway dan merutekan klien Anda ke pool.