Rehber · Güncelleme 2026-11-10
n8n Proxy Ayarı: HTTP Request Düğümünde Rotating Proxy
n8n proxy ayarı adım adım: HTTP Request düğümünün Proxy seçeneği, kimlikli adres biçimi, ifadeyle oturum kimliği, Batching, Timeout, Retry On Fail ve sık hatalar.

n8n proxy ayarı nereye yazılır: düğüm seçeneği mi, ortam değişkeni mi?
n8n proxy ayarı iki yerden yapılabilir ve ikisi aynı anda tanımlıysa düğümdeki kazanır. Birinci yer HTTP Request düğümünün kendi seçeneğidir: düğümü açıp Add Option listesinden Proxy’yi seçersiniz, karşınıza tek satırlık bir adres alanı çıkar. İkinci yer kendi sunucunuzda çalışan n8n’in ortam değişkenleridir: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY ve bu üçünün dışında tutulacak adresleri listeleyen NO_PROXY. n8n belgeleri düğümdeki Proxy alanının bu değişkenlere göre öncelikli olduğunu açıkça yazar; bütün kurulum bir kurumsal proxy’den çıkıyor olsa bile tek bir düğümü rotating gateway’e yönlendirebilirsiniz.
Hangisini seçeceğiniz işin şekline bağlıdır. Ortam değişkeni bütün düğümleri etkiler: Slack bildirimi, Google Sheets yazımı ve veritabanı sorgusu dahil her dış bağlantı aynı gateway’den geçer ve hepsi GB sayacını tüketir. Rotating proxy yalnız hedef siteye giden isteklerde gerekir, bu yüzden pratik olan düğüm seçeneğidir: scraping yapan bir ya da birkaç HTTP Request düğümünde Proxy alanı dolu olur, geri kalan düğümler kendi bağlantılarıyla çalışır. Ortam değişkenlerinin genel kullanımı ayrı bir konudur; bu rehber yalnız n8n’e özgü öncelik kuralını anlatır.
Bir ayrıntı daha var: n8n ortam değişkenlerini proxy-from-env paketiyle okur ve belgelerde küçük harfli http_proxy değişkeninin büyük harfli HTTP_PROXY’ye göre öncelikli olduğu yazar. Sunucuda iki yazım birden tanımlıysa ve düğümde Proxy alanı boşsa, hangi adresin kullanıldığını tahmin etmek yerine aşağıdaki IP testini yapın.
Kurulum ve ilk test: adres biçimi ve çıkış IP’sinin doğrulanması
Proxy alanına yazılacak adres tek parçadır: http://kullanici:sifre@host:port. Panelden aldığınız kullanıcı adı, şifre, gateway adresi ve port bu kalıba yerleşir. Şemayı yazmak zorunludur. n8n topluluk forumundaki bir başlıkta kullanıcı adresi kullanici:sifre@host:port biçiminde, başında http:// olmadan girmiş, curl ile aynı proxy çalışırken düğüm her seferinde kendi sunucusunun IP’sini döndürmüştü; http:// eklenince sorun kapandı. Alan hata vermez, yalnız proxy’siz gider. Bu yüzden ilk test isteğin gerçekten proxy’den çıkıp çıkmadığını ölçmelidir.
Test akışı üç düğümden oluşur. Manual Trigger ile başlayın, HTTP Request düğümüne istemci IP’sini düz metin döndüren bir adres yazın ve Proxy alanını doldurun. Düğümü tek başına çalıştırıp çıktıya bakın: dönen adres sunucunuzun adresiyse proxy devreye girmemiştir, farklı bir adresse gateway çalışıyordur. Aynı düğümü dört beş kez art arda çalıştırın; adres her seferinde değişiyorsa istek başına rotasyon açıktır, aynı kalıyorsa kullanıcı adında bir oturum eki vardır ya da ürün oturum modundadır. Hangi davranışın beklenmesi gerektiği gateway mantığı rehberinde anlatılır.
Şifreyi düğüme açık yazmak kalıcı bir çözüm sayılmaz; akışı dışa aktardığınızda ya da ekiple paylaştığınızda şifre JSON’un içinde gider. Proxy alanı ifade (expression) kabul eder: alanı ifade moduna alıp adresi parçalardan kurabilirsiniz. Kendi sunucunuzda şifreyi bir ortam değişkeninde tutup ifadeyle okumak yaygın yoldur; bazı kurulumlarda düğümlerden ortam değişkenine erişim yönetici tarafından kapatılmış olabilir, önce kendi sürümünüzde deneyin. Akışı paylaşmadan önce dışa aktarılan dosyada şifreyi arayın.
Gateway’in kabul ettiği protokol ürüne göre değişmez: RotatingProxy kataloğundaki ürünlerin hepsi HTTP, HTTPS ve SOCKS5 bağlantı kabul eder. n8n’in Proxy alanına HTTP şemalı adres yazmak yeterlidir; HTTPS hedeflere giden istekler proxy’ye CONNECT ile tünel açar ve hedefle TLS el sıkışması tünelin içinde yapılır. Ignore SSL Issues seçeneğinin bu tünelle ilgisi yoktur; hedefin sertifikası geçersizse yanıtı yine de indirmek için kullanılır ve gateway sorunlarını gizlemek için açılmamalıdır.
Her istekte yeni IP mi, aynı oturum mu: ifadeyle oturum parametresi
Rotating gateway iki modda çalışır: her istekte yeni çıkış adresi ya da bir oturum kimliği boyunca aynı adres. Oturum kimliği kullanıcı adına eklenir ve sözdizimi panelde tanımlıdır. n8n tarafında bunun karşılığı, Proxy alanını ifade moduna alıp kullanıcı adını akıştaki bir değerden kurmaktır. Bir ürün listesini tarayan akışta her öğe için farklı bir oturum kimliği üretirseniz her sayfa farklı IP’den çıkar; sayfalama yapan bir istek dizisinde oturum kimliğini sabit tutarsanız sayfa 1’den sayfa 20’ye kadar bütün istekler aynı IP’de kalır.
Sayfalama n8n’de düğümün kendi Pagination seçeneğiyle yapılır; Pagination Mode alanında Off dışında iki seçenek vardır: Update a Parameter in Each Request ve Response Contains Next URL. Bu seçenek açıkken düğüm aynı çalıştırmada art arda birçok istek atar ve hepsi Proxy alanındaki adresi kullanır. Hedef site sayfalama arasında oturum çerezi ya da sıralama anahtarı tutuyorsa IP’nin sayfadan sayfaya değişmesi sonuçları bozabilir; bu tür hedeflerde oturum ekli adres kullanın. Sayfalar birbirinden bağımsızsa istek başına rotasyon daha ucuz ve daha dayanıklıdır. Hangi aralığın hangi işe uyduğu rotasyon aralığı rehberinde ayrıntılı anlatılır.
Oturum kimliğini üretmek için ayrı bir düğüm gerekmez. Edit Fields (Set) düğümünde her öğeye bir alan ekleyip bu alanı ifadeyle Proxy adresine katmak yeterlidir. Kimliğin tekrar etmemesi önemlidir: akış her tetiklendiğinde aynı kimlik üretilirse gateway her çalıştırmada aynı çıkış adresini verebilir. Çalıştırma kimliğini ya da zaman damgasını kimliğin bir parçası yapmak bu tekrarı önler.
Çok öğeli akışlarda hız: Batching, Timeout ve yeniden deneme
HTTP Request düğümü girişine gelen her öğe için bir istek atar; 500 ürün adresi içeren bir liste 500 istek demektir ve varsayılan davranış hepsini mümkün olduğunca hızlı göndermektir. Hızı düğümün Batching seçeneği düzenler. Items per Batch kaç öğenin bir grupta gönderileceğini, Batch Interval iki grup arasında milisaniye cinsinden ne kadar bekleneceğini belirler; sıfır değeri bekleme yok demektir. 500 adresi 10’arlık gruplar hâlinde ve gruplar arasında 2.000 ms bekleyerek göndermek, aynı listeyi tek seferde boşaltmaktan çok daha az 429 üretir.
Timeout seçeneği milisaniye cinsindendir ve belgelerde yalnız yanıt başlıklarının gelmesine kadar geçen süreyi sınırladığı yazar; gövdenin indirilmesi bu süreye dahil değildir. Rotating gateway üzerinden giden isteklerde gecikme, doğrudan bağlantıya göre bir tünel kurulumu kadar fazladır; zaman aşımını çok kısa tutmak sağlıklı istekleri de keser. Hedefin normal yanıt süresinin birkaç katı makul bir başlangıçtır; gerçek değeri ilk çalıştırmanın çıktısındaki sürelerden alın.
Yeniden deneme düğümün ayarlar sekmesinde yapılır. Retry On Fail açıkken başarısız düğüm, belgelerin ifadesiyle, başarana kadar yeniden çalışır; deneme sayısı ve denemeler arası bekleme aynı panelde ayarlanır. Aynı sekmedeki On Error seçeneği hatanın akışı nasıl etkileyeceğini belirler: Stop Workflow akışı durdurur, Continue hatayı yok sayıp son geçerli veriyle devam eder, Continue (using error output) hata bilgisini ayrı bir çıkıştan sonraki düğüme aktarır. Scraping akışlarında üçüncü seçenek en kullanışlısıdır: başarısız adresler ayrı bir dala düşer, orada bekleyip yeniden kuyruğa alınır ya da bir tabloya yazılır.
429 yanıtı geldiğinde Retry On Fail’in aynı tempoda tekrar etmesi işe yaramaz; hedef hız sınırı koymuştur ve aynı tempoda gelen tekrar aynı cevabı alır. Doğru tepki Batch Interval’ı artırmak ya da Items per Batch’i düşürmektir; yeniden deneme yalnız geçici ağ hatalarında anlamlıdır. Response seçeneğindeki Include Response Headers and Status, durum kodunu ve Retry-After başlığını akışa sokar; Never Error ise 4xx ve 5xx yanıtlarında düğümün hata vermemesini sağlar ve kodu kendi IF düğümünüzle ayırmanıza izin verir. 429’un hangi durumda rotasyonla, hangi durumda tempoyla çözüleceği 429 rehberinde ele alınır.
Sık hatalar: gerçek IP dönüyor, tünel hatası, Cloud farkı
Gerçek IP’nin dönmesi en sık görülen durumdur ve üç nedeni vardır. Birincisi adres biçimi: şema yok, kullanıcı adında ya da şifrede kaçırılmamış @ veya : karakteri var, ya da alanın başında boşluk kalmış. İkincisi ifade hatası: Proxy alanı ifade modundayken ifade boş dize üretiyorsa düğüm proxy’siz çalışır; çalıştırma çıktısında alanın çözümlenmiş değerine bakın. Üçüncüsü yanlış düğüm: Proxy seçeneği düğüm başınadır, akıştaki ikinci HTTP Request düğümü ayarı miras almaz. Düğümü kopyalayarak çoğaltmak seçeneği taşır, sıfırdan eklemek taşımaz.
Tünel hatası (CONNECT reddi, 407 ya da bağlantı kesilmesi) genellikle kimlik bilgisiyle ilgilidir: şifre yanlış, hesap kotası bitmiş ya da panelde IP izni gerektiren bir ayar açıkken n8n sunucusunun adresi listede değil. Gateway tarafındaki 407 ve rotasyon hatalarının ayrımı bağlantı sorunları rehberinde adım adım verilir. n8n tarafında hatayı görünür kılmak için On Error’ı Continue (using error output) yapıp hata dalına bir Edit Fields düğümü bağlayın; hata mesajı ve durum kodu orada okunur.
n8n Cloud ile kendi sunucunuz arasındaki fark ortam değişkenlerindedir. Cloud’da HTTP_PROXY gibi değişkenleri siz ayarlayamazsınız; proxy yalnız düğümün Proxy seçeneğiyle verilir ve belgelerde bu seçenek için Cloud’a özgü bir kısıt yazmaz. Yine de ilk IP testini Cloud’daki akışın içinde yapın; dışa giden bağlantıların nasıl çıktığı sizin kontrolünüzde değildir. Kendi sunucunuzda ise konteynerin dışa açık olduğunu ve NO_PROXY listesinin gateway adresini kapsamadığını doğrulayın.
Topluluk düğümleri de vardır: proxy desteğini genişletmeyi amaçlayan n8n-nodes-httpsoverproxy gibi paketler npm’de bulunur. Bu rehberdeki ayarlar yalnız çekirdek HTTP Request düğümüyle yapılır; topluluk düğümü kurmak ayrı bir bakım yükü getirir ve Cloud’da her zaman mümkün olmaz. Çekirdek düğüm yetmediğinde eksik olan çoğu zaman tarayıcıdır.
HTTP Request yetmediğinde: tarayıcı gereken işler
HTTP Request düğümü sayfanın HTML’ini olduğu gibi alır; JavaScript çalıştırmaz. Fiyatı sayfa yüklendikten sonra bir API çağrısıyla dolduran siteler, sonsuz kaydırmayla listelenen ürünler ve giriş sonrası görünen paneller bu düğümle eksik gelir. İlk kontrol basittir: HTML düğümüyle aradığınız alanı seçemiyorsanız ve ham yanıtta değer yoksa, sayfa tarayıcıda oluşuyor demektir. Çoğu zaman tarayıcıya gerek kalmaz: tarayıcının ağ sekmesinde sayfanın çağırdığı JSON uç noktasını bulup onu HTTP Request ile doğrudan çekmek hem daha hızlı hem daha az GB tüketir.
Tarayıcı gerçekten gerekiyorsa n8n bunu kendi başına yapmaz; Playwright gibi bir aracı ayrı bir serviste çalıştırıp n8n’den Execute Command ya da bir webhook ile tetiklemek gerekir. Proxy ayarı bu durumda n8n’de değil tarayıcı tarafında yapılır; bağlam başına proxy, kimlik doğrulama ve rotasyonun tarayıcıyla nasıl kurulduğu Scrapy ve Playwright rehberinde anlatılır. n8n yalnız zamanlama, kuyruk ve sonuçların yazılacağı yer olarak kalır.
Fiyat izleme gibi düzenli aralıklarla çalışan işlerde bu bölünme iyi çalışır: Schedule Trigger akışı başlatır, bir tablo ya da veritabanından adres listesi okunur, HTTP Request düğümü Batching ile tempolu şekilde sayfaları çeker, HTML düğümü fiyatı ayıklar, karşılaştırma yapılıp değişenler bildirilir. GB bazlı ürünlerde her çalıştırmanın maliyeti yanıt boyutuyla orantılıdır; yalnız gereken sayfaları çekmek ve JSON uç noktası varsa HTML yerine onu kullanmak kotayı doğrudan korur.
Sık sorulan sorular
n8n HTTP Request düğümünde proxy nereye yazılır? Düğümün alt kısmındaki Add Option listesinden Proxy seçilir ve açılan alana http://kullanici:sifre@host:port biçiminde tam adres yazılır. Alan düğüm başınadır; her HTTP Request düğümüne ayrıca eklenir.
Düğümdeki Proxy ile HTTP_PROXY değişkeni birlikte tanımlıysa hangisi geçerli? Düğümdeki. n8n belgeleri Proxy seçeneğinin HTTP_PROXY, HTTPS_PROXY ve ALL_PROXY değişkenlerine göre öncelikli olduğunu yazar. Alan boşsa ortam değişkeni kullanılır.
n8n’de her istekte farklı IP nasıl alınır? Gateway istek başına rotasyon modundaysa tek adresle her istek farklı adresten çıkar. Oturum modundaysa Proxy alanını ifade moduna alıp kullanıcı adındaki oturum kimliğini her öğe için farklı üretin; aynı kimlik aynı IP, farklı kimlik farklı IP verir.
n8n Cloud’da rotating proxy kullanılabilir mi? Düğümün Proxy seçeneği Cloud’da da vardır ve belgelerde bu seçenek için Cloud’a özgü bir kısıt yazmaz. Ortam değişkeni ayarlayamayacağınız için proxy yalnız düğüm seçeneğiyle verilir; ilk IP testini mutlaka Cloud’daki akışta yapın.
Proxy tanımlı ama n8n hâlâ kendi IP’sini gösteriyorsa ne kontrol edilmeli? Sırayla: adresin başında http:// var mı, şifredeki özel karakterler kaçırılmış mı, alan ifade modundaysa çözümlenmiş değer boş mu, test ettiğiniz düğüm Proxy seçeneği eklenen düğüm mü. Dördü de temizse gateway tarafına geçin ve aynı adresi curl ile deneyin.
