Proksi untuk n8n: pengaturan HTTP Request tanpa 403 (2026)

Anda telah mengumpulkan workflow di n8n, itu berfungsi selama dua minggu, dan kemudian mulai jatuh secara konsisten dengan 403 Forbidden. Pikiran pertama adalah "situsnya rusak" atau "kredensialnya kadaluarsa". Namun, seringkali masalahnya berbeda: server target mengetahui bahwa permintaan datang bukan dari browser, tetapi dari otomatisasi yang berjalan dengan IP pusat data VPS Anda. n8n memiliki mekanisme proxy bawaan — hanya saja tidak diaktifkan secara default, dan beberapa pengaturan berada di tempat yang tidak terduga.

Kita akan membahas langkah demi langkah: di mana tepatnya proxy diatur di n8n, perbedaan antara self-hosted dan Cloud, serta tiga jebakan yang paling banyak memakan waktu.

Kenapa n8n lebih sering diblokir dibandingkan browser Anda

n8n adalah platform otomatisasi open-source terbesar: hampir 198 ribu bintang dan 59,6 ribu fork di GitHub, rilis terkini pada saat publikasi adalah [email protected] (24 Juli 2026). Popularitas memiliki sisi negatif: sistem anti-bot sangat mengenali jejak jaringan-nya.

Terdapat tiga faktor yang berkontribusi:

User-Agent mengungkapkan identitas Anda dengan cepat. Ini bukan dugaan, tetapi perilaku yang terdokumentasi secara resmi. Di n8n terdapat variabel N8N_ENFORCE_GLOBAL_USER_AGENT (secara default false), dan dokumentasi secara langsung menjelaskan tujuannya: mengganti string User-Agent n8n yang "telanjang" dengan yang kompatibel RFC Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/), untuk mencegah pemblokiran permintaan oleh firewall aplikasi web. Masalah ini sampai menjadi laporan bug: di issue #28280 (dibuka 10 April 2026, ditutup) dijelaskan bagaimana node asli memberikan bare-UA n8n, dan situs-situs merespons dengan 403 dengan alasan "Bad User-Agent". Node HTTP Request itu sendiri di bawah kapot menggunakan axios dan tanpa header manual mudah dikenali.
IP server Anda adalah dari pusat data. n8n hampir selalu berjalan di VPS atau di cloud. Rentang ini dikenal secara publik dan ditandai sebagai "bukan pengguna": beberapa platform memotongnya lebih ketat, hingga batas permintaan yang jauh lebih rendah dibandingkan dengan koneksi rumah.
Kecepatan permintaan tidak manusiawi. Node dalam siklus mengeluarkan puluhan permintaan per detik dari satu alamat — ini adalah pemicu klasik rate-limit dan pemblokiran IP selanjutnya.

Langkah 1. Proxy di dalam node itu sendiri (bekerja juga di Cloud)

Cara tercepat adalah mengatur proxy secara spesifik untuk satu HTTP Request:

Buka node HTTP Request.
Di bagian bawah, klik Add Option dan pilih Proxy — ini adalah kolom teks untuk URL proxy server.
Masukkan string dalam format standar dengan otorisasi: http://LOGIN:PASSWORD@host:port.
Di sana juga tambahkan opsi header: aktifkan Send Headers dan atur User-Agent dari browser nyata — salin string yang relevan dari DevTools Chrome Anda secara manual.

Cara ini adalah satu-satunya yang tersedia di n8n Cloud: di sana Anda tidak mengelola lingkungan eksekusi, sehingga variabel lingkungan sistem tidak tersedia untuk Anda, dan IP keluar tidak tetap dan berubah dari satu eksekusi ke eksekusi lainnya. Keuntungan dari pendekatan ini adalah granularitas: node yang berbeda dalam satu workflow dapat menggunakan proxy dan geo yang berbeda. Kerugian — jika ada dua puluh node, Anda harus mengedit dua puluh tempat.

Langkah 2. Proxy global melalui variabel lingkungan (self-hosted)

Di server Anda, lebih logis untuk membungkus semua lalu lintas keluar sekaligus. n8n membaca variabel standar:

