n8n için proxy: 403 olmadan HTTP Request ayarı (2026)

n8n' de bir iş akışı oluşturdunuz, iki hafta boyunca çalıştı, ardından 403 Forbidden hatası vermeye başladı. İlk düşünce "site bozuldu" veya "kimlik bilgileri geçersiz" olur. Çoğu zaman sorun farklıdır: hedef sunucu, isteğin bir tarayıcıdan değil, VPS'nizin veri merkezi IP'sinden çalışan bir otomasyondan geldiğini anlamıştır. n8n'in yerleşik bir proxy mekanizması vardır - ancak varsayılan olarak etkin değildir ve bazı ayarlar, arandığı yerden farklı bir yerde bulunur.

Adım adım inceleyelim: n8n' de proxy'nin nerede ayarlandığı, self-hosted ile Cloud arasındaki farklar ve en çok zaman kaybına neden olan üç tuzak.

n8n neden tarayıcınızdan daha sık engelleniyor

n8n, en büyük açık kaynak otomasyon platformudur: GitHub'da neredeyse 198 bin yıldız ve 59,6 bin fork, yayınlandığı tarihteki güncel sürüm ise [email protected] (24 Temmuz 2026). Popülerliğin bir ters tarafı vardır: anti-bot sistemleri onun ağ imzasını iyi bilir.

Üç faktör bir araya gelir:

User-Agent anında ifşa eder. Bu bir tahmin değil, resmi olarak belgelenmiş bir davranıştır. n8n' de N8N_ENFORCE_GLOBAL_USER_AGENT adlı bir değişken vardır (varsayılan olarak false) ve belgeler, amacını açıkça tanımlar: "çıplak" User-Agent n8n dizesini RFC uyumlu Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/) ile değiştirmek, web uygulamalarının güvenlik duvarları tarafından isteklerin engellenmesini önlemek için. Sorun, hata raporlarına kadar ulaştı: #28280 (10 Nisan 2026'da açıldı, kapatıldı) sayfasında, yerel düğümlerin bare-UA n8n döndürdüğünü ve sitelerin "Bad User-Agent" nedeni ile 403 ile yanıt verdiğini anlatıyor. HTTP Request düğümü, arka planda axios kullanır ve manuel başlık olmadan kolayca tanınır.
Sunucunuzun IP'si veri merkezi IP'sidir. n8n neredeyse her zaman VPS veya bulutta çalışır. Bu aralıklar kamuya açık olarak bilinir ve "kullanıcı olmayan" olarak işaretlenmiştir: bazı platformlar, ev bağlantılarına göre çok daha düşük istek limitleri ile bunları daha sert bir şekilde kesmektedir.
İstek hızı insani değil. Bir düğüm, bir adres üzerinden saniyede onlarca istek gönderir - bu, klasik bir rate-limit tetikleyicisi ve ardından IP'nin yasaklanmasıdır.

