“Connection lost” error in self-hosted n8n behind ALB + NGINX reverse proxy on version v1.99.1

[ProductVartopia]

Bug Description

I’ve deployed n8n (v1.99.1) in a Docker container behind:

An AWS Application Load Balancer (ALB) handling SSL termination

A local NGINX reverse proxy forwarding traffic to the Docker container

WebSocket support is configured (including connection_upgrade and related headers)

All environment variables are set properly

N8N_PUSH_BACKEND=websocket is explicitly configured

Despite all efforts, the UI always shows a "Connection lost" banner and WebSocket connections fail silently (status = finished, no data transferred).

Deployment Details
ALB

• HTTPS listener on port 443
• Forwarding to a Target Group (port 80)
• Health checks working
• No sticky sessions
• Path-based forwarding enabled
• SSL certificate installed and valid

NGINX Config (/etc/nginx/sites-available/n8n)

server {
    listen 80;
    server_name domain;
    location /rest/push/ {
        proxy_pass http://localhost:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header Origin $http_origin;
        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 $scheme;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
    location / {
        proxy_pass http://localhost:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header Origin $http_origin;
        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 $scheme;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }

}

Main NGINX Conf (/etc/nginx/nginx.conf)

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }
}
Docker .env
env
Copy
Edit
N8N_HOST=domain
N8N_PORT=5678
N8N_PROTOCOL=http
N8N_EDITOR_BASE_URL=https://domain.com
WEBHOOK_URL=https://domain.com
N8N_PUSH_BACKEND=websocket
N8N_BASIC_AUTH_ACTIVE=true
N8N_BASIC_AUTH_USER=admin
N8N_BASIC_AUTH_PASSWORD=password
GENERIC_TIMEZONE=Asia/Kolkata

Additional Notes
Running curl -I -u admin:... https://domain.com/rest/push returns a redirect to http://..., indicating a mismatch due to ALB SSL termination.

WebSocket attempts show as Finished but do not establish a stream.

All headers (Origin, Host, Upgrade, Connection, etc.) are correctly forwarded via NGINX.

The same deployment works fine on v1.74.0.

This is blocking usage of n8n on the current stack.

Please let us know if something changed in WebSocket handling in recent versions that would explain the persistent connection lost message in the UI despite correct reverse proxy and ALB setup.

To Reproduce

To Reproduce
Launch n8n via Docker on Ubuntu 22.04 behind NGINX

Terminate SSL at ALB, forward HTTP to EC2 instance

Ensure correct headers are added in NGINX for WebSocket

Open the editor in browser: https://domain.com

Observe persistent "Connection lost" in UI

Expected behavior

n8n UI should remain connected and live features (workflow updates, execution state) should work properly with WebSocket enabled.

Operating System

Ubuntu

n8n Version

v1.99.1 (Docker)

Node.js Version

Bundled with Docker image

Database

PostgreSQL

Execution mode

main (default)

[Joffcom]

Hey @ProductVartopia,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-2828".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

[Joffcom]

Hey @ProductVartopia

I suspect this is going to be a configuration issue that is maybe because of some recent changes. For a start I would remove the env options that no longer exist which are the basic auth ones.

I would also start with an nginx configuration that is known to work like the one below.

server {
  listen 80;
  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;
  }
}

Maybe test this with a direct connection then introduce ALB, I would also recommend setting the N8N_PROXY_HOPS option to match the number of proxies you are going through.

[ProductVartopia]

Hello @Joffcom

Proxy Chain Clarification (Critical for N8N_PROXY_HOPS):
We are behind an AWS ALB (which does SSL termination) + NGINX reverse proxy → Docker container. Should N8N_PROXY_HOPS=2 be set in this case?

Basic Auth Deprecation:
You mentioned the basic auth env vars no longer exist. Could you confirm if N8N_BASIC_AUTH_ACTIVE, N8N_BASIC_AUTH_USER, and N8N_BASIC_AUTH_PASSWORD are deprecated in v1.99.1? If so, what is the current recommended approach for basic auth or UI protection?

Minimal Config Context:
We can test the minimal working NGINX config, but since our setup is behind an ALB, we need to ensure headers like X-Forwarded-For, Host, and Origin are preserved to pass security checks. Is your minimal config intended to be used without ALB first, then expanded?

WebSocket Debugging:
We’ve already configured N8N_PUSH_BACKEND=websocket and confirmed WebSocket headers are passed via NGINX. Yet, /rest/push requests still fail with 301 or 401 depending on auth. Would this behavior occur if N8N incorrectly detects the origin? Any debug logs or flags we should enable?

[Joffcom]

Hey @ProductVartopia

I would start with 2 and see if that changes anything, the basic auth env options were deprecated before v1 was released so that is well over 2 years ago now. I only really see that config option on very old installs or when AI has been involved with the configuration which can cause other issues.

We don't support basic auth at all and that was replaced with our user management feature which in a lot of ways is better and you are likely already using it.

I would recommend testing without ALB first to make sure it works then introduce it as it could be an issue between ALB and nginx but our main priority will be working out which step is failing.

[reynaldots]

I'm having the same problem, 1.99.1 version.
I'm updated to 1.100.1 and still occuring.
This problem exist since 1.88.0 (#14653)

I'm using k3s + traefik, applied the headers and N8N_PUSH_BACKEND=websocket, but did not solve.

Only occurs using the webhook-test and on Ai Agent node
On production url work!

Edit:
Its a memory leak.
My pods are dying with this message:

1:0xf3c729310000]   288635 ms: Mark-Compact 250.4 (258.1) -> 250.1 (258.8) MB, pooled: 0 MB, 494.48 / 0.00 ms  (average mu = 0.591, current mu = 0.041) allocation failure; scavenge might not succeed
[1:0xf3c729310000]   289225 ms: Mark-Compact 251.1 (258.8) -> 250.8 (259.3) MB, pooled: 0 MB, 564.91 / 0.00 ms  (average mu = 0.406, current mu = 0.043) allocation failure; scavenge might not succeed   

<--- JS stacktrace --->                                                                                                                                                                                       
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory                                                                                                                             
----- Native stack trace -----  

I changed my deployment resources from:

resources:
  requests:
    cpu: "50m"
    memory: "256Mi"
  limits:
    cpu: "800m"
    memory: "512Mi"

to:

res
ources:
  requests:
    cpu: "50m"
    memory: "256Mi"
  limits:
    cpu: "800m"
    memory: "1024Mi"

For now, it's working.