n8nをセルフホストしていると、ワークフローエディタ右上に「Connection lost」と表示され、保存や編集が不安定になることがあります。その原因としてよく調べられているのが、N8N_PUSH_BACKEND、つまり検索されることの多い「n8n_push_backend」です。これは、n8nの画面とサーバーが状態更新をやり取りする方式を決める環境変数で、websocketまたはsseを指定できます。
この記事では、n8n公式ドキュメント、n8n Community、GitHub Issue、Cloudron Forum、OpenLiteSpeed Forum、Railwayの公開スレッドなどで確認できる情報をもとに、n8n_push_backendの意味、sseとwebsocketの違い、リバースプロキシ・CDN・Cloudflare・Nginx・Railway・OpenLiteSpeed環境で起きやすい接続切れの整理、そして設定確認の順番までを、初めての人にもわかるようにまとめます。
| この記事のポイント |
|---|
| ✅ n8n_push_backendが何を変える環境変数なのかがわかる |
| ✅ n8n_push_backend sseとwebsocketの使い分けがわかる |
| ✅ Connection lostが出るときに見るべき設定がわかる |
| ✅ Nginx・CDN・Railway・OpenLiteSpeed環境の注意点がわかる |
n8n_push_backendの基本と接続切れ対策
- n8n_push_backendの答えはUI更新方式をsseかwebsocketに切り替えること
- n8n_push_backend sseはWebSocketが通りにくい環境の回避策になること
- n8n_push_backend websocketは現在の標準寄りだがプロキシ設定が重要になること
- Connection lostの主因はn8n本体よりプロキシやOrigin不一致に寄りやすいこと
- NginxではUpgradeとConnectionヘッダーを通す設定が重要になること
- CDNやCloudflare配下ではOriginヘッダーとキャッシュ設定を疑うこと
n8n_push_backendの答えはUI更新方式をsseかwebsocketに切り替えること
n8n_push_backendを調べている人がまず知りたい答えは、かなりシンプルです。n8nでは、エディタ画面にサーバー側の変更や実行状況を届けるための「プッシュ通信」が使われます。その方式を選ぶ環境変数が、公式ドキュメント上の表記ではN8N_PUSH_BACKENDです。
n8n公式ドキュメントでは、N8N_PUSH_BACKENDについて、バックエンドがUIへ変更を送る方法をserver-sent events、つまりsseにするか、WebSockets、つまりwebsocketにするかを選ぶ項目として説明されています。デフォルト値は、調査時点の公式ドキュメントではwebsocketとされています。
参考：Deployment environment variables | n8n Docs
https://docs.n8n.io/hosting/configuration/environment-variables/deployment/
ここで大事なのは、N8N_PUSH_BACKENDは「ワークフローそのもののHTTPリクエスト処理」を直接変える設定ではないという点です。Cloudron Forumでも、スタッフが「ブラウザとバックエンド間の更新を制御するものではないか」という趣旨で整理しており、ワークフロー自体がWebSocketで動いているわけではない、という見方が示されています。
つまり、Connection lostが出たときにN8N_PUSH_BACKENDを触るのは有効な切り分けになりますが、すべての実行エラーを解決する魔法の設定ではありません。画面上の接続警告、エディタの保存状態、実行中表示、リアルタイム更新のような部分に関係しやすい設定として理解すると、かなり見通しがよくなります。
📌 n8n_push_backendの基本整理
| 項目 | 内容 |
|---|---|
| 正式な環境変数名 | N8N_PUSH_BACKEND |
| よく検索される表記 | n8n_push_backend |
| 指定できる値 | sse / websocket |
| 公式ドキュメント上のデフォルト | websocket |
| 関係しやすい症状 | エディタのConnection lost、UI更新不安定、push接続失敗 |
| 関係しにくいもの | 外部APIへのHTTPリクエスト成功可否そのもの |
✅ 最初に押さえるべき結論
| 状況 | まず見ること |
|---|---|
| n8n画面だけがConnection lostになる | N8N_PUSH_BACKENDとリバースプロキシ |
| WebSocketエラーがブラウザコンソールに出る | websocket設定とプロキシのUpgrade |
| WebSocketがどうしても通らない | N8N_PUSH_BACKEND=sseを試す |
| sseでも直らない | Origin、Host、公開URL、プロキシホップを確認 |
| 長時間実行で落ちる | メモリ不足やn8n再起動も確認 |
検索キーワードとしてはn8n_push_backendと小文字で入力されがちですが、Docker Composeや.envでは大文字のN8N_PUSH_BACKENDとして指定するのが基本です。環境変数は一般的に大文字で書かれるため、設定ファイルでは表記ミスに注意しましょう。
特に、GitHub IssueではN8N_PUSH_BACKEND=sselのような誤記も見られました。sseでもwebsocketでもない値を入れると、意図した切り替えにならない可能性があります。トラブル対応中は焦って入力ミスをしやすいため、まずは変数名と値を一文字ずつ確認するのがおすすめです。
n8n_push_backend sseはWebSocketが通りにくい環境の回避策になること
n8n_push_backend sseと検索している人の多くは、WebSocketまわりでエラーが出ているはずです。sseはServer-Sent Eventsの略で、ざっくり言うと「サーバーからブラウザへ一方向にイベントを送る仕組み」です。WebSocketよりも単純な構造で、プロキシや一部のホスティング環境では通しやすいことがあります。
実際にn8n Communityでは、N8N_PUSH_BACKEND=sseを追加してConnection lostが改善したという投稿が確認できます。Docker runの例として、-e N8N_PUSH_BACKEND=sseを指定しているケースもありました。ただし、後続の投稿ではバージョンやプロキシ環境によってsseで直る場合と、websocketへ戻した方が直る場合が混在しています。
参考：Connection lost: You have a connection issue or the server is down – n8n Community
https://community.n8n.io/t/connection-lost-you-have-a-connection-issue-or-the-server-is-down-n8n-should-reconnect-automatically-once-the-issue-is-resolved/80999?page=3
sseの利点は、WebSocketのUpgrade処理に依存しにくいことです。WebSocketでは、HTTP接続をWebSocketへ切り替えるために、リバースプロキシがUpgradeやConnectionヘッダーを正しく扱う必要があります。ここが崩れると、n8n本体が正常でもブラウザ側にはConnection lostが出ることがあります。
一方で、sseには注意点もあります。n8n Communityの投稿では、N8N_PUSH_BACKEND=sseを設定したあと、コラボレーション機能が無効になるというログが出た例がありました。ログ内容としては、pushが一方向に設定されているため、コラボレーション機能にはwebsocketを使うよう案内するものです。
📌 n8n_push_backend sseが向きやすい場面
| 場面 | sseが候補になる理由 |
|---|---|
| WebSocketがプロキシで失敗する | Upgrade不要で通る可能性がある |
| OpenLiteSpeed配下でWebSocketが不安定 | フォーラムでSSE回避例あり |
| CDNや特殊なプロキシを通している | WebSocketより単純に扱える場合がある |
| まずConnection lostを止めたい | 切り分けとして試しやすい |
| コラボレーション機能を重視しない | 一方向pushでも運用できる可能性がある |
🧩 sse設定例
| 形式 | 設定例 |
|---|---|
| Docker run | -e N8N_PUSH_BACKEND=sse |
| Docker Compose | - N8N_PUSH_BACKEND=sse |
| .env | N8N_PUSH_BACKEND=sse |
| Railwayなどの環境変数 | キー：N8N_PUSH_BACKEND / 値：sse |
ただし、sseは万能ではありません。n8n Communityの1.88.0関連スレッドでは、sseからwebsocketへ変更したら改善したという投稿もあります。つまり、Connection lostの原因が「WebSocketそのもの」ではなく、「公開URL」「Originヘッダー」「Hostヘッダー」「プロキシホップ」の不一致にある場合、sseだけでは解決しないことがあります。
そのため、N8N_PUSH_BACKEND=sseは「WebSocketが通らない環境での有力な回避策」と考えるのが現実的です。まずsseで症状が変わるかを見て、改善しない場合はURLやプロキシ設定へ進む、という順番がわかりやすいでしょう。
n8n_push_backend websocketは現在の標準寄りだがプロキシ設定が重要になること
n8n_push_backend websocketと検索する人は、n8nのデフォルトや推奨設定が気になっているケースが多いでしょう。公式ドキュメントでは、N8N_PUSH_BACKENDのデフォルトはwebsocketとされています。WebSocketは、ブラウザとサーバーが双方向に通信する仕組みで、リアルタイム性が高いのが特徴です。
n8nのエディタでは、ワークフローの実行状況や保存状態など、画面側がリアルタイムに変わる場面があります。そのため、WebSocketは機能面では自然な選択肢です。n8n Communityでも、websocketに切り替えて解決したという報告が複数確認できます。
ただし、WebSocketはリバースプロキシとの相性が問題になりやすい通信方式です。Nginx、Nginx Proxy Manager、Synology、Traefik、CloudFront、ALB、OpenLiteSpeed、Railwayのように、n8nの前段に何かが挟まる構成では、ブラウザから見えるURLとn8nコンテナ内部のURLが異なることがよくあります。
その結果、n8n側が期待するOriginと実際のリクエストOriginがずれたり、WebSocketのUpgradeヘッダーが失われたりして、画面では「Connection lost」と表示されます。GitHub Issue #14572でも、CDN配下でWebSocketがcode=1008になり、Connection lostが点滅するような報告がありました。
参考：Connection lost when behind a CDN · Issue #14572
https://github.com/n8n-io/n8n/issues/14572
📌 websocketで重要な設定マトリクス
| 確認項目 | 重要な理由 |
|---|---|
N8N_PUSH_BACKEND=websocket |
WebSocket方式を明示する |
proxy_http_version 1.1 |
WebSocket Upgradeに必要になりやすい |
Upgradeヘッダー |
HTTPからWebSocketへ切り替える |
Connectionヘッダー |
Upgrade要求を維持する |
Hostヘッダー |
n8nが正しいホストを認識する |
Originヘッダー |
n8nのOrigin検証に関係しやすい |
N8N_PROXY_HOPS |
何段プロキシの後ろかを伝える |
🔧 websocketを使うときの代表的なNginx設定要素
| 設定 | 例 |
|---|---|
| HTTPバージョン | proxy_http_version 1.1; |
| Upgrade | proxy_set_header Upgrade $http_upgrade; |
| Connection | proxy_set_header Connection "upgrade"; |
| Host | proxy_set_header Host $host; |
| X-Forwarded-Proto | proxy_set_header X-Forwarded-Proto $scheme; |
| キャッシュ回避 | proxy_cache_bypass $http_upgrade; |
n8n Communityでは、Nginx Proxy Managerを使っている場合は「Websockets Support」を有効にするだけで改善したという投稿も確認できます。手書きNginxではなく管理画面型のプロキシを使っている場合、まずはそのチェックボックスやWebSocket関連オプションを探すのが早いでしょう。
結論として、websocketはn8nの現在の標準寄りの選択肢ですが、前段のプロキシが正しくWebSocketを通すことが前提です。もし自分の環境がシンプルなDocker単体ならwebsocketで問題ない場合もありますが、公開URL、SSL終端、CDN、リバースプロキシを使っているなら、設定を丁寧にそろえる必要があります。
Connection lostの主因はn8n本体よりプロキシやOrigin不一致に寄りやすいこと
n8nのConnection lostを見ると、「n8nが壊れたのでは」と感じるかもしれません。しかし、調査した公開事例を見る限り、少なくともセルフホスト環境では、n8n本体よりも前段のプロキシ、CDN、Origin、Host、公開URL設定が原因になっているケースがかなり目立ちます。
n8n Communityの1.88.0スレッドでは、リバースプロキシを使っているかどうかを最初に確認するやり取りがあります。その後、WebSocketを許可する設定、HostとOriginヘッダーを通す必要性、N8N_PUSH_BACKEND=websocketへの変更などが話題になっています。つまり、単にn8nのバージョンだけでなく、通信経路全体を見る必要があります。
参考：1.88.0 connection lost loop on self-hosted version – n8n Community
https://community.n8n.io/t/1-88-0-connection-lost-loop-on-self-hosted-version/99560
特に最近のn8nでは、Originチェックが厳しくなっている可能性がうかがえる情報があります。Mediumの記事では、CloudFrontとALBの構成で、リクエストにOriginヘッダーがないためInvalid originが出ていたと説明されています。この記事では、CloudFront側でOriginヘッダーを追加したことで解決したとされています。
参考：Solve Self-hosted n8n Workflow Editor “Connection Lost”
https://medium.com/@cwentsai/n8n-v1-86-editor-connection-lost-issue-f320d62579cf
ここでいうOriginとは、ブラウザが「どのサイトからこのリクエストを送っているか」を示す情報です。たとえば、ユーザーがhttps://n8n.example.comでn8nを開いているなら、n8n側もそれに合ったOriginを受け取る必要があります。前段のCDNやプロキシがこの情報を落としたり、別の値にしたりすると、n8nが不正なアクセスと判断することがあります。
📌 Connection lostで疑う順番
| 優先度 | 確認対象 | 見る理由 |
|---|---|---|
| 高 | ブラウザコンソール | WebSocketかSSEか、Originかを見分ける |
| 高 | n8nログ | Invalid originや再起動の有無を見る |
| 高 | リバースプロキシ | WebSocket UpgradeやHostが通っているか |
| 中 | N8N_EDITOR_BASE_URL |
エディタの公開URLが正しいか |
| 中 | WEBHOOK_URL |
公開URLとn8n内部URLのズレを減らす |
| 中 | N8N_PROXY_HOPS |
プロキシ配下であることをn8nに伝える |
| 低〜中 | N8N_PUSH_BACKEND |
sseとwebsocketの切り替えで切り分ける |
🧪 症状別の見立て表
| 症状 | よくある原因候補 |
|---|---|
| 画面右上だけConnection lost | push接続の失敗 |
| ブラウザコンソールにwss失敗 | WebSocket設定不足 |
Invalid originがログに出る |
Originまたは公開URLの不一致 |
| 一定時間後に落ちる | メモリ不足やアプリ再起動も疑う |
| 1.86では動くが1.88以降で不安定 | プロキシ・Originチェック差分の可能性 |
sseでもwebsocketでも直らない |
URL、Host、Proxy hopsの見直しが必要 |
GitHub Issue #16707では、sseとwebsocketの両方を試しても解決しないという報告もあります。これは、N8N_PUSH_BACKENDだけを変えても、根本がOriginやNginx設定にある場合は解決しにくいことを示しているように見えます。
したがって、Connection lost対策では「まずN8N_PUSH_BACKENDを変える」だけでなく、「n8nが外部からどう見えているか」をそろえることが重要です。内部では5678で動いていても、外部からはhttps://example.comの443番でアクセスしているなら、その差をn8nとプロキシの両方に正しく伝える必要があります。
NginxではUpgradeとConnectionヘッダーを通す設定が重要になること
Nginxを前段に置いてn8nを公開している場合、N8N_PUSH_BACKEND=websocketを使うなら、WebSocketのUpgradeを通す設定が重要です。n8n Communityでは、Nginx設定にproxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"などを追加して改善したという投稿が複数あります。
WebSocketは、最初はHTTPとして接続し、その後に「この接続をWebSocketへ切り替えたい」というUpgrade要求を送ります。Nginxがその要求をn8nへ渡さないと、ブラウザ側はwss://.../rest/pushへの接続に失敗し、n8nの画面ではConnection lostが表示されることがあります。
Nginx Proxy Managerの場合は、管理画面に「Websockets Support」のような項目があり、それを有効にするだけで改善したという投稿もありました。自分でconfを書く構成か、管理画面から設定する構成かで作業は変わりますが、見るべきポイントは共通しています。
参考：Connection lost: You have a connection issue or the server is down – n8n Community
https://community.n8n.io/t/connection-lost-you-have-a-connection-issue-or-the-server-is-down-n8n-should-reconnect-automatically-once-the-issue-is-resolved/80999?page=3
📌 Nginxでよく出てくる設定要素
| 設定 | 役割 |
|---|---|
proxy_pass |
n8n本体へリクエストを渡す |
proxy_http_version 1.1 |
WebSocketで必要になりやすいHTTP/1.1を使う |
proxy_set_header Upgrade $http_upgrade |
Upgrade要求をn8nへ渡す |
proxy_set_header Connection "upgrade" |
接続切り替えを維持する |
proxy_set_header Host $host |
元のホスト名をn8nへ伝える |
proxy_set_header X-Forwarded-Proto $scheme |
http/httpsの外部プロトコルを伝える |
proxy_buffering off |
SSEやリアルタイム通信で役立つことがある |
🛠️ Nginx確認チェックリスト
| チェック | 状態 |
|---|---|
| ✅ WebSocket用ヘッダーを設定したか | 未設定なら優先確認 |
✅ proxy_http_version 1.1があるか |
ない場合は追加候補 |
✅ Hostを渡しているか |
Origin検証に関係する可能性 |
✅ X-Forwarded-Protoを渡しているか |
HTTPS終端時に重要 |
| ✅ キャッシュやバッファが邪魔していないか | SSE/WebSocketで問題になることがある |
| ✅ 設定後にNginxを再起動したか | reload忘れに注意 |
注意したいのは、ネット上の設定例をそのまま貼っても、環境によっては動かないことです。たとえば、n8nコンテナ名、内部ポート、SSL終端の場所、Dockerネットワーク、CDNの有無によってproxy_pass先やヘッダーの意味が変わります。設定例は「部品」として見て、自分の構成に合わせて調整する必要があります。
また、N8N_PUSH_BACKEND=sseへ変更する場合でも、Nginx側のバッファリングやキャッシュが邪魔になることがあります。SSEはサーバーから少しずつイベントを流すため、プロキシがレスポンスを溜め込むと画面更新が遅れたり切れたりする可能性があります。一般的にはproxy_buffering offのような設定が話題になりますが、適用可否は環境に合わせて確認しましょう。
CDNやCloudflare配下ではOriginヘッダーとキャッシュ設定を疑うこと
n8nをCDNやCloudflareの後ろに置いている場合、N8N_PUSH_BACKENDだけでなく、CDNがヘッダーやWebSocketをどう扱っているかを確認する必要があります。GitHub Issue #14572では、CDN配下でConnection lostが点滅し、ブラウザコンソールにWebSocket関連のエラーが出るという報告がありました。
CDNは本来、静的ファイルの配信やセキュリティ、SSL終端などに便利です。しかし、n8nのエディタのようにリアルタイム通信を使う画面では、CDNがヘッダーを変えたり、キャッシュを挟んだり、WebSocket接続を期待通りに通さなかったりすると、問題の原因になります。
Mediumの記事では、CloudFrontからオリジンへ送られるリクエストにOriginヘッダーがなく、n8n側でInvalid originになっていたと説明されています。このケースでは、CloudFrontのOrigin設定でヘッダーを追加したことで、WebSocketへ戻しても動いたとされています。
参考：Solve Self-hosted n8n Workflow Editor “Connection Lost”
https://medium.com/@cwentsai/n8n-v1-86-editor-connection-lost-issue-f320d62579cf
Cloudflareについては、n8n Communityで「Cloudflareを使っているならサブドメインのキャッシュを無効にすることが推奨される」という趣旨の投稿がありました。これは公式な万能手順というより、プロキシやCDNのキャッシュがリアルタイム通信の邪魔をする可能性があるため、切り分けとして妥当な見方です。
📌 CDN配下で見るべきポイント
| 確認対象 | 理由 |
|---|---|
| WebSocket対応 | CDNがwss接続を通す必要がある |
| Originヘッダー | n8nのOrigin検証に関係しやすい |
| Hostヘッダー | 公開ドメインとn8nの認識を合わせる |
| キャッシュ設定 | /rest/pushなどをキャッシュしない |
| HTTPS終端 | 外部はhttps、内部はhttpのズレが起きやすい |
N8N_PROXY_HOPS |
プロキシ段数をn8nへ伝える |
🧭 CDNあり環境の切り分け手順
| 手順 | 内容 |
|---|---|
| 1 | ブラウザコンソールでwss://や/rest/pushの失敗を見る |
| 2 | n8nログにInvalid originがないか確認する |
| 3 | CDNを一時的にバイパスできるなら比較する |
| 4 | キャッシュを無効化または対象外にする |
| 5 | Origin/Hostヘッダーを明示的に渡す |
| 6 | websocketとsseを切り替えて挙動を見る |
Railwayの公開スレッドでも、プロキシ配下でn8nが外部URLを正しく認識できず、pushチャネルが失敗してConnection lostになったという説明があります。そこでは、N8N_EDITOR_BASE_URL、WEBHOOK_URL、N8N_HOST、N8N_PROTOCOL、N8N_PROXY_HOPSなどを明示する対応が紹介されていました。
参考：My n8n is lost connection, please check why – Railway Central Station
https://station.railway.com/questions/my-n8n-is-lost-connection-please-check-5af6cbc5
CDN配下のConnection lostは、単に「sseにする」「websocketにする」だけでは解けないことがあります。公開URL、Origin、Host、プロキシ段数、キャッシュ、WebSocket対応を一つずつそろえることで、ようやく安定するケースがあると見た方がよいでしょう。
ポチップ
n8n_push_backendの実践設定と環境別チェック
- DockerではN8N_PUSH_BACKENDを環境変数として明示すること
- RailwayなどPaaSでは公開URLとプロキシホップを合わせること
- OpenLiteSpeedではwebsocketが難しい場合にsseが現実的な回避策になること
- 長時間実行でConnection lostが出る場合はメモリ不足も疑うこと
- バージョンアップ後の接続切れは設定差分を順番に潰すこと
- 直らないときはブラウザコンソールとn8nログをセットで見ること
- 総括：n8n_push_backendのまとめ
DockerではN8N_PUSH_BACKENDを環境変数として明示すること
Dockerでn8nを動かしている場合、N8N_PUSH_BACKENDは環境変数として指定します。Docker runなら-e N8N_PUSH_BACKEND=websocketまたは-e N8N_PUSH_BACKEND=sse、Docker Composeならenvironmentに追加するのが一般的です。
n8n Communityでは、Docker runの例として-e N8N_PUSH_BACKEND=sseを入れて改善した投稿がありました。一方で、1.88.0以降のConnection lostに関する別スレッドでは、N8N_PUSH_BACKEND=websocketにしたら直ったという投稿もあります。つまり、Dockerだからsse、Dockerだからwebsocketと決め打ちするより、前段のプロキシ環境に合わせて選ぶ必要があります。
Docker環境でよくあるのは、n8nコンテナは内部で5678番ポートを待ち受けているが、外部からはhttps://n8n.example.comでアクセスしている構成です。この場合、n8nにとっての内部URLとブラウザから見える公開URLが違います。このズレを放置すると、Connection lostの原因になることがあります。
そのため、N8N_PUSH_BACKENDだけでなく、N8N_EDITOR_BASE_URL、WEBHOOK_URL、N8N_HOST、N8N_PROTOCOL、N8N_PROXY_HOPSなどもセットで確認するのが実務的です。特にSSLをNginxやCDNで終端している場合、n8n本体はHTTPで動いていても、外部からはHTTPSとして見えます。
📌 Docker Composeの確認項目
| 環境変数 | 例 | 目的 |
|---|---|---|
N8N_PUSH_BACKEND |
websocket / sse |
UI更新方式を指定 |
N8N_HOST |
n8n.example.com |
外部ホスト名を指定 |
N8N_PROTOCOL |
https |
外部から見えるプロトコル |
N8N_EDITOR_BASE_URL |
https://n8n.example.com |
エディタの公開URL |
WEBHOOK_URL |
https://n8n.example.com/ |
Webhookの公開URL |
N8N_PROXY_HOPS |
1 |
プロキシ配下であることを伝える |
🧩 Docker runでの指定イメージ
| 目的 | 指定例 |
|---|---|
| WebSocketを使う | -e N8N_PUSH_BACKEND=websocket |
| SSEを使う | -e N8N_PUSH_BACKEND=sse |
| 公開URLを伝える | -e N8N_EDITOR_BASE_URL=https://n8n.example.com |
| Webhook URLを伝える | -e WEBHOOK_URL=https://n8n.example.com/ |
| プロキシ配下を伝える | -e N8N_PROXY_HOPS=1 |
注意点として、古い記事や投稿にはVUE_APP_URL_BASE_APIが出てくることがあります。公式ドキュメントでは、これはn8n-editor-uiパッケージを手動ビルドする場合に、フロントエンドがバックエンドAPIへ到達するための値として説明されています。通常のDocker利用で常に必要とは限らないため、現在の構成で本当に必要かは慎重に見た方がよいでしょう。
また、Dockerの環境変数を変えたら、コンテナの再作成や再起動が必要です。.envを書き換えただけで実際のコンテナに反映されていない、ということもよくあります。docker compose configやdocker inspectなどで、実際に環境変数が入っているか確認できると安心です。
RailwayなどPaaSでは公開URLとプロキシホップを合わせること
RailwayのようなPaaS環境では、アプリは内部ポートで動き、外部にはRailway側のプロキシを通してHTTPSで公開されます。この構成では、n8nが自分の外部URLを誤って認識すると、エディタのpush接続が失敗し、Connection lostが出ることがあります。
Railway Central Stationの公開スレッドでは、手動再デプロイ後に公開URLが明示されておらず、n8nが期待するOriginを誤って計算していたため、pushチャネルが失敗したという説明があります。対応として、N8N_EDITOR_BASE_URL、WEBHOOK_URL、N8N_HOST、N8N_PROTOCOL、N8N_PROXY_HOPS、PORTなどを明示する例が挙げられていました。
参考：My n8n is lost connection, please check why – Railway Central Station
https://station.railway.com/questions/my-n8n-is-lost-connection-please-check-5af6cbc5
ここで大切なのは、アプリ内部の待ち受けポートと、ユーザーがアクセスする外部ポートを混同しないことです。Railwayの例では、アプリは5678で待ち受けても、外部からはHTTPSの443番としてアクセスされます。そのため、N8N_PORT=443を無理に指定するのではなく、PaaS側の公開URLとアプリ側の待ち受け設定を分けて考える必要があります。
また、PaaSではプロキシが何段挟まっているかをn8nに伝えるために、N8N_PROXY_HOPS=1のような設定が役立つ場合があります。これは、リクエスト元やプロトコルを判断するときに、n8nがX-Forwarded-*系ヘッダーをどこまで信用するかに関係する設定と考えるとわかりやすいです。
📌 PaaS環境での設定観点
| 観点 | 確認内容 |
|---|---|
| 公開URL | ブラウザで開くURLをN8N_EDITOR_BASE_URLへ反映 |
| Webhook URL | 外部サービスから届くURLをWEBHOOK_URLへ反映 |
| ホスト名 | N8N_HOSTを公開ドメインに合わせる |
| プロトコル | 外部がHTTPSならN8N_PROTOCOL=https |
| ポート | 内部待ち受けと外部公開ポートを混同しない |
| プロキシ | N8N_PROXY_HOPSを検討する |
🧭 Railway系トラブルの見立て
| 症状 | 見る場所 |
|---|---|
| デプロイ後に急にConnection lost | 環境変数が消えていないか |
| ログインはできるが編集画面が不安定 | push接続とOrigin |
| URLを変えたあと不安定 | N8N_EDITOR_BASE_URLとWEBHOOK_URL |
| 外部HTTPS、内部HTTP | N8N_PROTOCOLとプロキシヘッダー |
| WebSocketが不安定 | N8N_PUSH_BACKEND=sseも切り分け候補 |
PaaSの注意点は、管理画面上では環境変数を変えたつもりでも、PrimaryとWorkerの両方に反映されていない場合があることです。Railwayの投稿でも、PrimaryとWorkerの再デプロイという話が出ています。構成によっては、n8n本体だけでなくワーカー側の環境変数もそろえる必要があるかもしれません。
PaaSでは自由にNginx設定を触れないこともあります。その場合、N8N_PUSH_BACKEND=sseは現実的な回避策になることがあります。ただし、先ほどの通り、Originや公開URLが間違っている場合はsseだけでは直らない可能性があるため、URL系の設定を先にそろえるのが堅実です。
OpenLiteSpeedではwebsocketが難しい場合にsseが現実的な回避策になること
OpenLiteSpeedのリバースプロキシ配下でn8nを動かしている場合、WebSocket接続がうまくいかない事例が公開されています。OpenLiteSpeed Forumでは、wss://.../rest/pushへの接続で「Invalid WebSocket frame: RSV1 must be clear」というエラーが出るケースが投稿されていました。
このスレッドでは、OpenLiteSpeedを経由せずに:5678へ直接アクセスするとWebSocketが動く一方、OpenLiteSpeedを挟むと問題が出るという切り分けがされています。また、n8nのバージョンを1.86.1へ戻すと問題が出ないという情報もありました。ただし、バージョンダウンは根本的な解決というより回避策に近い可能性があります。
参考：WebSocket Not Connecting with n8n Behind OpenLiteSpeed Reverse Proxy
https://forum.openlitespeed.org/threads/websocket-not-connecting-with-n8n-behind-openlitespeed-reverse-proxy-docker-setup.7465/
同じスレッドでは、N8N_PUSH_BACKEND=sseを使うことで動作したという構成例が紹介されています。投稿者は、OpenLiteSpeedがWebSocket接続をブロックまたは圧縮しているように見える、と説明しています。これは推測を含む表現ですが、少なくとも実例として「OLS配下ではSSE回避が候補になる」と言えます。
OpenLiteSpeedでは、gzipやbrotliなどの圧縮、WebSocket有効化、ヘッダー追加、/rest/pushの扱いなど、複数の設定が関係します。Nginxに比べてn8n向けの情報が多いとは言いにくいため、最初からWebSocketにこだわりすぎると時間を使う可能性があります。
📌 OpenLiteSpeed環境の見立て
| 状況 | 対応候補 |
|---|---|
直接:5678では動く |
n8n本体よりOLS設定を疑う |
| OLS経由でwssが失敗 | WebSocket設定や圧縮を確認 |
| RSV1系のエラー | 圧縮やフレーム処理の影響を疑う |
| WebSocketにこだわらない | N8N_PUSH_BACKEND=sseを試す |
| コラボ機能が必要 | WebSocket側の調整を継続検討 |
🧩 OLS配下でのSSE設定例の考え方
| 項目 | 例 |
|---|---|
| Push方式 | N8N_PUSH_BACKEND=sse |
| 外部ホスト | N8N_HOST=domain.com |
| 外部プロトコル | N8N_PROTOCOL=https |
| Webhook | WEBHOOK_URL=https://domain.com/ |
| プロキシ段数 | N8N_PROXY_HOPS=1 |
| Origin関連 | N8N_CORS_ORIGINなども環境により検討 |
もちろん、OpenLiteSpeedでWebSocketがまったく使えないと断定はできません。設定次第で動く可能性はあります。ただ、公開事例を見る限り、短時間でConnection lostを止めたい場合は、N8N_PUSH_BACKEND=sseを試す価値は高いでしょう。
運用上、n8nのコラボレーション機能や双方向性が必要でなければ、SSEで安定させる選択も現実的です。一方で、チーム編集や将来的な機能を重視するなら、OLSのWebSocket設定を深掘りするか、NginxやTraefikなど実績の多いリバースプロキシへ寄せる判断もありえます。
長時間実行でConnection lostが出る場合はメモリ不足も疑うこと
N8N_PUSH_BACKENDやプロキシ設定ばかりを見ていると見落としがちですが、長時間実行中にConnection lostが出る場合は、n8nプロセス自体が落ちている可能性もあります。Cloudron Forumの事例では、WebSocket接続エラーの裏で、Node.jsのヒープメモリ不足によるクラッシュログが確認されていました。
このケースでは、ブラウザ側にはWebSocket connection failedのように見えていましたが、ログにはJavaScript heap out of memoryが出ており、n8nが再起動していたようです。最終的にNODE_OPTIONS=--max_old_space_size=8192を追加したことで解決したと投稿されています。
参考：n8n Web Socket Connection Failed | Cloudron Forum
https://forum.cloudron.io/topic/12968/n8n-web-socket-connection-failed
この事例からわかるのは、ブラウザに出るConnection lostやWebSocketエラーは、必ずしもWebSocket設定そのものだけが原因ではないということです。n8nプロセスがメモリ不足で落ちれば、当然ブラウザとの接続は切れます。その結果として、画面にはConnection lostが出ます。
特に、大量のHTTP Requestノード、大量データの処理、長時間のワークフロー実行、実行履歴の肥大化、大きなJSONデータの保持などがある場合、メモリを消費しやすくなる可能性があります。これは一般論ですが、n8nに限らずNode.jsアプリではヒープ上限に当たるとプロセスが落ちることがあります。
📌 メモリ不足を疑うサイン
| サイン | 内容 |
|---|---|
| 一定時間後に切れる | 接続設定より負荷や再起動の可能性 |
| n8nログにOOM | heap out of memoryなど |
| 実行中にn8nが再起動 | コンテナログや監視で確認 |
| 大量データ処理をしている | HTTP Requestやループ処理を確認 |
| メモリグラフが上がり続ける | リソース不足の可能性 |
🧪 Connection lostの原因切り分け表
| 原因候補 | 確認方法 |
|---|---|
| WebSocket不通 | ブラウザコンソールにwss失敗 |
| Origin不一致 | n8nログにInvalid origin |
| プロキシ設定不足 | Nginx/OLS/CDN設定を見る |
| メモリ不足 | n8nログにOOM、再起動履歴 |
| アプリクラッシュ | Docker logsやPaaS logs |
| バージョン差分 | アップデート前後で比較 |
メモリ対策としてNODE_OPTIONS=--max_old_space_size=8192のような指定が紹介されていますが、これは環境のメモリ容量や運用方針に合わせて慎重に扱うべきです。サーバー自体に十分なメモリがないのに上限だけ上げても、別の問題につながるかもしれません。
また、根本対策としては、ワークフローを分割する、不要な大容量データを持ち回らない、実行データの保存設定を見直す、外部DBやキュー構成を検討する、といった方向もあります。この記事の主題はN8N_PUSH_BACKENDですが、長時間実行時のConnection lostでは「通信」と「プロセスの生存」を分けて確認することが大切です。
バージョンアップ後の接続切れは設定差分を順番に潰すこと
n8nのConnection lostに関する公開事例では、バージョンアップ後に問題が出たという話が目立ちます。n8n Communityでは、1.86.1以前では動いていたが1.88.0でConnection lostが出る、1.90系でNginx設定を追加した、1.99.1でも解決できない、など複数の投稿が確認できます。
ただし、これを「特定バージョンが悪い」と単純に断定するのは避けた方がよいです。バージョンアップによってWebSocketやOriginチェックまわりの挙動が変わった可能性はありますが、実際にはプロキシ、CDN、ヘッダー、公開URL、キャッシュなどの既存設定が、新しい挙動に合わなくなったと見る方が実務的です。
GitHub Issue #14572では、1.88.0でCDN配下のConnection lostが報告されています。n8n Communityでも、1.88.0の接続切れループに対して、WebSocket設定、Host、Originヘッダー、N8N_PUSH_BACKEND=websocketなどが話題になっています。
参考：1.88.0 connection lost loop on self-hosted version – n8n Community
https://community.n8n.io/t/1-88-0-connection-lost-loop-on-self-hosted-version/99560
バージョンアップ後の対応では、いきなり複数の設定を同時に変えない方が原因を特定しやすいです。まずブラウザコンソールを見る。次にn8nログを見る。そこからWebSocketエラーなのか、Originエラーなのか、アプリ再起動なのかを分けます。その上で、N8N_PUSH_BACKEND、プロキシ設定、公開URL設定の順に確認します。
📌 バージョンアップ後のチェック順
| 順番 | 確認内容 |
|---|---|
| 1 | どのバージョンからどのバージョンへ上げたか |
| 2 | ブラウザコンソールのエラー |
| 3 | n8nログのエラー |
| 4 | リバースプロキシのWebSocket設定 |
| 5 | N8N_PUSH_BACKENDの値 |
| 6 | 公開URL系の環境変数 |
| 7 | CDN・Cloudflareのキャッシュやヘッダー |
| 8 | メモリ不足や再起動履歴 |
🧩 変更前後の比較メモ
| 比較項目 | 変更前 | 変更後 |
|---|---|---|
| n8nバージョン | 例：1.86.1 | 例：1.88.0以降 |
| Push方式 | 未指定 / sse / websocket | 現在値 |
| プロキシ | Nginx / Traefik / OLS | 設定差分 |
| CDN | あり / なし | キャッシュ設定 |
| 公開URL | 旧URL | 新URL |
| ログ | エラーなし | Invalid originなど |
ダウングレードで一時的に直るケースもありますが、公開スレッドでは「以前のバージョンへ戻す必要は必ずしもない」という趣旨の投稿も見られます。特にリバースプロキシでWebSocketを正しく許可すれば解決するケースがあるため、まずは現在のバージョンに合わせて設定を整える方がよいでしょう。
もちろん、本番運用中で業務影響が大きい場合は、一時的に安定版へ戻す判断もありえます。ただし、その場合でも最終的にはプロキシ設定や公開URL設定を見直して、次回アップデートで同じ問題を繰り返さないようにするのが望ましいです。
直らないときはブラウザコンソールとn8nログをセットで見ること
N8N_PUSH_BACKEND=sseにしても直らない、websocketにしても直らない、Nginx設定を足しても直らない。こういうときは、闇雲に設定を増やすより、ブラウザコンソールとn8nログをセットで見るのが近道です。
ブラウザコンソールでは、wss://.../rest/pushへの接続失敗、code=1008、Invalid WebSocket frame、SSE接続の失敗などが見えることがあります。n8nログでは、Invalid origin、Origin header is missing、メモリ不足、再起動、設定の非推奨警告などが出ることがあります。片方だけを見ると、原因を誤解しやすくなります。
たとえば、Mediumの記事ではブラウザ側ではConnection lostに見えていましたが、n8nログにはOrigin header missingとInvalid originが出ていました。Cloudron Forumでは、ブラウザ側にはWebSocket失敗が出ていましたが、n8nログにはJavaScript heap out of memoryが出ていました。この2つは対応方法がまったく違います。
参考：n8n Web Socket Connection Failed | Cloudron Forum
https://forum.cloudron.io/topic/12968/n8n-web-socket-connection-failed
つまり、Connection lostは「結果」としての表示であり、原因は複数あります。原因を見ずにN8N_PUSH_BACKENDだけを何度も変えると、設定が増えて管理しづらくなります。まずはエラーの種類を分類し、その種類に合った対策を選ぶのが重要です。
📌 ログで見るべきキーワード
| キーワード | 考えられる方向 |
|---|---|
wss:// |
WebSocket接続の問題 |
/rest/push |
n8nのpush接続まわり |
Invalid origin |
Originや公開URLの不一致 |
Origin header is missing |
CDNやプロキシがOriginを落としている可能性 |
heap out of memory |
メモリ不足 |
ECONNREFUSED |
n8n再起動中や接続先不通 |
code=1008 |
WebSocketのポリシー違反系の可能性 |
🧭 原因別の次アクション
| 原因の見立て | 次にやること |
|---|---|
| WebSocket Upgrade不足 | NginxやプロキシのWebSocket設定 |
| Origin不一致 | N8N_EDITOR_BASE_URL、Host、Originヘッダー |
| CDNが絡む | キャッシュ除外、ヘッダー転送、CDNバイパス比較 |
| PaaSプロキシ | N8N_PROXY_HOPSと公開URL設定 |
| OLSでwss失敗 | N8N_PUSH_BACKEND=sseを試す |
| OOM | メモリ設定やワークフロー分割 |
設定変更後は、n8nを再起動または再デプロイし、ブラウザもハードリロードするのがおすすめです。古いフロントエンド資産やキャッシュが残っていると、設定を変えたのに古い挙動に見えることがあります。CDNを使っている場合は、CDN側のキャッシュも疑いましょう。
また、トラブル対応の履歴をメモしておくと、後から戻しやすくなります。sseにした、websocketに戻した、NginxのUpgradeを追加した、Originを追加した、という変更を一つずつ記録しておけば、原因がわかったあとに余計な設定を整理できます。
総括：n8n_push_backendのまとめ
最後に記事のポイントをまとめます。
n8n_push_backendで検索される設定の正式名はN8N_PUSH_BACKENDである。N8N_PUSH_BACKENDはn8nのUI更新をsseまたはwebsocketで送る方式を選ぶ環境変数である。- 公式ドキュメント上のデフォルトは
websocketである。 n8n_push_backend sseはWebSocketが通りにくい環境での回避策になる。n8n_push_backend websocketはリアルタイム性に向くが、リバースプロキシ設定が重要である。- Connection lostはn8n本体の故障とは限らず、プロキシ、CDN、Origin、Hostの不一致でも起きる。
- Nginxでは
Upgrade、Connection、Host、X-Forwarded-Protoなどのヘッダー確認が重要である。 - Nginx Proxy ManagerではWebsockets Supportの有効化が有効な場合がある。
- CDNやCloudflare配下ではOriginヘッダーとキャッシュ設定を確認するべきである。
- RailwayなどPaaSでは
N8N_EDITOR_BASE_URL、WEBHOOK_URL、N8N_HOST、N8N_PROTOCOL、N8N_PROXY_HOPSをそろえることが重要である。 - OpenLiteSpeed配下でWebSocketが難しい場合、
N8N_PUSH_BACKEND=sseが現実的な回避策になりうる。 - 長時間実行でConnection lostが出る場合、WebSocketではなくメモリ不足やn8n再起動が原因の場合もある。
- バージョンアップ後のConnection lostは、バージョンだけでなく既存のプロキシ設定との差分を見るべきである。
- 直らないときはブラウザコンソールとn8nログをセットで確認するべきである。
sseとwebsocketのどちらが正解かは環境次第であり、症状に合わせて切り替えて検証することが重要である。
記事作成にあたり参考にさせて頂いたサイト
- https://docs.n8n.io/hosting/configuration/environment-variables/deployment/
- https://community.n8n.io/t/connection-lost-you-have-a-connection-issue-or-the-server-is-down-n8n-should-reconnect-automatically-once-the-issue-is-resolved/80999?page=3
- https://www.reddit.com/r/n8n/comments/1kps6il/permanent_connection_lost/
- https://community.n8n.io/t/1-88-0-connection-lost-loop-on-self-hosted-version/99560
- https://forum.cloudron.io/topic/12968/n8n-web-socket-connection-failed
- https://github.com/n8n-io/n8n/issues/16707
- https://medium.com/@cwentsai/n8n-v1-86-editor-connection-lost-issue-f320d62579cf
- https://github.com/n8n-io/n8n/issues/14572
- https://forum.openlitespeed.org/threads/websocket-not-connecting-with-n8n-behind-openlitespeed-reverse-proxy-docker-setup.7465/
- https://station.railway.com/questions/my-n8n-is-lost-connection-please-check-5af6cbc5
各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
私たちは、情報の収集や整理を通じて「情報をまとめてわかりやすく伝える」という形で新たな価値を提供できるのではないかと考え、運営しております。
なお、引用や参照の方法には不備、あるいはご不快に感じられる点がございましたら、迅速に対応いたしますので、お手数ですがお問い合わせフォームよりご連絡いただければ幸いです。
今後とも、どうぞよろしくお願いいたします。
当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。
情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。
迅速に対応をさせていただきます。
その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。
今後とも当サイトをよろしくお願いいたします。
