Connection lost en n8n: origen en el reverse proxy y WebSocket

Cuando la interfaz de n8n muestra "Connection lost", normalmente no se ve afectado el workflow en sí, sino la conexión WebSocket entre el navegador y el backend, que se interrumpe, por ejemplo, por un reverse proxy. Un workflow activo por lo general sigue ejecutándose, aunque la interfaz no lo muestre en un primer momento. Estado: agosto de 2026.

¿Cuál suele ser la causa?

Un vistazo a la comunidad de n8n muestra un patrón recurrente: la gran mayoría de los mensajes "Connection lost" afecta a instancias autoalojadas detrás de un reverse proxy, por ejemplo en despliegues en DigitalOcean, detrás de un Cloudflare Tunnel con Docker, detrás de Nginx con un puerto SSL no estándar, detrás de Apache o en entornos Kubernetes con un proxy Envoy. En varios de estos hilos, el mensaje se relaciona explícitamente con conexiones WebSocket reenviadas de forma incorrecta, en un caso concretamente como un error "Invalid Origin" a partir de n8n versión 1.87 detrás de un Cloudflare Tunnel. n8n en sí suele seguir funcionando, solo se interrumpe la visualización en directo en la interfaz.

¿Cómo se configura correctamente n8n detrás de un reverse proxy?

Según la documentación de n8n, el último proxy de la cadena debe reenviar correctamente los encabezados X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto, para que n8n interprete correctamente la solicitud original. Además, la variable N8N_PROXY_HOPS debe establecerse en 1 cuando hay exactamente un proxy delante de n8n. Si faltan estos encabezados o el número de proxy hops no es correcto, esto puede provocar exactamente las interrupciones de conexión que más se describen en la comunidad.

¿Qué papel desempeña N8N_WEBHOOK_URL?

Según la documentación, la URL de webhook debe establecerse manualmente mediante la variable de entorno N8N_WEBHOOK_URL, para que n8n la muestre correctamente en la interfaz del editor y la registre en servicios externos. La variante anterior WEBHOOK_URL sigue reconociéndose, pero genera una advertencia de obsolescencia. Esta variable afecta principalmente a los webhooks entrantes, pero forma parte de la misma configuración básica que los encabezados de proxy, por lo que a menudo se menciona junto con los problemas de conexión en los mismos hilos de la comunidad.

¿Cuándo ayuda cambiar a Server-Sent Events?

De forma predeterminada, según la documentación de n8n, n8n utiliza WebSockets para la comunicación en directo entre el backend y la interfaz, controlada mediante la variable N8N_PUSH_BACKEND con el valor predeterminado websocket. También se puede establecer el valor en sse, en cuyo caso se utilizan Server-Sent Events en lugar de WebSockets. Esto puede ayudar cuando un entorno de red, un proxy o un firewall dificulta o bloquea en general las conexiones WebSocket, mientras que las conexiones HTTP simples pasan sin problemas. Una prueba con sse es una de las medidas que se puede probar rápidamente sin grandes cambios de infraestructura, antes de profundizar en la configuración del proxy.

¿Cómo se procede de forma sistemática?

Es recomendable comprobar primero si el error se produce solo en la interfaz, mientras el workflow se completa correctamente en segundo plano, lo cual se puede verificar mediante la lista de ejecuciones. A continuación se revisan los tres encabezados Forwarded, así como N8N_PROXY_HOPS, luego se comprueba N8N_WEBHOOK_URL, y solo después se prueba con N8N_PUSH_BACKEND=sse. Quien opere n8n en el marco de una introducción a n8n debería documentar estos cuatro puntos directamente al configurar el reverse proxy, lo que ahorra una búsqueda de errores posterior bajo presión de tiempo.

Preguntas frecuentes sobre Connection lost en n8n

¿Se interrumpe el workflow cuando la interfaz muestra "Connection lost"?

Por lo general, no. El mensaje suele afectar solo a la conexión en directo entre el navegador y el backend de n8n; un workflow ya iniciado sigue ejecutándose en segundo plano y se puede verificar mediante la lista de ejecuciones.

¿Qué encabezados debe reenviar mi reverse proxy?

Según la documentación de n8n, como mínimo X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto. Además, N8N_PROXY_HOPS debe establecerse en el número real de proxies previos, normalmente 1.

¿Qué hace N8N_PUSH_BACKEND?

Esta variable determina si n8n utiliza WebSockets o Server-Sent Events para la actualización en directo de la interfaz. El valor predeterminado es websocket; en caso de problemas de conexión persistentes detrás de proxies o firewalls restrictivos, sse puede ser una alternativa funcional.

¿WEBHOOK_URL sigue siendo válida o tengo que cambiar?

WEBHOOK_URL sigue reconociéndose según la documentación, pero genera una advertencia de obsolescencia. La notación actual es N8N_WEBHOOK_URL; se recomienda cambiar para evitar futuros problemas de compatibilidad.