VPS 上の Nginx Proxy Manager：レビューとセットアップガイド

NPM 対 Caddy 対 Traefik：どのリバースプロキシがあなたの VPS に合うか

3 つのツールは、選択を決める 4 つの軸で分かれます。どのように構成するか、HTTPS をどう扱うか、サービス数に応じてどうスケールするか、そしてアイドル時にどれだけの RAM を使うか。以下が比較です。

アイドル時 RAM の数値は次からのおおよその観測値です ある 2026 年の比較固定された要件ではありません。実際の使用量は、イメージのバージョン、有効化された機能、トラフィック、ログ出力によって異なります。

切り替えの基準は、その表から直接導かれます。ダッシュボードを求め、あまり変化しない少数のサービスを運用しているなら、NPM が適切なツールです。設定をコードとして扱いたい、最小のフットプリントを求める、または Caddy の次の点を評価するなら、 ACME の設定なしでの自動 HTTPS のプロビジョニングと更新Caddy を使ってください。私自身、単一サイトのデプロイでは Caddy に手を伸ばします。SSL 処理が自動で、Caddyfile が短いからです。コンテナを頻繁に追加、削除、再デプロイする場合、Traefik のラベルベースの自動検出により、新しいホストを毎回手作業で登録する必要がなくなります。

Certbot を組み合わせた素の Nginx もあり、精密な制御や非 Docker のデプロイのためにこれを好む管理者もいます。Certbot は証明書の更新を自動化できますが、バーチャルホストのルーティングと Nginx 構成は依然として自分で管理します。NPM を検討する主な理由が手動でのプロキシ構成を避けることであるなら、素の Nginx がより適している可能性は低いでしょう。

選択に関する 1 つの注意点：byte-guard の比較では、その比較において最も軽い選択肢として Caddy に落ち着いており、2026 年の新規な単一ホストのセットアップにはこれは妥当な選択です。Caddy は NPM より軽い点で勝りますが、特に GUI を求めるなら最善の選択肢ではありません。

基盤エンジンのより詳しい比較については、次を参照してください VPS 上の Caddy 対 Nginx の比較.

前提条件：必要になるもの

デプロイの前に、これらを用意しておいてください。短いリストですが、いずれかの項目を飛ばすと後で証明書のステップが失敗します。

• 次を備えた VPS Docker と Docker Compose がインストール済み （Ubuntu 22.04 LTS または Debian 12 で問題ありません）。
• ドメイン名。次を伴います DNS A レコード （IPv6 を使う場合は AAAA も）が VPS のパブリック IP を指していること。
• VPS への SSH アクセス。
• ファイアウォールでポート 80 と 443 がインターネットに開放されていること。
• ポート 81 は自分だけが到達可能で、一般には公開しないこと（セキュリティのセクションで扱います）。

Docker Compose を使って VPS に Nginx Proxy Manager をセットアップする

このセクションでは、Docker Compose を使って NPM をデプロイします。DNS レコードが VPS に解決されれば、コンテナのセットアップ自体は素早く済みますが、DNS の伝播と証明書の発行にはもっと時間がかかる場合があります。

このセットアップでは、1 つの Docker Compose ファイルと、共有 Docker ネットワークを作成する一度きりのコマンドを使います。ディレクトリを作成し、ネットワークを作成し、次を追加します docker-compose.yml 以下のファイルを追加し、コンテナを起動します。

まず、共有 Docker ネットワークを作成します：

docker network create proxy

次に、以下を作成します docker-compose.yml ファイル:

# docker-compose.yml
services:
  npm:
    image: 'jc21/nginx-proxy-manager:<PATCHED_VERSION>'
    restart: unless-stopped
    ports:
      - '80:80'                 # public HTTP
      - '443:443'               # public HTTPS
      - '127.0.0.1:81:81'       # admin UI, reachable only from the VPS itself
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    networks:
      - proxy
networks:
  proxy:
    external: true

NPM がサービス名で到達する必要のあるすべてのバックエンドコンテナを、同じ外部の次に接続します proxy ネットワークです。これにより NPM は、バックエンドアプリケーションのポートを VPS 上で公開することなく、サービス名でコンテナを解決できます。

両方をバックアップします ./data と ./letsencrypt アップグレードの前に。データディレクトリには NPM のデータベースと生成された構成が含まれ、Let's Encrypt ディレクトリには証明書の情報が含まれます。

このファイルについていくつか。イメージはデフォルトで、次に保存される SQLite データベースを使用します ./data ボリュームです。これはデフォルトのバックエンドで、ほとんどの単一 VPS デプロイに適しています。外部データベースが必要な場合、NPM は MariaDB/MySQL と PostgreSQL をサポートしており、その場合はデータベースサービスと対応する環境変数を追加します。単一 VPS では、データベースをデータボリュームの外に移す明確な理由がない限り、SQLite が依然として最もシンプルなデフォルトです。 restart: unless-stopped ポリシーは、VPS が再起動しても NPM が復帰することを意味し、これは他のすべての前面に位置するサービスにとって望ましい動作です。

起動して、動作していることを確認します：

docker compose up -d
docker compose ps

