新しいVPSを用意し、ドメインをそこに向け、あと1コマンドでWebサーバーが動き出す。次に打ち込むコマンドでCaddyかNginxのどちらかをインストールすることになり、その1つの判断が、そのサーバーを使い続ける間にTLSにどれだけの時間を費やすかを左右します。では、VPSでのCaddy対Nginx、どちらをインストールすべきでしょうか。
以下では、同じ3つの構成を両方のツールで設定して並べて示し、報告されているメモリの数値、ワイルドカード証明書の落とし穴、そしてすでにNginxを使っている場合の実用的な移行のポイントを取り上げます。
短いバージョン
- 結論: ほとんどの新規VPSのワークロード、特に個人開発者、小規模チーム、そして設定したら手をかけないTLSにはCaddyが向いています。そのモジュールのエコシステム、明示的なチューニング、既存のチームの専門知識、あるいは可能な限り小さいメモリ消費が必要なときはNginxを選びましょう。
- 自動HTTPS： Caddyは証明書の取得と更新を自ら行います。Certbotも、cronも、リロードのフックも不要です。NginxにはCertbot（または別のACMEクライアント）と、その周辺の更新の自動化が必要です。
- メモリ: NginxはGoではなくCで書かれているぶん軽量です。この差が最近のプランで何かを左右することはめったにありません。数値は下の表にあります。
- 落とし穴： Caddyはワイルドカードに関してはゼロ設定ではありません。*.example.comのような名前にはDNSチャレンジが必要で、それはプラグインとAPIトークンを意味します。
比較の全体を一画面で示します。
| Caddy | Nginx | |
|---|---|---|
| 言語 | Go | C |
| 自動HTTPS | 組み込み（Let's Encrypt + ZeroSSL） | なし。Certbotまたは別のACMEクライアントが必要 |
| 設定の冗長さ | 最小限（サイトあたり数行） | 明示的で冗長 |
| HTTP/3 | HTTPSでデフォルトで有効 | 1.25.0以降で利用可能。Nginxの設定で有効化する必要があります。ソースからのビルドには次が必要です。 --with-http_v3_module. |
| 報告されているアイドル時のメモリ | 15-25 MB | 2-8 MB |
| 1,000接続時に報告されているメモリ | 80-120 MB | 50-80 MB |
| モジュールのエコシステム | 小規模、xcaddyで拡張 | 大規模で成熟 |
| ライセンス | Apache 2.0 | BSD-2-Clause |
メモリの範囲の出典は あるサードパーティによるVPSのテスト であり、普遍的な要件ではなく、おおまかな傾向として扱うべきです。実際の使用量は、ソフトウェアのバージョン、有効なモジュール、ロギング、トラフィック、テスト手法によって異なります。バージョンとライセンスの情報は、各プロジェクトの公式リポジトリに基づいています。
Caddyの自動HTTPS（そして実際に何を置き換えるのか）
CaddyはTLS証明書の取得と更新を自ら行います。公開ドメインをサーバーに向けてCaddyを起動すれば、Let's EncryptまたはZeroSSLから証明書を取得し、その後バックグラウンドで更新します。Certbotも、cronジョブも、更新後のリロードフックも不要です。これがCaddyの自動HTTPSを一文で表したものであり、人々が乗り換える理由のすべてです。
内部では、Caddyは HTTP-01（port 80）またはTLS-ALPN-01（port 443）チャレンジ を使ってドメインの所有権を証明し、その後、2つ目のツールを一切関与させずに証明書を最新の状態に保ちます。
Nginxで同等のことを行うには、別のACMEクライアントを使います。一般的な certbot --nginx ワークフローでは、Certbotが証明書を取得してインストールし、その後、 更新時に同じプラグインと保存済みのオプションを再利用できます。ほとんどのCertbotのインストールには、自動的に実行されるスケジュールされたタスクも含まれています。 certbot renew 自動的に。
もし certbot certonly や、更新したファイルをディスクに書き込むだけの別のACMEクライアントを使う場合は、 デプロイフック を追加して、更新の成功後にNginxをリロードするようにしましょう。この構成でも機能しますが、それでもCaddyより可動部品が多く残ります。Webサーバー、ACMEクライアント、更新のスケジューラー、そして各種のデプロイフックが、別々のコンポーネントのまま残るのです。
Caddyの運用上の利点は、証明書の発行、配置、更新、そしてHTTPからHTTPSへのリダイレクトが、サーバー自体に統合されていることです。デフォルトでは、Caddyは証明書の有効期間のおよそ 3分の1が残った時点で更新を試み始めます。90日間の証明書なら30日です。ただし認証局が異なる更新期間を指定している場合を除きます。
プロのヒント： CaddyのデフォルトのACMEチャレンジには、port 80またはport 443での公開到達性が必要です。HTTP-01はport 80を、TLS-ALPN-01はport 443を使います。port 80がブロックされていても443が開いていれば、TLS-ALPNは動作する可能性があります。サーバーがインターネットに面していない場合は、下記のワイルドカード証明書と同じくDNS-01を使いましょう。
設定ファイルを並べて比較
ここでは、一般的な3つのVPSの構成、すなわちHTTPSリバースプロキシ、静的ファイルの配信、Basic認証を、両方のツールで記述しています。Caddyの例には自動HTTPSが含まれています。Nginxの例では証明書がすでに用意されていることを前提とし、静的ファイルとBasic認証の例ではHTTPSのserverブロックのみを示しています。HTTPからHTTPSへの同等の挙動が欲しい場合は、最初の例のport 80のリダイレクトブロックを再利用してください。
port 3000のローカルアプリへのリバースプロキシ：
Caddyfile
example.com {
reverse_proxy localhost:3000
}nginx.conf
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
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;
}
}
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}Nginxのブロック内のTLSの行は、Certbotがすでに実行済みであることを前提としています。上記のようなHTTPアップストリームの場合、Caddyは受信した Host ヘッダーをそのまま通し、 X-Forwarded-For, X-Forwarded-Proto、そして X-Forwarded-Host デフォルトで設定します。Nginxでは通常、アップストリームが元のホスト、スキーム、クライアントアドレスの連鎖を必要とするとき、プロキシヘッダーを明示的に追加します。これはトレードオフを凝縮したものです。Caddyは実用的なプロキシのデフォルトを備えて出荷されるのに対し、Nginxはその挙動の多くを明示的にさせます。
静的ファイルの配信：
Caddyfile
example.com {
root * /var/www
file_server
}nginx.conf
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}Basic認証、すべてをユーザー名とパスワードの背後で保護：
Caddyfile
example.com {
basic_auth {
Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
}
reverse_proxy localhost:3000
}nginx.conf
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
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;
}
}どちらのツールも、パスワードのハッシュ化は別途行います。Caddyは caddy hash-passwordを使い、Nginxは htpasswd を使って.htpasswdファイルを作成します。ディレクティブは、ちなみに現行のCaddyでは basic_auth です。以前は basicauth でしたが、v2.8.0で名称が変更されました。これは Caddyのbasic_authドキュメントに記載されており、古いチュートリアルでは今もこれで人々がつまずいています。
プロのヒント： Caddyfile内のそのハッシュはパスワードではありません。次のコマンドによるbcryptの出力です。
caddy hash-password。このコマンドを実行し、出力された内容を貼り付けます。Caddyは設定内の平文パスワードを拒否します。これは正しいデフォルトであり、最初は少し驚かされる点です。
設定そのものが答えを物語っています。CaddyはTLS、まっとうなプロキシヘッダー、そしてリダイレクトを数行にまとめます。Nginxは明示的で冗長であり、あらゆるつまみをあなたに委ねます。Nginxに何年も携わってきたなら、その冗長さは体に染みついた動作であり、制御できることこそが目的です。そうでないなら、Caddyfileは頭の中に収められる設定です。実用的なポイントはシンプルです。Caddyの設定は一目で読みやすく、Nginxはより明示的な制御を与えてくれます。
パフォーマンスとメモリ：ベンチマークを慎重に読む
公開されているテストは、おおむね同じ方向を指しています。Nginxはたいていメモリ使用量が少なく、素のスループットでも先行することが多いですが、その優位性の大きさは環境に大きく左右されます。
In あるサードパーティによる4コアVMのテストでは、Nginxが毎秒約48,000リクエストに達したのに対し、Caddyは約42,000でした。同じテストでは、HTTPSのp99レイテンシがNginxで2.1 ms、Caddyで2.4 msと報告されています。これらは普遍的な性能差ではなく、1つの構成での結果として扱ってください。
比較表のメモリの範囲の出典は、 別のVPSのテストです。さらに別の、 50,000同時接続での合成テスト では、Nginxが145 MB、Caddyが520 MBと報告されましたが、そのテストはハードウェアとワークロードの条件が大きく異なっていました。その絶対的な数値を、上記のVPSの数値と直接比較すべきではありません。
確実に言える結論はもっと限定的です。Nginxは一般にメモリ消費が小さく、高スループットや高並行性のワークロードで先行する傾向があります。ごく一般的な小〜中規模のVPSのリバースプロキシであれば、どちらも通常は十分に高速なので、運用のシンプルさのほうがしばしば有用な決め手になります。
このセクションの要点： サーバーのメモリに制約があるか、あるいは自分の負荷テストでプロキシのスループットがボトルネックだと示されない限り、運用面を基準に選びましょう。
ワイルドカード証明書の落とし穴（Caddyは常にゼロ設定とは限らない）
Caddyはワイルドカード証明書を自動化できますが、デフォルトのHTTP-01やTLS-ALPN-01チャレンジではできません。次の証明書には、 *.example.com DNS-01検証が必要です。これはLet's Encryptがワイルドカード証明書に対して義務づけているものです。つまり、DNSプロバイダーのプラグイン（xcaddyでCaddyのバイナリに組み込む）と、DNSホスト用のAPIトークンを、tlsブロック内に設定することを意味します。Caddyが宣伝しているような、1行書いて放っておけるという話ではありません。
これは、自分が管理する実在のドメインの下に多数のサービスを置くホームラボのユーザーを悩ませます。たとえば *.home.example.comのように置いて、ワイルドカードの発行が次と同じくらい自動的だと思い込む場合です。 app.example.com。次のような純粋に内部向けの名前については、 *.homelab.internal、それは公開のLet's Encryptのワイルドカードではなく、ローカル/内部のPKIの領域として扱いましょう。正確に言えば、Caddyはワイルドカードを問題なく扱えます。ただそれをデフォルトのチャレンジでは行わないだけであり、その設定は単一ドメインの場合より一段手間がかかります。ここではNginxも同じ立場です。DNS-01の要件はサーバーではなくLet's Encryptに由来するからです。
GUIが欲しい場合：Nginx Proxy Manager（少し脇道に）
Nginx Proxy Managerは、上記の2つのツールとはまったく別物であり、名前が人々を混乱させるため、一段落を割く価値があります。NPMはNginxをラップするGUIで、port 81のWebインターフェースを通じてリバースプロキシのルールとLet's Encryptの証明書を管理します。Nginx本体ではなく、Nginx本体のような設定方法でもありません。
そのトレードオフは、いつもの「クリックか設定ファイルか」というものです。NPMは、想定どおりの道筋から外れない限りは手軽なボタンです。その設定は、手で編集する単一の設定ファイルではなく、アプリケーションのデータベースを通じて管理されます。 デフォルトのDocker構成では SQLiteを使い、MySQL/MariaDBとPostgreSQLはサポートされている外部データベースの選択肢です。この違いは可搬性にも影響します。Caddyの構成は、多くの場合、 単一のCaddyfileをコピーするだけで移せますが、Nginx Proxy Managerの導入では、その アプリケーションのデータとデータベース を保持する必要があります。NPMは、編集よりもクリックを本当に好み、構成がシンプルなままであれば、良い選択肢です。Infrastructure as Codeのワークフローには不向きな選択です。
NginxからCaddyへの移行（何がそのまま移り、何が移らないか）
すでにNginxを使っていて移行を検討しているなら、まず自動化への期待を下げることから始めましょう。CaddyにはNGINX設定のアダプターがありますが、不完全であり、信頼できる一発の移行手段として扱うべきではありません。NginxからCaddyへの移行は、ほとんどが手作業での書き直しですが、その大半は短くなります。
そのまま移ってシンプルになるものは、 Caddyコミュニティの変換ガイド:
- によれば次のとおりです。HTTPアップストリームの場合、
reverse_proxyは受信したHostヘッダーをそのまま通し、 標準のX-Forwarded-*ヘッダーをデフォルトで設定します。そのため、それらのproxy_set_header行のほとんどは消えます。 - PHPは、
try_filesプラスfastcgi_passと大量のパラメータを伴うlocationブロックから、単一のphp_fastcgiディレクティブへと集約されます。 - WebSocketの処理はCaddy v2では自動です。チュートリアルが別途
websocketディレクティブを追加するよう指示していたら、それはCaddy v1の名残です。無視してください。
自動的には移らないものはこうです。Caddyにはない特定のNginxモジュールに紐づくもの、移植するのではなく考え直す必要のある複雑なrewriteやlocationのロジック、そしてワイルドカード証明書の設定です。ワイルドカード証明書は、上のセクションのDNSチャレンジの設定に逆戻りさせられます。モジュールとrewriteの分は時間を見込んでおきましょう。残りはたいてい、行数の正味の削減になります。
どちらをインストールすべきか？（結論）
設定、数値、ワイルドカードの落とし穴、そして移行のコストを見てきました。では、結論はこうです。個人開発者か小規模チームであり、これが新規VPSへの導入であり、設定したら手をかけないTLSが欲しく、シンプルなルーティングでDockerを動かしていて、あるいは体に染みつく設定が欲しいだけなら、Caddyをインストールしましょう。これを読んでいるほとんどの人が該当します。
きめ細かな制御や、その成熟したエコシステムからの特定のモジュールが必要なとき、メモリに制約のあるサーバーから性能を絞り出しているとき、高並行の静的ファイル配信を行っているとき、あるいはチームがすでに深いNginxの専門知識と動作実績のある大量の設定を持っているときは、Nginxをインストールしましょう。これらは確かな理由であり、そのうちの1つがあなたに当てはまるなら、Nginxが正しい選択です。これは、古いツールが間違ったツールだというケースではありません。
どちらに落ち着くにせよ、次の手順はそれをサーバーに導入することです。どちらも Caddy と Nginx 当社のマーケットプレイスでワンクリック導入が可能なので、インストール作業を省いて、そのままCaddyfileやserverブロックに取りかかれます。1 GBのVPSは、低トラフィックの単一サイトの導入には妥当な出発点ですが、プロキシ単体ではなく、プロキシの背後にあるアプリケーションとトラフィックに合わせてサーバーのサイズを決めましょう。Caddyをセルフホスト型サービスの玄関口として使うなら、 PrometheusとGrafanaの監視スタック や Uptime Kumaの導入 の前に、別途TLSのツールを必要とせずに配置できます。
このセクションの要点： Nginxを指し示す明確な理由がない限り、Caddyを選びましょう。
よくある質問
CaddyはCertbotを置き換えますか？
はい。Caddyはワイルドカード証明書を含む公開証明書の取得と更新を自ら行えるため、Certbotは不要です。 ワイルドカードにはDNS-01検証が必要です。つまり、対応するDNSプロバイダーのモジュールとAPIの認証情報を設定することを意味します。
CaddyはNginxよりメモリ使用量が少ないですか？
いいえ。Nginxのほうが一般にメモリ消費が小さいです。 あるサードパーティによるVPSのテスト では、アイドル時にNginxが2-8 MB、Caddyが15-25 MBと報告されましたが、これらの数値は固定的なメモリ要件ではなく、ワークロードに依存するものです。この差が最も効いてくるのは、複数のサービスを動かすメモリに制約のあるサーバーです。
CaddyはNginxより高速ですか？
ワークロードによります。どちらも通常、一般的なVPSのリバースプロキシのトラフィックには十分な速さです。 引用したテストでは、Nginxが素のスループットとメモリ効率で先行しましたが、その差の大きさは、 ハードウェア、トラフィックのパターン、並行性のレベルによって大きく変わりました。すべての導入に当てはまる単一の割合はありません。
CaddyはワイルドカードSSL証明書に対応していますか？
はい。次のようなワイルドカードです。 *.example.com DNS-01検証が必要です。Caddyに対応するDNSプロバイダーのモジュールとAPIの認証情報がそろえば、ワイルドカード証明書の取得と更新を自動的に行えます。
Nginx Proxy ManagerはNginxと同じですか？
いいえ。Nginx Proxy ManagerはNginxをラップするGUIで、設定をアプリケーションのデータベースに保存し、port 81のWeb UIを使い、そのインターフェースを通じてリバースプロキシのホストと証明書を管理します。Nginx本体はテキストファイルで設定され、独自のGUIは持ちません。
CaddyではなくNginxを使うべきなのはどんなときですか？
きめ細かな制御、その成熟したエコシステムからの特定のモジュール、メモリに制約のあるサーバーでの1 MBに至るまでの節約、高並行の静的ファイル配信が必要なとき、あるいはチームがすでに深いNginxの専門知識を持っているときは、Nginxを選びましょう。
