Connection lost в n8n: причина в reverse proxy и WebSocket

Когда интерфейс n8n сообщает "Connection lost", обычно затронут не сам workflow, а WebSocket-соединение между браузером и backend, которое прерывается, например, из-за reverse proxy. Активный workflow при этом, как правило, продолжает выполняться, даже если интерфейс в первый момент этого не показывает. По состоянию на: август 2026.

В чём чаще всего причина?

Взгляд на сообщество n8n показывает повторяющуюся закономерность: подавляющее большинство сообщений "Connection lost" касается самостоятельно размещённых (self-hosted) инстансов за reverse proxy, например при развёртывании на DigitalOcean, за Cloudflare Tunnel с Docker, за Nginx с нестандартным SSL-портом, за Apache или в средах Kubernetes с Envoy-proxy. В нескольких из этих тем сообщение прямо связывается с некорректно перенаправляемыми WebSocket-соединениями, в одном случае конкретно как ошибка "Invalid Origin" начиная с версии n8n 1.87 за Cloudflare Tunnel. Сам n8n при этом обычно продолжает работать, обрывается только отображение в реальном времени в интерфейсе.

Как правильно настроить n8n за reverse proxy?

Согласно документации n8n, последний proxy в цепочке должен корректно передавать заголовки X-Forwarded-For, X-Forwarded-Host и X-Forwarded-Proto, чтобы n8n правильно интерпретировал исходный запрос. Кроме того, переменную N8N_PROXY_HOPS следует установить в 1, если перед n8n находится ровно один proxy. Если эти заголовки отсутствуют или количество proxy hops указано неверно, это может приводить именно к тем обрывам соединения, которые чаще всего описываются в сообществе.

Какую роль играет N8N_WEBHOOK_URL?

Согласно документации, URL webhook должен задаваться вручную через переменную окружения N8N_WEBHOOK_URL, чтобы n8n корректно отображал его в интерфейсе редактора и регистрировал во внешних сервисах. Более старый вариант WEBHOOK_URL по-прежнему распознаётся, но вызывает предупреждение об устаревании (deprecation). Эта переменная в первую очередь касается входящих webhook, но она относится к той же базовой конфигурации, что и заголовки proxy, поэтому в тех же темах сообщества её часто упоминают вместе с проблемами соединения.

Когда помогает переход на Server-Sent Events?

По умолчанию, согласно документации n8n, n8n использует WebSocket для живой связи между backend и интерфейсом, что регулируется переменной N8N_PUSH_BACKEND со значением по умолчанию websocket. Альтернативно значение можно установить в sse, тогда вместо WebSocket используются Server-Sent Events. Это может помочь, если сетевое окружение, proxy или firewall в целом затрудняют или блокируют WebSocket-соединения, тогда как простые HTTP-соединения проходят без проблем. Тест со значением sse — одна из мер, которую можно быстро опробовать без серьёзных изменений инфраструктуры, прежде чем углубляться в настройку proxy.

Как действовать системно?

Разумно сначала проверить, возникает ли ошибка только в интерфейсе, в то время как workflow успешно завершается в фоновом режиме, что можно проследить по списку выполнений. Затем следует проверка трёх заголовков Forwarded, а также N8N_PROXY_HOPS, далее проверка N8N_WEBHOOK_URL, и только после этого попытка с N8N_PUSH_BACKEND=sse. Тому, кто использует n8n в рамках введения в n8n, стоит задокументировать эти четыре пункта сразу при настройке reverse proxy — это избавит от поиска ошибок позже, под давлением времени.

Часто задаваемые вопросы о Connection lost в n8n

Прерывается ли workflow, когда интерфейс показывает "Connection lost"?

Как правило, нет. Сообщение обычно касается только живого соединения между браузером и backend n8n; уже запущенный workflow продолжает выполняться в фоновом режиме, и это можно проследить по списку выполнений.

Какие заголовки должен передавать мой reverse proxy?

Согласно документации n8n, это как минимум X-Forwarded-For, X-Forwarded-Host и X-Forwarded-Proto. Кроме того, N8N_PROXY_HOPS следует установить в фактическое количество предшествующих proxy, обычно 1.

Что делает N8N_PUSH_BACKEND?

Эта переменная определяет, использует ли n8n WebSocket или Server-Sent Events для живого обновления интерфейса. Значение по умолчанию — websocket; при устойчивых проблемах с соединением за ограничивающими proxy или firewall рабочей альтернативой может стать sse.

Действителен ли ещё WEBHOOK_URL или нужно переходить на новый?

WEBHOOK_URL, согласно документации, по-прежнему распознаётся, но вызывает предупреждение об устаревании. Актуальное написание — N8N_WEBHOOK_URL; переход рекомендуется, чтобы избежать проблем совместимости в будущем.