n8n'de Connection lost: Reverse proxy ve WebSocket kaynaklı neden

n8n arayüzü "Connection lost" mesajı verdiğinde, genellikle workflow'un kendisi değil, tarayıcı ile backend arasındaki, örneğin bir reverse proxy tarafından kesilen WebSocket bağlantısı etkilenir. Aktif bir workflow bu sırada genellikle çalışmaya devam eder, arayüz bunu ilk anda göstermese bile. Durum: Ağustos 2026.

Genellikle neden kaynaklanır?

n8n topluluğuna bir bakış tekrarlayan bir örüntü gösteriyor: "Connection lost" mesajlarının büyük çoğunluğu, örneğin DigitalOcean üzerindeki deployment'larda, Docker ile bir Cloudflare Tunnel arkasında, standart olmayan SSL portuna sahip Nginx arkasında, Apache arkasında veya Envoy proxy'li Kubernetes ortamlarında, bir reverse proxy arkasındaki kendi barındırılan (self-hosted) örnekleri etkiliyor. Bu thread'lerin birçoğunda mesaj açıkça hatalı yönlendirilmiş WebSocket bağlantılarıyla ilişkilendiriliyor, bir durumda ise somut olarak bir Cloudflare Tunnel arkasında n8n sürüm 1.87'den itibaren "Invalid Origin" hatası olarak. n8n'in kendisi bu sırada genellikle çalışmaya devam eder, sadece arayüzdeki canlı görüntü kesilir.

n8n bir reverse proxy arkasında nasıl doğru yapılandırılır?

n8n dokümantasyonuna göre, n8n'in orijinal isteği doğru yorumlayabilmesi için zincirdeki son proxy'nin X-Forwarded-For, X-Forwarded-Host ve X-Forwarded-Proto başlıklarını doğru şekilde iletmesi gerekir. Ayrıca, n8n'in önünde tam olarak bir proxy varsa N8N_PROXY_HOPS değişkeni 1 olarak ayarlanmalıdır. Bu başlıklar eksikse veya proxy hop sayısı doğru değilse, bu durum toplulukta en sık tarif edilen bağlantı kesilmelerine yol açabilir.

N8N_WEBHOOK_URL nasıl bir rol oynar?

Dokümantasyona göre webhook URL'si, n8n'in bunu editör arayüzünde doğru şekilde göstermesi ve harici hizmetlere kaydetmesi için N8N_WEBHOOK_URL ortam değişkeni üzerinden manuel olarak ayarlanmalıdır. Daha eski WEBHOOK_URL varyantı hâlâ tanınmaya devam etse de, bir deprecation uyarısı tetikler. Bu değişken öncelikle gelen webhook'ları ilgilendirir, ancak proxy başlıklarıyla aynı temel yapılandırmanın bir parçasıdır ve bu nedenle aynı topluluk thread'lerinde bağlantı sorunlarıyla birlikte sıkça anılır.

Server-Sent Events'e geçiş ne zaman yardımcı olur?

n8n dokümantasyonuna göre, n8n varsayılan olarak backend ile arayüz arasındaki canlı iletişim için, varsayılan değeri websocket olan N8N_PUSH_BACKEND değişkeni ile kontrol edilen WebSocket'leri kullanır. Alternatif olarak değer sse olarak ayarlanabilir, bu durumda WebSocket yerine Server-Sent Events kullanılır. Bu, bir ağ ortamı, proxy veya güvenlik duvarı WebSocket bağlantılarını genel olarak zorlaştırıyor veya engelliyorken basit HTTP bağlantılarının sorunsuz geçtiği durumlarda yardımcı olabilir. sse ile bir test, proxy yapılandırmasına daha derinlemesine girmeden önce büyük bir altyapı değişikliği yapmadan hızlıca denenebilecek önlemlerden biridir.

Sistematik olarak nasıl ilerlenir?

Öncelikle hatanın yalnızca arayüzde mi ortaya çıktığını, workflow'un arka planda başarıyla tamamlanıp tamamlanmadığını kontrol etmek mantıklıdır; bu, execution listesi üzerinden takip edilebilir. Ardından üç Forwarded başlığının ve N8N_PROXY_HOPS'un kontrolü, sonra N8N_WEBHOOK_URL'nin kontrolü ve ancak bundan sonra N8N_PUSH_BACKEND=sse denemesi gelir. n8n'i bir n8n girişi kapsamında işletenler, bu dört noktayı reverse proxy kurulumu sırasında doğrudan belgelemelidir, bu da zaman baskısı altında sonradan hata aramaktan kurtarır.

n8n'de Connection lost hakkında sık sorulan sorular

Arayüz "Connection lost" gösterdiğinde workflow durur mu?

Genellikle hayır. Mesaj genellikle yalnızca tarayıcı ile n8n backend'i arasındaki canlı bağlantıyı etkiler; zaten başlamış olan bir workflow arka planda çalışmaya devam eder ve execution listesi üzerinden takip edilebilir.

Reverse proxy'imin hangi başlıkları iletmesi gerekir?

n8n dokümantasyonuna göre bunlar en az X-Forwarded-For, X-Forwarded-Host ve X-Forwarded-Proto'dur. Ayrıca N8N_PROXY_HOPS, önündeki gerçek proxy sayısına, genellikle 1'e ayarlanmalıdır.

N8N_PUSH_BACKEND ne işe yarar?

Bu değişken, n8n'in arayüzün canlı güncellenmesi için WebSocket mi yoksa Server-Sent Events mi kullanacağını belirler. Varsayılan değer websocket'tir; kısıtlayıcı proxy'ler veya güvenlik duvarları arkasında ısrarcı bağlantı sorunlarında sse işlevsel bir alternatif olabilir.

WEBHOOK_URL hâlâ geçerli mi yoksa değiştirmem mi gerekiyor?

WEBHOOK_URL, dokümantasyona göre hâlâ tanınmaya devam ediyor, ancak bir deprecation uyarısı tetikliyor. Güncel yazım şekli N8N_WEBHOOK_URL'dir; gelecekteki uyumluluk sorunlarını önlemek için değiştirmek önerilir.