Caddy vs nginx：HTTPS、設定、どちらを選ぶか
Caddy vs nginx
Caddy vs nginx：自動HTTPSと設定を並べて比較 | We.Inc
Caddyとnginxを実際の用途で比較します。自動HTTPS、静的サイト、リバースプロキシ、負荷分散、WebSocketを取り上げ、あなたのドメイン用に両方の設定を書き出すビルダーも用意しました。
最大の違いは証明書です。Caddyはデフォルトですべてのサイトを HTTPS で配信し、Let's EncryptやZeroSSLから証明書を取得・更新し、HTTPからのリダイレクトも自動で行います。nginxでは、ACMEクライアントや別途用意するACMEモジュールで取得した証明書ファイルを自分で用意する必要があります。Caddyfileのほうが短く書け、nginxはより細かい制御と、はるかに長い実績を持っています。
日常的な用途でのCaddyとnginxの比較
- HTTPS証明書
- 設定にある公開ドメインはすべて自動
- ssl_certificateでファイルを指定するか、別途ngx_http_acme_moduleを追加
- HTTPからHTTPSへのリダイレクト
- 自動
- 301を返す80番ポート用のサーバーブロック
- 圧縮
- encode zstd gzip
- gzip on
- リバースプロキシ
- reverse_proxy localhost:3000
- ロケーション内のproxy_passとヘッダー設定
- プロキシ経由のWebSocket
- 自動で処理
- UpgradeヘッダーとConnectionヘッダーを転送
- 能動的ヘルスチェック
- reverse_proxy内のhealth_uri
- health_checkは商用版のみ
- 設定チェックとリロード
- caddy validate, caddy reload
- nginx -t, nginx -s reload
多くの比較は機能の一覧で終わります。ここでは、ドメインとアプリのポートを入力すると両方の設定が得られるので、同じ結果を得るためにそれぞれのサーバーがどれだけ書かせるかを正確に確認できます。ビルダーの下には、よくある用途の設定を並べたスニペットと、それぞれが向いている場面についての率直な解説があります。
- ドメインを入力し、サーバーに静的ファイルを配信させるか、リクエストをアプリに転送させるかを選びます。
- 圧縮とwwwのリダイレクトを切り替えて、それぞれのサーバーにどの行が必要かを確認します。
- Caddyfileはcaddyのバイナリと同じ場所にコピーして caddy run を実行し、nginxのブロックはサイト用フォルダーの中のファイルにコピーします。
- nginxの場合は、まずACMEクライアントで証明書を取得し、リロードする前に2つの証明書パスを更新してください。
- Caddyが公開証明書を取得できるのは、ドメインのAレコードかAAAAレコードがそのマシンを指し、80番と443番のポートに外部から到達できる場合だけです。
- Caddyのデータディレクトリには、永続的で書き込み可能なストレージを用意しましょう。コンテナではボリュームをマウントしないと、再起動のたびに新しい証明書を要求してしまいます。
- 手で編集したCaddyfileには caddy fmt を実行しましょう。インデントを毎回同じ形に整えてくれます。
- nginxでは、リロードの前に毎回 nginx -t でテストしましょう。構文を確認するだけでなく、証明書のパスなど、設定が参照するファイルを開けるかも確かめます。
- Caddy 2.8以降、ルートディレクティブにワイルドカードのマッチャーは不要になったので、root /srv と書けます。root * /srv と書いている古いガイドも引き続き有効です。
よくある質問
Caddyはnginxをそのまま置き換えられますか？
静的サイト、リバースプロキシ、シンプルな負荷分散なら、たいていは置き換えられ、設定も短くなります。多数のサードパーティモジュール、複雑なマップやリライトのロジック、チューニングしたキャッシュを使う大規模な構成には、Caddyで1対1に対応するものがないこともあるので、1サイトずつ書き換えてテストしましょう。
今のnginxは自動HTTPSに対応していますか？
ACMEを実装したngx_http_acme_moduleがありますが、デフォルトではビルドに含まれていません。別の動的モジュール（nginx-module-acmeパッケージ）としてインストールし、発行元を設定する必要があります。これがなければ、証明書は外部のクライアントから取得します。
Caddyでlocalhostにも HTTPS を使えますか？
使えます。localhostや内部向けの名前に対して、Caddyは独自のローカル認証局を作成し、そこから証明書を発行します。システムから、そのルート証明書を信頼するかどうか一度だけ確認されることがあります。
性能が良いのはどちらですか？
速度の数値は、ハードウェア、TLSの設定、ワークロードによって大きく変わるため公開していません。どちらも一般的なWebサイトやAPIなら余裕をもって処理できます。純粋なスループットが重要なら、自分のサーバーで自分のトラフィックパターンを使ってベンチマークしましょう。
Caddyは負荷分散とヘルスチェックに対応していますか？
対応しています。reverse_proxyに複数のアップストリームを列挙し、round_robinやleast_connなどのlb_policyを選び、能動的なチェックにはhealth_uri、受動的なチェックにはfail_durationを追加します。ポリシーを指定しない場合、Caddyはアップストリームをランダムに選びます。
自動HTTPSが実際にカバーする範囲
- Caddyfileに公開ドメインが書かれていると、CaddyはACMEで証明書を取得し、443番でサイトを配信し、80番ポートをHTTPSへリダイレクトし、バックグラウンドで証明書を更新します。ある発行元で失敗すると再試行し、別の発行元に切り替えることもできます。デフォルトを変えたい場合を除き、設定にTLSについて書く必要はありません。
- nginxでは、これは自分で行う必要があります。一般的なのは、証明書ファイルを書き出して更新後にリロードするACMEクライアントを使う方法か、意図的にインストールする新しいACMEモジュールを使う方法です。
nginxのほうが向いている場合
- nginxはディストリビューション、コンテナイメージ、ホスティングのコントロールパネルなど、あらゆる場所にあり、ほぼどんな状況にもドキュメントや回答が見つかります。すでに運用しているチーム、特定のモジュールに依存しているチーム、バッファリングやキャッシュを細かく制御する必要があるチームには、移行する理由はほとんどありません。
Caddyのほうが向いている場合
- 小さなチーム、個人プロジェクト、多数のドメインを扱う場合は、証明書を管理しなくて済むことの恩恵が最も大きくなります。ネイティブの設定形式はJSONで、caddy adapt でCaddyfileから生成できます。caddy reload は管理APIを通じて、実行中のプロセスに新しい設定をダウンタイムなしで反映します。
3台のアプリサーバーに負荷分散する
Caddyfile
3つのバックエンドにラウンドロビンで振り分け、/healthz に対してバックグラウンドでヘルスチェックを行います。
ラウンドロビンがデフォルトです。オープンソース版は、失敗したリクエストを通じた受動的なヘルスチェックしか行いません。
WebSocketのプロキシ
Caddyfile
reverse_proxyがアップグレードを行い、追加の行なしで双方向のトンネルを開いたままにします。
UpgradeヘッダーとConnectionヘッダーは明示的に転送する必要があります。nginx 1.29.7より前のバージョンでは proxy_http_version 1.1 も必要です。
サーバーの役割
静的ファイルを配信
アプリへのリバースプロキシ
ファイルのあるフォルダー
このマシン上のアプリのポート
レスポンスを圧縮
wwwをwwwなしのドメインへリダイレクト
Caddyfile
{n}行
無料で始める · クレジットカード不要
関連: ガイド｜Webマーケティングと集客を学ぶ
製品
ご利用いただける方
機能
リソース
会社情報
サイトマップを見る