中級向け
n8nを外に公開するときの守り
VPS で動かした n8n を Web に開いたとき、外から何に届くのかを確かめました。ログイン画面・Webhook・承認リンク・MCP の入口は誰でも届くこと、5678番は閉じていたこと、アカウントを作る順番、バックアップに入っている暗号の鍵まで。試していない守りも書いています。
公開
動作確認: — n8n 2.41.6 / ConoHa VPS 1GB / Ubuntu 24.04
自分のパソコンで動かしている n8n は、外から見えません。 VPS に置いて、LINE の通知やスマホの承認ボタンを動かすには、外から届くようにする必要があります。 同時に、誰でも届く場所に、自分の n8n が出ていくことにもなります。
VPS に n8n を入れる手順で作った n8n（ConoHa VPS 1GB、n8n 2.41.6）を Web に開いて、 外から何に届くかを確かめました。この記事は、そこで分かったことと、公開前に確かめたいことをまとめたものです。
試したのは、検証用の使い捨ての n8n です。本番の認証情報は入れていません。 セキュリティの専門家による検査ではないので、「ここまで確かめた」と「確かめていない」を分けて書きます。
外から届くもの
ConoHa のセキュリティグループに IPv4v6-SSH と IPv4v6-Web を付けた状態です。
| 入口 | 外から | 確かめ方 |
|---|---|---|
| 22番（SSH） | 届く。鍵がないと入れない | サーバーの設定を見た（パスワードでのログインは無効、鍵だけ） |
| 80・443番（Web） | 届く。http は https に切り替わる | 外から https に接続した |
| 5678番（n8n 本体） | 届かない | 外から接続して、応答がないことを確かめた |
注意したいのは、80・443番に届いたものを、Caddy がすべて n8n に渡すことです（テンプレートの設定を読んで確認しました）。 そのため、次のものが、インターネットのどこからでも届きます。
- n8n のログイン画面（エディタ）
- Webhook の URL
- 承認・フォームのリンク
- MCP の入口
n8n に届く手前で守ってくれるものは、ありません。守りは、n8n 自身の認証だけです。
順番：アカウントを作ってから、外に開く
n8n は、最初にアクセスした人が、オーナーのアカウントを作る作りです。 アカウントを作る前に Web に開くと、先に見つけた人がオーナーになれます。
筆者の環境では、パスワードを忘れて、アカウントを作り直せる状態にしました（n8n user-management:reset）。
その直後、n8n の画面は「最初のアカウントを作る」状態に戻りました。ここでも、同じことが起きます。
- 申し込んだら、セキュリティグループは SSH だけにしておく
- SSH のトンネルで手元から開いて、アカウントを作る
- そのあとで、Web を足す
- アカウントを作り直すときは、先に Web を外す（外す手順そのものは試していません）
手順はVPS に n8n を入れる手順に書いています。
5678番が閉じていたのは、ConoHa の設定のおかげ
テンプレートは、Ubuntu のファイアウォール（ufw）で、22・80・443だけを許可しています。
ところが、n8n の Docker の設定は、5678:5678 として、5678番を全体に向けて公開する形でした。
Docker は、ufw を通り越してポートを開くことがあります。
今回、外から5678番に届かなかったのは、ConoHa のセキュリティグループが、80と443しか通していないためでした。 つまり、守っていたのは、サーバーの中のファイアウォールではなく、ConoHa 側の設定です。
Webhook と承認リンクは、URL を知っていれば誰でも開ける
外から届く入口のうち、ログインが要らないものがあります。
- Webhook の URL：検証用に作った Webhook に、ログインしていない状態で外から接続すると、そのまま応答が返りました。n8n のログインは、Webhook には関係しません
- 承認・フォームのリンク：Send and Wait や Wait ノードの待機フォームのリンクは、スマホで、ログインなしで開けました。2.41 のリンクには、64桁の署名（
?signature=…）が付いていました
署名は、n8n が作ったリンクかどうかを確かめるためのものです。誰が押したかは確かめません （Send and Wait の使い方）。 メールを転送したり、複数人が見るアドレスに送ったりすると、見た人なら誰でも押せます。
Webhook に送られてくるものが、本当に相手のサービスからなのかを確かめたいときは、署名の検証や認証をワークフローに入れます。
たとえば、LINE の通知は、受け取った内容の署名を確かめる作りにしました（LINE対応自動化ワークフロー）。
Webhook ノードには、Authentication という設定があります（Basic・Header・JWT）。ただし、筆者はこの設定を試していません（Webhookノードの使い方の記事も None で検証しています）。
MCP の入口が、外に見えている
MCP の入口（/mcp-server/http）も、外から届きます。ログインしていない状態では、401（認証が必要）が返りました。
- 使っていないなら、n8n の Settings の「Instance-level MCP」を無効にしておくのが安全です（無効にした状態で、入口が閉じることまでは確かめていません）
- 使うなら、許可した Claude Code は、そのアカウントでできる操作を、MCP の入口を通して行えます。ツールの一覧には、ワークフローの作成と実行のほか、認証情報の一覧やコミュニティノードの追加もありました（VPS の n8n に MCP でつなぐ）
試していない守り
次のものは、確かめていません。公開する前に、自分の環境で調べてください。
- ログイン画面への総当たり（パスワードを何度も試される）への対策。 n8n 側にどんな制限があるかは、確かめていません。パスワードは、長いものにしてください
- ConoHa のセキュリティグループで、Web を自分の IP アドレスだけに絞ること。
IPv4v6-Webは、誰からでも通します。絞ったグループを作れば、ログイン画面を外に見せない形にできるはずですが、試していません。その場合、LINE のように外のサービスから届く Webhook も止まります - Caddy で、Webhook のパスだけを通し、管理画面を隠すこと。 テンプレートの Caddy は、全部を n8n に渡します。パスで分ける設定は、試していません
- サーバー自体の更新（Ubuntu の更新）
- n8n の脆弱性への対応。 テンプレートは
latestのイメージを使っています。バージョンが固定されていません。更新の手順も、試していません
暗号の鍵と、パスワードの扱い
- バックアップに、認証情報を読むための鍵が入っています。 ボリュームを丸ごと保存すると、鍵も入ります（手順の記事）。そのファイルを持っている人は、認証情報を全部読めます
- パスワードを忘れても、メールでは直せません。 メールの設定がないためです。パスワードはパスワード管理のアプリに保存してください
- テンプレートが、
/root/n8n-info.txtに、ユーザーn8n-userのパスワードを、そのまま（平文で）書きます。 中身は、ここには載せません。このファイルの権限は確かめていません。不要なら、消すか、中身を控えて別の場所にしまってください - SSH は、パスワードでのログインが無効で、鍵だけです。ただし、root で入れる設定です。鍵のファイル（
.pem）は、無くすと入れなくなり、盗まれると誰でも入れます
公開する前の確認
| 確認すること | このサーバーでは |
|---|---|
| アカウントを作ってから、外に開いたか | 作ってから開いた |
| 5678番に、外から届かないか | 届かなかった |
| 使っていない MCP の入口を、閉じているか | 試していない |
| Webhook に、認証か署名の検証が付いているか | 検証用なので付けていない |
| パスワードは、長くて、保存してあるか | 長いものを保存した |
| バックアップは、鍵ごと安全な場所にあるか | サーバーの中だけ |
| 本番の認証情報を、置いていないか | 置いていない（ダミーのみ） |
確認していないこと
- n8n の脆弱性や、攻撃を受けたときの動きは、確かめていません。この記事は、外から届くものの一覧と、順番の注意で、安全を保証するものではありません
- VPS は ConoHa の1GB だけです。ほかの会社のサーバーでは、セキュリティグループの代わりの仕組みが違います
- n8n Cloud の守りは、この記事の対象外です
次に読む
- 手順をたどるなら ConoHa VPSにn8nを入れる
- MCP の入口を使うなら VPS の n8n に MCP でつなぐ
- 動かす場所を選ぶところから読むなら n8nはどこで動かすか