Adım 1. Düğümde proxy ayarı (Cloud'da da çalışır)

En hızlı yol, bir HTTP Request için proxy'yi belirli bir şekilde ayarlamaktır:

HTTP Request düğümünü açın.
Aşağıda Add Option butonuna tıklayın ve Proxy seçeneğini seçin - bu, proxy sunucusunun URL'si için bir metin alanıdır.
Standart formatta kimlik doğrulama ile dizeyi yazın: http://KULLANICI_ADI:ŞİFRE@host:port.
Aynı yerde başlık seçeneklerini ekleyin: Send Headers'ı etkinleştirin ve gerçek bir tarayıcının User-Agent değerini belirleyin - Chrome'unuzun Geliştirici Araçları'ndan geçerli dizeyi manuel olarak kopyalayın.

Bu yöntem, n8n Cloud için mevcut olan tek yöntemdir: orada çalışma ortamını yönetemezsiniz, bu nedenle sistem ortam değişkenlerine erişiminiz yoktur ve giden IP, her başlatmada değişir. Bu yaklaşımın artısı, granülaritedir: aynı iş akışındaki farklı düğümler, farklı proxy'ler ve farklı coğrafi konumlar üzerinden çalışabilir. Eksi tarafı ise, yirmi düğüm varsa yirmi yeri düzenlemeniz gerekecektir.

Adım 2. Ortak proxy ayarı (self-hosted)

Kendi sunucunuzda, tüm giden trafiği bir seferde yönlendirmek daha mantıklıdır. n8n, standart değişkenleri okur:

HTTP_PROXY - düğümlerin şifrelenmemiş HTTP trafiği için proxy URL'si;
HTTPS_PROXY - TLS/SSL istekleri için aynı (pratikte bu sizin ana parametrenizdir);
ALL_PROXY - daha spesifik HTTP_PROXY/HTTPS_PROXY tanımlanmadığında kullanılır;
NO_PROXY - n8n'in proxy'yi atlayarak doğrudan gideceği, virgülle ayrılmış ana bilgisayarlar listesi.

docker-compose.yml dosyasında bu şu şekilde görünür:

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

Mutlaka NO_PROXY değerini doldurun. Aksi takdirde, dış proxy üzerinden iç başvurular da gidecektir - Postgres'inize, komşu konteynerlere, kendi webhook alanınıza. Belirti - "proxy'yi etkinleştirdikten sonra her şey bozuldu", oysa hedef siteler açılmaya başladı.

n8n'in sürümünü dışarıya ifşa etmemek istiyorsanız, RFC dizesi yerine kendi dize değerini N8N_GLOBAL_USER_AGENT_VALUE ile ayarlayın - bu varsayılan değeri geçersiz kılar. Konteyner trafiği ayarlarının genel mantığı, diğer senaryolarla aynıdır: formatları ve tuzakları incelemek için Docker konteynerleri için proxy ayarları kılavuzuna bakabilirsiniz.

Adım 3. Üç tuzak, akşamı çalan

Tuzak 1: Değişkenlerin kaydı belirleyici

Bu, belirgin değildir ve hemen hemen hiçbir yerde eğitimlerde bulunmaz. n8n, _PROXY ile biten değişkenleri proxy-from-env npm paketi aracılığıyla işler ve bu da kendi öncelik sırasını dayatır: küçük harfli versiyonlar (http_proxy) büyük harfli olanlardan (HTTP_PROXY) daha önceliklidir, her ikisi de tanımlandığında. Klasik bir acı senaryosu: sistemde uzun zamandır unutulmuş bir https_proxy var, dikkatlice HTTPS_PROXY değerini compose dosyasına yazıyorsunuz - ve trafik inatla eski adrese gidiyor. Her iki kaydı da kontrol edin.

Enterprise için ayrı bir detay: lisans sunucusuna yapılan istekler için proxy değişkeni https_proxy_license_server yalnızca küçük harfli olmalıdır, format - https://user:pass@proxy:port.

Tuzak 2: Code düğümü düşündüğünüzü yapamaz

Forumlardan sıkça gelen bir öneri - "Code düğümünde isteğinizi axios ile proxy ajanı kullanarak yazın". Varsayılan olarak bu çalışmaz: n8n, Code düğümünde modül ithalatını devre dışı bırakır. Onları açıkça izin vermeniz gerekir - NODE_FUNCTION_ALLOW_BUILTIN yerleşik olanlar için ve NODE_FUNCTION_ALLOW_EXTERNAL dış olanlar için (n8n/node_modules içinden). Ek bir detay: eğer dış modda görev çalıştırıcılarınız varsa, bu değişkenler konteyner ortamında değil, görev çalıştırıcıların konfigürasyonunda /etc/n8n-task-runners.json dosyasında env-override olarak tanımlanır. Daha kolay ve güvenli olanı, düğümdeki varsayılan Proxy seçeneğinde kalmaktır.

Tuzak 3: Proxy var, ama hız aynı

Proxy adresi değiştirir, ancak davranışı değiştirmez. Eğer iş akışı hala bir dizi istek gönderiyorsa, yeni IP'leri yakarsınız. Aynı düğümde yerleşik yavaşlatıcılar vardır:

Batching - Items per Batch (paketteki öğe sayısı) ve Batch Interval milisaniye cinsinden (0 = duraksız). Paket sayısını 1-5 ve aralığı 1000-3000 ms olarak ayarlayın.
Timeout - milisaniye cinsinden; yerleşik kanallar veri merkezi kanallarından daha yavaştır, varsayılan değeri artırmak gerekir.
Response → Never Error - ilk 403'te tüm iş akışını düşürmez, yanıt kodunu dallanarak işleme almanıza olanak tanır.
Pagination - Update a Parameter ve Response Contains Next URL modları, kendi döngüleriniz yerine.

Örnek düzeyinde hız, N8N_CONCURRENCY_PRODUCTION_LIMIT ile sınırlıdır (varsayılan olarak -1, yani sınırsız) - makul bir değer, hem proxy havuzunu hem de sunucuyu korur. İsteklerinizi nasıl hesapladıkları ve limitlerle ne yapacağınız hakkında daha fazla bilgi için rate limiting'i proxy aracılığıyla aşma incelemesine bakabilirsiniz.

n8n için hangi proxy'leri almalı

Seçim "havalı" olmaktan değil, diğer tarafta kimin olduğundan etkilenir.

Veri merkezi proxy'leri. Ucuz ve hızlı. Resmi API'ler, iç hizmetler, bot dostu siteler ve sadece kararlı bir statik adrese ihtiyaç duyulan her türlü görev için uygundur - örneğin, IP'nizin bir partnerin beyaz listesine alınması için. Güvenli sitelerde de tam olarak aynı 403 hatasını alırsınız: bu aralıklar bilinir. Bu, anti-bot olmayan toplu görevler için bir temeldir.
İkametgah proxy'leri. Gerçek ev sağlayıcılarının adresleri - ciddi koruma gerektiren sitelerden veri toplamak, coğrafi olarak bağımlı içerik ve fiyat izleme için gereklidir. Kamu sitelerinde dolaşan iş akışları için ikametgah proxy'leri - çalışır varsayılan: toplu veri çekimi için talep başına döngü almayı ve düğüm zincirinde bir oturumu tutmak gerektiğinde yapışkan oturumları tercih edin.
Mobil proxy'ler. En yüksek güven düzeyi: bir operatörün arkasında binlerce canlı abone bulunur, böyle bir IP'yi yasaklamak siteye pahalıya mal olur. En sert kısıtlamaların olduğu yerlerde geçerlidir - sosyal medya ve mesajlaşma uygulamaları ile çalışmak için. Bunun için hız ve maliyetle ödüyorsunuz.

Karışık bir iş akışında pratik bir şema: resmi API'ler - doğrudan veya veri merkezi proxy'leri aracılığıyla, kamu siteleri - ikametgah proxy'leri aracılığıyla, sosyal medya - mobil proxy'ler aracılığıyla. Proxy seçeneği her düğümde ayrı ayrı ayarlanabilir, bu nedenle bunları tek bir senaryoda bir araya getirmek için ek bir çaba gerektirmez.

Başlatmadan önce kontrol listesi

Proxy ayarlandı - ya düğümdeki Proxy seçeneği ile ya da HTTPS_PROXY aracılığıyla; Cloud'da yalnızca birinci seçenek mevcuttur.
Her iki değişken kaydının kontrol edildiğinden emin olun - küçük harfler büyük harfleri geçersiz kılar.
NO_PROXY localhost, veritabanı ve iç ana bilgisayarları kapatır.
User-Agent değiştirildi: N8N_ENFORCE_GLOBAL_USER_AGENT=true veya düğümde kendi başlığınız. Diğer başlıkların tutarlılığını kontrol edin - tutarsız bir başlık seti, otomasyonu User-Agent'tan daha iyi ifşa eder.
Batching, sıfırdan farklı bir aralık ile etkinleştirildi.
Test sürüşü, tüm liste yerine 3-5 öğe ile yapıldı.

Sonuç

n8n' deki 403 hatası genellikle tek bir neden değil, üç nedenin toplamıdır: tanınabilir User-Agent, veri merkezi IP'si ve çok düzgün istek hızı. Bu, tek bir onay kutusu ile değil, bir dizi ayar ile çözülür: UA'yı değiştirmek, trafiği uygun türde bir proxy üzerinden yönlendirmek ve düğümü Batching ile yavaşlatmak. Bu üç etken, platforma zaten entegre edilmiştir - yeter ki bulup etkinleştirin.

En kolay başlangıç, en sorunlu düğümler için ikametgah kanalı ve diğerleri için veri merkezi kullanmaktır: ProxyCove'da ödeme, trafiğe göre yapılır, bu nedenle testler için minimum miktarı alabilir ve belirli iş akışınızın nasıl davranacağını görebilirsiniz. Göreve uygun proxy'yi seçmek ve Proxy alanına dizeyi yerleştirmek birkaç dakikanızı alır.