Solved: 'Connection lost' / 'Invalid origin!' Error with n8n >= 1.87.0 behind Cloudflare Tunnel

Tips & Tricks
1

Hi everyone,

I’m posting this here to help other community members who might run into the same issue: After updating to n8n v1.87.x (v1.88.0 in my case), I constantly experienced the ‘Connection lost’ error in the UI, accompanied by ResponseError: Invalid origin! in the n8n container’s Docker logs.

My Setup:

  • Self-hosted n8n via Docker (using multiple workers in queue mode)
  • External access via a Cloudflare Tunnel (Cloudflared)

Problem Description: The UI constantly lost connection to the backend, severely impacting usability. The error started occurring after n8n v1.87 introduced stricter security checks for push endpoints (SSE/WebSockets) (see PR #14365).

Attempted Solutions (Without Success): I checked the usual configurations for running behind a reverse proxy and made sure they were correct:

  • N8N_HOST=n8n.example.com (hostname only)
  • N8N_PROTOCOL=https
  • WEBHOOK_URL=https://n8n.example.com
  • N8N_TRUST_PROXY='172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8' (Example covering common private/Docker ranges; more specific ranges might be needed depending on your setup)
  • Ensured the ‘HTTP Host Header’ override field in the Cloudflare Tunnel settings was empty.

Despite these correct settings, the Invalid origin! error persisted.

Diagnosis (The Cause): The crucial clue came from the Cloudflare Tunnel’s Live Logs. For requests to the /rest/push endpoint, the logs showed that the Origin header was being sent to n8n without the scheme:

JSON"Origin": [ "n8n.example.com" ]

However, based on the configuration (N8N_PROTOCOL + N8N_HOST), n8n expects the value https://n8n.example.com. Since the values didn’t match exactly, the security check failed.

The Solution: The solution was to instruct Cloudflare to explicitly set the Origin header to the correct value before the request reaches your tunnel and thus n8n. This was achieved using a Cloudflare Transform Rule:

  1. In the Cloudflare Dashboard, navigate to your domain → Rules → Transform Rules.
  2. Create a “Modify Request Header” rule.
  3. Filter: Hostname equals n8n.example.com
  4. Modification: Set static Header Origin to https://n8n.example.com
  5. Deploy the rule.

After this rule was active, the Origin header was correctly transmitted to n8n, and the Invalid origin! error, along with the ‘Connection lost’ message, disappeared immediately.

I hope this helps others who encounter a similar issue when running n8n behind a Cloudflare Tunnel!

Best regards
Florian

TL;DR: If you get the ‘Invalid origin!’ error after updating to n8n >= 1.87.0 while using a Cloudflare Tunnel: Create a Cloudflare Transform Rule (Modify Request Header) for your n8n hostname that statically sets the Origin header to your full HTTPS URL (e.g., https://n8n.example.com).

4 Likes
2

Same here, after updating to the latest version of n8n, I am experiencing a WebSocket connection lost error. Switching to SSE results in an “Internal Server Error”, with logs showing “Invalid origin” in docker logs

Do you have any idea how to fix this with Nginx as a reverse proxy?

3

Hi @h40huynh

I think this would be a great question for a friendly AI

Reg,
J.

4

I am having same issue, where I deployed n8n on AWS fargate, and fargate is behind an application load balancer, then the load balancer is behind a CloudFront distribution. If I access n8n from ip for fargate or ALB, it works. If I access from CloudFront distribution it start showing “invalid origin!”.

The code source causing this seems to be here.

I have tried every setup I can think of for CloudFront and nothing seems to work.

UPDATE:
I added edge lambda to make sure the origin and host headers match (with origin having https://) , not sure how this can be fixed

5

in your n8n section of your nginx config, just put a line, i.e.

proxy_set_header Origin 'https://yourdomain.com';

Just ran into this problem and it appears to fix it. ymmv etc.

2 Likes
6

I ran n8n on my PC within my home network behind a Verizon router.

When I tried setting up NGINX for SSL, I encountered an issue where proxy_set_header Origin $http_origin; did not work.

I had to hardcode the domain name in the NGINX configuration to resolve the problem.
below is my location config for nginx

    location / {
        proxy_pass http://host.docker.internal:5678;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Upgrade $http_upgrade;     
        #proxy_set_header Origin $http_origin;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Origin 'https://mydomain.ddns.net';
    }
7

THis worked for me: Connection lost after upgrade to 1.88.0 · Issue #14653 · n8n-io/n8n · GitHub

1 Like
8

Thank you kindly :+1: worked for me.

9

if you are using apache or litespeed you can add this lines

#Proxy all requests to internal Docker host
RewriteRule ^(.*)$ http://127.0.0.1:5678/$1 [P,L]

#Set necessary headers
<IfModule mod_headers.c>
	RequestHeader set Host "your.n8n.domain"
	RequestHeader set X-Real-IP %{REMOTE_ADDR}e
	RequestHeader set Origin "https://your.n8n.domain"
	RequestHeader set Connection "upgrade"
	RequestHeader set Upgrade %{HTTP:Upgrade}e
</IfModule>

#Enable required proxy features
<IfModule mod_proxy.c>
	ProxyPreserveHost On
	ProxyRequests Off
</IfModule>

changing your.n8n.domain for your n8n’s url

10

I have a similar setup, but not using the Cloudflare Tunnel, just the Cloudflare proxy on my n8n subdomain (the orange cloud).
I use Traefik v3 as the reverse proxy. I run on docker.

Here is how I fixed the issue in my setup:
Add the following traefik labels (adapt to your setup) to the main n8n instance:

- "traefik.http.middlewares.websocket-headers.headers.customrequestheaders.Origin=wss://n8n.example.com"
- "traefik.http.routers.my-n8n.middlewares=websocket-headers"
3 Likes
11

This solved my issue. Thank you

12

I came to the same conclusion as @mavios and hit the same wall, and found the same code causing it, but no resolution provided resolves it from this thread.

Still an open issue with all kinda of back and forth:

13

This worked fine for me, make sure to use the unique name for middleware router for the instance