Connection lost dans n8n : origine côté reverse proxy et WebSocket

Lorsque l'interface n8n affiche "Connection lost", ce n'est généralement pas le workflow lui-même qui est concerné, mais la connexion WebSocket entre le navigateur et le backend, qui est interrompue par exemple par un reverse proxy. Un workflow actif continue en général de s'exécuter, même si l'interface ne l'affiche plus dans un premier temps. État : août 2026.

Quelle en est la cause la plus fréquente ?

Un coup d'œil dans la communauté n8n montre un schéma récurrent : la grande majorité des messages "Connection lost" concerne des instances auto-hébergées derrière un reverse proxy, par exemple des déploiements sur DigitalOcean, derrière un Cloudflare Tunnel avec Docker, derrière Nginx avec un port SSL non standard, derrière Apache ou dans des environnements Kubernetes avec un proxy Envoy. Dans plusieurs de ces fils, le message est explicitement associé à des connexions WebSocket mal transmises, dans un cas concrètement comme une erreur "Invalid Origin" à partir de n8n version 1.87 derrière un Cloudflare Tunnel. n8n lui-même continue généralement de fonctionner, seul l'affichage en direct dans l'interface s'interrompt.

Comment configurer correctement n8n derrière un reverse proxy ?

Selon la documentation n8n, le dernier proxy de la chaîne doit transmettre correctement les en-têtes X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Proto, afin que n8n interprète correctement la requête d'origine. La variable N8N_PROXY_HOPS doit en outre être définie sur 1 lorsqu'un seul proxy se trouve devant n8n. Si ces en-têtes sont absents ou si le nombre de proxy hops est incorrect, cela peut entraîner exactement les coupures de connexion le plus souvent décrites dans la communauté.

Quel rôle joue N8N_WEBHOOK_URL ?

Selon la documentation, l'URL de webhook doit être définie manuellement via la variable d'environnement N8N_WEBHOOK_URL, afin que n8n l'affiche correctement dans l'interface de l'éditeur et l'enregistre auprès des services externes. L'ancienne variante WEBHOOK_URL est certes encore reconnue, mais déclenche un avertissement de dépréciation. Cette variable concerne en premier lieu les webhooks entrants, mais elle fait partie de la même configuration de base que les en-têtes de proxy, et c'est pourquoi elle est souvent mentionnée avec les problèmes de connexion dans les mêmes fils de la communauté.

Quand le passage aux Server-Sent Events aide-t-il ?

Par défaut, selon la documentation n8n, n8n utilise des WebSockets pour la communication en direct entre le backend et l'interface, contrôlée via la variable N8N_PUSH_BACKEND dont la valeur par défaut est websocket. Il est possible de définir la valeur sur sse, auquel cas des Server-Sent Events sont utilisés à la place des WebSockets. Cela peut aider lorsqu'un environnement réseau, un proxy ou un pare-feu gêne ou bloque en général les connexions WebSocket, alors que de simples connexions HTTP passent sans problème. Un test avec sse est l'une des mesures qui peut être essayée rapidement sans modification majeure de l'infrastructure, avant d'approfondir la configuration du proxy.

Comment procéder de façon systématique ?

Il est judicieux de vérifier d'abord si l'erreur se produit uniquement dans l'interface, alors que le workflow s'exécute avec succès en arrière-plan, ce qui peut être vérifié via la liste des exécutions. Vient ensuite le contrôle des trois en-têtes Forwarded ainsi que de N8N_PROXY_HOPS, puis la vérification de N8N_WEBHOOK_URL, et ce n'est qu'après cela qu'il faut essayer N8N_PUSH_BACKEND=sse. Quiconque exploite n8n dans le cadre d'une introduction à n8n devrait documenter ces quatre points directement lors de la mise en place du reverse proxy, ce qui évite une recherche d'erreur ultérieure sous pression du temps.

Questions fréquentes sur Connection lost dans n8n

Le workflow s'interrompt-il lorsque l'interface affiche "Connection lost" ?

En général, non. Le message concerne le plus souvent uniquement la connexion en direct entre le navigateur et le backend n8n ; un workflow déjà démarré continue de s'exécuter en arrière-plan et peut être vérifié via la liste des exécutions.

Quels en-têtes mon reverse proxy doit-il transmettre ?

Selon la documentation n8n, ce sont au minimum X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Proto. La variable N8N_PROXY_HOPS doit en outre être définie sur le nombre réel de proxies en amont, généralement 1.

Que fait N8N_PUSH_BACKEND ?

Cette variable détermine si n8n utilise des WebSockets ou des Server-Sent Events pour la mise à jour en direct de l'interface. La valeur par défaut est websocket ; en cas de problèmes de connexion persistants derrière des proxys ou des pare-feux restrictifs, sse peut être une alternative fonctionnelle.

WEBHOOK_URL est-elle encore valable ou dois-je changer ?

WEBHOOK_URL est encore reconnue selon la documentation, mais déclenche un avertissement de dépréciation. La notation actuelle est N8N_WEBHOOK_URL ; il est recommandé de changer pour éviter de futurs problèmes de compatibilité.