HTTP_PROXY — URL proxy untuk lalu lintas HTTP yang tidak terenkripsi dari node;
HTTPS_PROXY — sama untuk permintaan TLS/SSL (dalam praktiknya ini adalah parameter utama Anda);
ALL_PROXY — digunakan ketika tidak ada HTTP_PROXY/HTTPS_PROXY yang lebih spesifik yang ditetapkan;
NO_PROXY — daftar host yang dipisahkan koma, yang akan diakses n8n secara langsung tanpa melalui proxy.

Di docker-compose.yml ini terlihat seperti ini:

HTTPS_PROXY=http://LOGIN:[email protected]:8080
NO_PROXY=localhost,127.0.0.1,postgres,n8n.example.com
N8N_ENFORCE_GLOBAL_USER_AGENT=true

Pastikan untuk mengisi NO_PROXY. Jika tidak, permintaan internal juga akan melalui proxy eksternal — ke Postgres Anda, ke kontainer tetangga, ke domain webhook Anda sendiri. Gejala — "semua rusak setelah mengaktifkan proxy", meskipun situs target justru mulai terbuka.

Jika Anda ingin tidak mengungkapkan versi n8n ke luar, alih-alih string RFC, tetapkan milik Anda melalui N8N_GLOBAL_USER_AGENT_VALUE — ini akan menimpa nilai default. Logika umum untuk mengatur lalu lintas kontainer sama dengan skenario lainnya: analisis format dan jebakan ada dalam panduan tentang proksi untuk kontainer Docker.

Langkah 3. Tiga jebakan yang mencuri waktu malam Anda

Jebakan 1: pendaftaran variabel menentukan

Ini tidak jelas dan hampir tidak pernah muncul di tutorial. n8n memproses variabel yang diakhiri dengan _PROXY melalui paket npm proxy-from-env, dan itu memaksakan urutan prioritasnya sendiri: varian huruf kecil (http_proxy) memiliki prioritas lebih tinggi daripada huruf besar (HTTP_PROXY), jika keduanya ditetapkan. Skenario klasik yang menyakitkan: di sistem sudah ada https_proxy yang terlupakan, Anda dengan hati-hati menulis HTTPS_PROXY di compose — dan lalu lintas tetap berjalan di alamat lama. Periksa kedua pendaftaran.

Detail terpisah untuk Enterprise: variabel proxy untuk permintaan ke server lisensi https_proxy_license_server harus hanya dalam huruf kecil, formatnya adalah https://user:pass@proxy:port.

Jebakan 2: Code node tidak dapat melakukan apa yang Anda rencanakan

Saran umum dari forum — "tulis permintaan Anda di Code node melalui axios dengan agen proxy". Secara default ini tidak akan berhasil: n8n menonaktifkan impor modul di Code node. Anda harus mengizinkannya secara eksplisit — NODE_FUNCTION_ALLOW_BUILTIN untuk yang bawaan dan NODE_FUNCTION_ALLOW_EXTERNAL untuk yang eksternal (dari n8n/node_modules). Nuansa tambahan: jika Anda memiliki task runners dalam mode eksternal, variabel ini ditetapkan bukan di lingkungan kontainer, tetapi di konfigurasi runner /etc/n8n-task-runners.json sebagai env-override. Lebih mudah dan lebih aman untuk tetap menggunakan opsi Proxy bawaan di node.

Jebakan 3: proxy ada, tetapi kecepatan tetap sama

Proxy mengubah alamat, tetapi tidak perilaku. Jika workflow masih mengeluarkan serangkaian permintaan, Anda hanya akan membakar IP baru. Di node yang sama terdapat pengatur kecepatan bawaan:

Batching — Items per Batch (jumlah item dalam satu batch) dan Batch Interval dalam milidetik (0 = tanpa jeda). Atur batch 1–5 dan interval 1000–3000 ms.
Timeout — dalam milidetik; saluran residensial lebih lambat daripada saluran pusat data, defaultnya harus ditingkatkan.
Response → Never Error — tidak menjatuhkan seluruh workflow pada 403 pertama, memungkinkan untuk memproses kode respons dengan percabangan.
Pagination — mode Update a Parameter dan Response Contains Next URL sebagai pengganti siklus buatan sendiri.

