Invalid origin error on Azure Container Apps - N8N_DISABLE_ORIGIN_CHECK=true has no effect

Questions
1

Running n8n on Azure Container Apps (ACA) with HTTPS via ACA Ingress.
Getting “Invalid origin” error when trying to execute workflows manually.
N8N_DISABLE_ORIGIN_CHECK=true has no effect.
Origin is always “undefined” in logs.
Tested from external network (mobile data) - same issue.

Describe the problem/error/question

Running n8n 2.14.2 on Azure Container Apps (ACA) in Switzerland North. n8n is accessible via HTTPS through the ACA Ingress (Port 443 → internal 5678). When trying to manually execute a workflow in the editor, the connection drops immediately with “Lost connection to server”.
In the logs the following error appears repeatedly:
Origin header does NOT match the expected origin. (Origin: “undefined” → “N/A”, Expected: “undefined” → “undefined”, Protocol: “undefined”)
ResponseError: Invalid origin!
All recommended environment variables are set including N8N_DISABLE_ORIGIN_CHECK=true, N8N_TRUST_PROXY=true, N8N_PROXY_HOPS=1, N8N_EDITOR_BASE_URL, N8N_HOST, N8N_PROTOCOL=https, N8N_SECURE_COOKIE=false.
Tested from external network (mobile data, no corporate proxy) — same issue. So it is not a corporate proxy/firewall problem.
N8N_PUSH_BACKEND=sse and websocket both tested — same result.
n8n was previously running stable on Azure Container Instance (ACI) with direct port 5678. After migration to ACA the origin error appeared.

What is the error message (if any)?

Please share your workflow

Not applicable. The issue occurs before any workflow can be executed. 
The connection drops immediately when opening any workflow in the editor.

Share the output returned by the last node

Not applicable. No workflow execution reaches completion due to the connection drop.
Log output from Azure Container Apps:
Origin header does NOT match the expected origin. (Origin: “undefined” → “N/A”, Expected: “undefined” → “undefined”, Protocol: “undefined”)
ResponseError: Invalid origin!
at Push.handleRequest (/usr/local/lib/node_modules/n8n/src/push/index.ts:143:10)
at /usr/local/lib/node_modules/n8n/src/push/index.ts:99:10

Information on your n8n setup

2

welcome to the n8n community @glongo10
I’d treat this as a reverse-proxy/header issue in ACA, not an editor problem. n8n expects the last proxy to forward X-Forwarded-Host and X-Forwarded-Proto, and to use N8N_PROXY_HOPS=1 behind one proxy. WEBHOOK_URL is the key URL override behind a reverse proxy. I’d verify ACA is actually sending those headers; otherwise n8n can’t resolve the origin correctly.

3

yeah the “Expected: undefined” part is actually a second problem on top of the forwarded headers thing. even with N8N_ALLOWED_ORIGINS set, if ACA is stripping the Origin header entirely before it reaches n8n, theres nothing to match against. have you checked if the ACA ingress has CORS policy enabled at the ingress level? if it does, it handles Origin itself and strips it from the forwarded request, which would break n8n’s own origin check regardless of what env vars you set.

5

Checked ACA CORS settings — completely empty, no allowed origins configured. So ACA ingress is not handling CORS and not stripping the Origin header at that level.

The Origin header still arrives as undefined at n8n.

Could the ACA ingress strip headers by default even without CORS configured? Is there another way to verify which headers actually reach the n8n container?

6

@glongo10
I’d treat this as a header-forwarding issue, not CORS. ACA ingress can omit headers even with no CORS config. If X-Forwarded-Host or Origin are missing, n8n can’t reconstruct the expected origin and returns Invalid origin. To verify, I’d deploy an echo container like traefik/whoami or log req.headers inside the app and check host, x-forwarded-proto, x-forwarded-for, x-forwarded-host, and origin.

7

Found the issue. Deployed a whoami echo container on ACA — X-Forwarded-Proto is forwarded correctly, but X-Forwarded-Host and Origin headers are completely missing. ACA strips them by default. How can n8n work without X-Forwarded-Host?

8

Update: Unser Netzwerk Engineer hat bestätigt dass Origin by default weitergeleitet wird vom Corporate Proxy. Das fehlende Header ist also nur X-Forwarded-Host. Gibt es eine Möglichkeit n8n ohne X-Forwarded-Host zu konfigurieren, oder einen Workaround um den Origin Check zu umgehen wenn dieser Header fehlt?

9

@glongo10
I’m really happy to hear this helped :blush:
If this solution solved the issue for you, please consider leaving a like or marking the reply as the solution ( it helps others find the answer more easily and also supports community contributors.)