想定される出力： npm 状態が次のコンテナ Upポート 80 と 443 がパブリックにマッピングされ、ポート 81 は次のみにバインドされています 127.0.0.1。NPM が JWT キーを生成し、データベースを初期化し、デフォルトの管理者ユーザーを作成する間、初回起動には数分かかります。 公式のセットアップドキュメント がこの初回実行のシーケンスを説明しています。

管理インターフェースを開く前に、ローカルコンピューターから SSH トンネルを作成します：

ssh -L 8181:127.0.0.1:81 user@your-vps

次に開きます http://127.0.0.1:8181 ブラウザで。新規インストールでは、次でサインインします [email protected] と changemeそしてただちにデフォルトのメールアドレスとパスワードを置き換えます。デフォルトの認証情報が有効な間は、ダッシュボードを一般に到達可能にしないでください。

管理者の認証情報を変更したら、最初のプロキシホストを追加します：

1. ダッシュボードで、次に移動します Hosts、続いて Proxy Hosts、続いて Add Proxy Host.
2. 設定する ドメイン名 を自分のサブドメインに（例えば cloud.example.com).
3. 設定 転送ホスト名 / IP をバックエンドのコンテナ名または IP に、そして 転送ポート をそれが待ち受けるポートに。
4. 保存します。プロキシホストが一覧に表示され、そのサブドメインへのトラフィックがコンテナに到達するようになります。

これと並行して Docker 管理 UI を実行している場合も、同じパターンが当てはまります。同じ方法でサブドメインをコンテナ管理ツールに向け、次についても同じことを行います PrometheusとGrafanaの監視スタック プロキシの背後に置きたいもの。

サブドメインの自動 HTTPS を構成する

このセクションでは、サブドメイン用の有効で自動更新される Let's Encrypt 証明書を取得します。前提条件は人がつまずきやすいものです。そのサブドメインの DNS A レコードがすでに VPS を指している必要があり、ポート 80 がインターネットから到達可能である必要があります。Let's Encrypt がドメインに接続し直して検証するためです。

プロキシホストを作成したら、証明書を要求します：

1. プロキシホストを編集し、次を開きます SSL タブ。
2. 以下 SSL証明書選択してください 新しい SSL 証明書を要求.
3. 有効にする SSL を強制 と HTTP/2 サポート。HSTS は HTTPS が正しく動作していることを確認してからのみ有効にしてください。ブラウザがポリシーをキャッシュするため、証明書やプロキシ構成の誤りからの回復がより難しくなる可能性があるからです。
4. Let's Encrypt の規約に同意して保存します。

デフォルトでは、NPM は非ワイルドカードの名前に HTTP-01 チャレンジを使用し、要求された各ホスト名をポート 80 経由で検証します。1 つの証明書は複数の非ワイルドカード名を含められますが、HTTP-01 はワイルドカード証明書を発行できません。次のようなワイルドカード名は *.example.com サポートされた DNS プロバイダーを用いた DNS-01 チャレンジが必要です。サービスごとに 1 サブドメインという通常のセットアップでは、必要なのは HTTP-01 だけであり、更新は自動です。

Nginx Proxy Manager 向けに VPS をサイジングする

NPM 自体は軽量で、サイジングの問題は実際には NPM に加えてその背後にあるサービスに関するものです。プロキシのアイドル時のフットプリントが制約になることはめったにありません。Nextcloud インスタンスや Ghost ブログは、プロキシ自体よりも多くのリソースを使います。

実際には、各ティアは次のようになります：

• 実用的な最小の基準線：1 GB RAM、1 vCPU、10 GB ストレージ。 1つ サードパーティのサイジングガイド も同じ基準線を使っていますが、これは NPM の公式要件ではなく計画の目安として扱ってください。NPM、オペレーティングシステム、いくつかの軽いサービスには十分ですが、余裕は限られます。
• 快適：2 GB RAM、1 vCPU、20 GB ストレージ。 NPM に加えて 3〜5 個のサービスを、余裕を持って動かせます。これはほとんどのセルフホスターにとって最適な水準です。
• ステップアップ：4 GB RAM、2 vCPU。 8〜12 個のサービス、または相応のトラフィックがあり、TLS 終端のための CPU の余裕を確保したいセットアップ向け。

サイジングの基準となる数字は、NPM ではなくプロキシされるアプリの合計です。実行予定のサービスの RAM フットプリントを合計し、その上にプロキシの小さなアイドル時オーバーヘッドを加え、それを余裕を持って上回るティアを選んでください。

サーバーのサイジングは簡単な部分です。NPM を動かすには、依然として VPS のプロビジョニング、Docker のインストール、イメージの取得、そしてあの初回実行のセットアップを進める必要があります。プロビジョニングのステップを省きたいなら、Cloudzy のマーケットプレイスにはワンクリックの次があります Nginx Proxy Manager のデプロイ NVMe VPS 上で。新しいサーバー上でコンテナを起動するので、すぐにダッシュボードと最初のプロキシホストに進めます。いずれにせよ、プロビジョニングの基準となるのは上記のサイジングティアです。

よくある質問