Di tingkat instance, kecepatan dibatasi oleh N8N_CONCURRENCY_PRODUCTION_LIMIT (secara default -1, yaitu tanpa batas) — nilai yang masuk akal akan melindungi baik kolam proxy maupun server itu sendiri. Lebih lanjut tentang bagaimana platform menghitung permintaan Anda dan apa yang harus dilakukan dengan batasan, ada dalam analisis menghindari rate limiting melalui proxy.

Proxy apa yang harus digunakan untuk n8n

Pemilihan tidak tergantung pada "keren" atau tidak, tetapi pada siapa yang berada di ujung lainnya.

Pusat data. Murah dan cepat. Cocok untuk API resmi, layanan internal, situs yang ramah terhadap bot, dan tugas apa pun yang hanya memerlukan alamat statis yang stabil — misalnya, agar IP Anda dimasukkan dalam daftar putih mitra. Di platform yang aman, mereka memberikan 403 yang sama seperti VPS telanjang: rentang mereka dikenal. Ini adalah dasar untuk tugas paket tanpa anti-bot.
Residen. Alamat dari penyedia rumah nyata — yang diperlukan untuk pengumpulan data dari situs dengan perlindungan serius, untuk konten yang bergantung pada geo dan pemantauan harga. Untuk workflow yang mengakses situs publik, proxy residensial adalah default yang bekerja: ambil rotasi per permintaan untuk pengambilan massal dan sesi lengket, ketika perlu mempertahankan satu sesi di rantai node.
Mobile. Tingkat kepercayaan tertinggi: di belakang satu operator terdapat ribuan pelanggan nyata, memblokir IP seperti itu mahal bagi platform. Diperlukan di tempat-tempat yang paling ketat — bekerja dengan media sosial dan aplikasi pesan. Untuk ini, Anda membayar dengan kecepatan dan harga.

Skema praktis untuk workflow campuran: API resmi — langsung atau melalui pusat data, situs publik — melalui proxy residensial, media sosial — melalui proxy mobile. Opsi Proxy diatur di setiap node secara terpisah, sehingga menggabungkan semua ini dalam satu skenario dapat dilakukan tanpa masalah.

Checklist sebelum peluncuran

Proxy telah ditetapkan — baik sebagai opsi Proxy di node, atau melalui HTTPS_PROXY; di Cloud hanya opsi pertama yang tersedia.
Kedua pendaftaran variabel telah diperiksa — huruf kecil menimpa huruf besar.
NO_PROXY menutup localhost, database, dan host internal.
User-Agent telah diganti: N8N_ENFORCE_GLOBAL_USER_AGENT=true atau header kustom di node. Juga periksa konsistensi header lainnya — set header yang tidak konsisten dapat mengungkapkan otomatisasi tidak lebih baik daripada User-Agent itu sendiri.
Batching diaktifkan dengan interval yang tidak nol.
Pengujian dilakukan pada 3–5 item, bukan pada seluruh daftar.

Kesimpulan

403 di n8n hampir selalu bukan satu penyebab, tetapi kombinasi dari tiga: User-Agent yang dapat dikenali, IP pusat data, dan kecepatan permintaan yang terlalu konsisten. Ini juga diatasi dengan paket, bukan hanya satu centang: mengganti UA, mengalihkan lalu lintas melalui proxy yang tepat, dan memperlambat node melalui Batching. Ketiga penggerak ini sudah terintegrasi dalam platform — cukup temukan dan aktifkan.

Mulailah dengan saluran residensial di node yang paling bermasalah dan pusat data di yang lainnya: pembayaran di ProxyCove dihitung berdasarkan lalu lintas, jadi untuk pengujian Anda bisa mengambil volume minimum dan melihat bagaimana workflow spesifik Anda berperilaku. Menemukan proxy untuk tugas dan memasukkan string di kolom Proxy — hanya butuh beberapa menit.