"Connection lost" - Can't save workflows

[JoeyFenny]

Describe the bug
A clear and concise description of what the bug is.
Says connection lost even though loading any other page works and I'm connected to the internet and it appears my instance is also connected. Possibly a docker issue? Running as a one-click-app via CapRover

To Reproduce
deploy n8nio/n8n:latest (1.1.0) on CapRover

Expected behavior
Is not complaining about connectivity issues. Connects successfully.

Environment (please complete the following information):

• OS: [e.g. Ubuntu Linux 22.04]
• n8n Version [e.g. 1.1.0]
• Node.js Version [e.g. 18.16.0]
• Database system [e.g. SQLite; n8n uses SQLite as default otherwise changed]
• Operation mode [e.g. own; operation modes are own, main and queue. Default is main]
  All of those example values match. I have not changed anything.

Additional context
Possible issue with how CapRover is running it rather than with n8n directly, but unsure.

[Joffcom]

Hey @JoeyFenny,

That looks like maybe your reverse proxy is not configured to support websockets. Has the CapRover reverse proxy got web sockets enabled?

[netroy]

I believe CapRover lets you enable Websocket support in the http config for your app.
Can you please try enabling that flag ?

[netroy]

@JoeyFenny does this solve the issue for you?

[dannyeuu]

@netroy we started to facing this problem today in kubernetes environment, our image tag has in n8n:latest

[netroy]

@dannyeuu what are you using for ingress ? not all ingress controllers support websockets out-of-the-box.

[Igcorreia]

This happens occasionally; some versions of n8n work, and some won't. In the past, I found a solution:
#3469 (comment)
Now, it doesn't work again. I had to change from Websocket to SSE, and it was fixed.
I am still fighting to find the reason why this happened, but I can't seem to.

[Joffcom]

Hey @Igcorreia,

The default now is websocket this was a change introduced into 1.0 and should help resolve a lot of the issues around SSE.

The previous option you linked to was to allow SSE to work nicely with nginx which you can also find further up in the same post.

To get nginx working with websockets it should be a case of adding the 3 options below

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

So a full config could look something like...

server {
  listen 443 ssl;
  server_name n8n.my_domain.tld;
  location / {
    proxy_pass http://127.0.0.1:5678;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Upgrade $http_upgrade;
    proxy_http_version 1.1;
  }
  ssl_certificate # removed
  ssl_certificate_key # removed
}

[Igcorreia]

@Joffcom, finally, I figured it out. The example code was what unblocked me. It works, but I had to manually change the Nginx settings in a Plesk server. I am actually going to try this with another application and report it back to Plesk.

[dannyeuu]

@netroy the problem was with nginx, too. Migrating to SSE, the problem solved.

[netroy]

@dannyeuu n8n is migrating away from SSE. That's what we used prior to 1.x.
Please node that SSE support is deprecated, and will be removed in a future release.
Please look at the comment from @Joffcom on how to get nginx to work with Websockets.

[luizeof]

helo @netroy @Joffcom

If it helps in your research I have noticed the following:

• When I'm using N8N through Cloudflare's proxy, as soon as the proxy is turned on, the connection with the socket lasts around 60 seconds and then the connection is "restarted".
• By turning off the cloudflare proxy, the connection is established and the workflow stays open for as long as it takes.

You can verify this behavior through the /push endpoint.

[Igcorreia]

@luizeof I also have to remove the proxy for N8N to work. :/

[Joffcom]

Hey @luizeof,

That sounds like there may be an additional configuration issue required if you are using a Cloudflare proxy and don't want it to reconnect, Cloudflare do also document that if Cloudflare push any code changes it will also restart websockets although it shouldn't cause any issues if they are reconnecting.

The issue in this post is for when n8n does nothing but show connection lost which indicates that websockets are not allowed at all.

To save on further confusion on this topic I am going to close this issue, If anyone in the future has an issue with the websockets or sees the connection lost message feel free to open a post on the support forum as this issue is more likely to be with the configuration of systems outside of n8n than n8n itself.

[luizeof]

@Joffcom thanks for your reply ;)

from what i found cloudflare actually closes connections if there is no activity. In this post people recommend doing a type of ping to avoid this.

Could the N8N make this tweak in doing a ping/heartbeat through the websocket to avoid this disconnect?

Cloudflare is very popular among users and this will generate a lot of questions.

https://stackoverflow.com/questions/39668410/whats-disconnecting-my-websocket-connection-cloudflare-apaches-mod-proxy

[netroy]

@luizeof can you please check if this PR fixes the issue for you

[Joffcom]

@luizeof Coudflare document that they close the connection after around 100 seconds, This is however not the same as the original raised here and I would rather try to keep things on topic as much as possible so we don't mix feature requests in with configuration issues.

As a general rule feature requests like this one should be opened on our support forum as well which is the preferred location for any support queries or feature requests.

[adamshand]

In case it's helpful to anyone else who has problems with CapRover. Ticking "Websocket support" under "HTTP Settings" solves the "Connection lost" problem.

[romainframe]

This might help someone. I just ran into this problem with n8n deployed on a kubernetes cluster behind a nginx-ingress.
The following annotation on my n8n ingress solved it for me. I didn't use any other nginx annotation.

nginx.org/websocket-services: "n8n-svc"

Found solution here.