Resolving n8n WebSocket 'Invalid Origin' Errors Behind Plesk Reverse Proxy

When n8n is deployed behind layered proxies (Plesk nginx → Apache → Docker), WebSocket connectivity and origin checks are common failure points. The 'Invalid origin' error typically means the server received an Origin header that doesn't match the expected public host, often because SSL termination or header rewriting at the proxy changed the effective origin or connection scheme. WebSockets also require explicit proxy directives to allow the Upgrade handshake.

Checklist to resolve the issue: first, ensure n8n's environment variables match the public endpoint-N8N_HOST, N8N_PROTOCOL, and WEBHOOK_URL should reflect the externally visible domain and scheme (https/wss). Next, configure the Plesk nginx reverse proxy to forward WebSocket upgrades: set proxy_http_version to 1.1 and add headers such as proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ensure proxy buffering is disabled if real-time streams are required.

Also verify that SSL termination is consistent: if Plesk terminates TLS and forwards to Apache or Docker via HTTP, ensure n8n knows to expect HTTPS externally (N8N_PROTOCOL=https and WEBHOOK_URL starting with https://). Preserve the Host and Origin headers across each proxy hop so n8n's origin validation can succeed. If Apache is in the chain, enable mod_proxy_wstunnel for websocket forwarding and mirror the same Upgrade/Connection header behavior.

Operational recommendations: add synthetic health checks that exercise the editor and websocket endpoints; centralize logging for proxy, Apache, and container output to trace requests; and document the proxy configuration as part of your deployment repo. If issues persist, collect request traces (headers and handshake logs) and share them with n8n support or your infrastructure team for targeted debugging.