Self Host N8N Connection Lost Google Cloud Project

Questions
,
1

I just updated N8N to the latest version as I did multiple times before but now it prompts me with connection is lost (see image below)

image
image1177Ă—253 31.3 KB

I stopped and restarted the VM already but still prompts me with the same error. I had this before a while back on another account which I couldnt solve either. Does anyone know what I can do to fix that - like narrow down the problem?

Installed and followed the guided in this repo: GitHub - JimPresting/n8n-gcp-selfhost: Guide on how to fully self-host n8n in a GCP project with up to no monthly costs (depending on the workflows you might pay networking costs, see: [GCP Network Pricing](https://cloud.google.com/vpc/network-pricing)) as well as auto-update the Docker image whenever the open-source GitHub repo of n8n has another release.

Thanks in advance!

Information on your n8n setup

  • n8n version: 1.88
  • Database (default: SQLite): SQLite
  • n8n EXECUTIONS_PROCESS setting (default: own, main): own
  • Running n8n via (Docker, npm, n8n cloud, desktop app): GCP
  • Operating system: Windows 10
2

Hi,

You should lookup on how the configure nginx as reverse proxy for websocket. There are many questions and solutions for this already

Reg
J.

1 Like
3

Hi @jcuypers ,

where can I look this up?

4

Hi friend, I understand this problem exists:

  1. What’s going on?
    Starting with v1.87/1.88, n8n changed the way it validates the Origin of the WebSocket used by the interface.

If the proxy (NGINX / Cloud Run LB / Cloudflare Tunnel, etc.) doesn’t forward the Host and Origin headers as is or fills them with the $host variable, n8n returns Invalid origin! and the browser displays the “Connection lost” message.

GitHub

For some users, the update also changed the default value of the push channel to SSE, which in many configurations loses the connection as soon as there are intermediate proxies.

So the temporary solution is to revert to version 1.86.1.

You can do this without losing your flows with these simple steps:

1
docker pull docker.n8n.io/n8nio/n8n:1.86.1

2
docker stop n8n

3
docker rm n8n

4
docker run -d --restart unless-stopped
–name n8n
-p 5678:5678
-e N8N_HOST=“n8n.yourdomain.com”
-e WEBHOOK_TUNNEL_URL="

https://n8n.yourdomain.com/

"
-e WEBHOOK_URL="

https://n8n.yourdomain.com/

"
-v n8n_data:/home/node/.n8n
n8nio/n8n:1.86.1

5

@Daniel_Suarez

I did it with these settings and it worked.

server {
    server_name your-subdomain.your-domain.com;
    location / {
        proxy_pass http://localhost:5678;
        proxy_http_version 1.1;
        chunked_transfer_encoding off;
        proxy_buffering off;
        proxy_cache off;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_read_timeout 86400;
    }
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/your-subdomain.your-domain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/your-subdomain.your-domain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
    if ($host = your-subdomain.your-domain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
    listen 80;
    server_name your-subdomain.your-domain.com;
    return 404; # managed by Certbot
}