Caddyは2015年にMatt Holtが公開したGo製のWebサーバで、最大の特徴はTLS証明書を自動取得・更新する「自動HTTPS」を初期設定で有効にしている点にある。Caddyfileと呼ばれる簡潔な設定構文と、JSON APIによる動的構成、HTTP/3への早期対応など、現代的なWeb運用の負担を軽くする工夫が随所に施されている。本稿ではCaddyの誕生背景、自動HTTPSの仕組み、設定モデル、リバースプロキシ用途を中心に解説する。
この記事の目次
- Matt Holtと自動HTTPSの問題意識
- 自動HTTPSとACMEとの統合
- Caddyfileとリバースプロキシ運用
- NginxやTraefikと比べた使いどころ
- まとめ
Matt Holtと自動HTTPSの問題意識
Caddyの開発者Matt Holtは米ユタ州の研究者・開発者で、2014年末ごろのLet's Encrypt登場を受けてTLSの普及を阻む最大の要因が「証明書取得・更新の手間」であると考えた。2015年4月にCaddy 0.1を公開し、ACMEプロトコルによる証明書取得・更新を当初からサーバ本体に組み込んだ。
「Webサーバはデフォルトで安全であるべき」という考えのもと、Caddyは初期設定でHTTPSを有効にし、HTTP→HTTPSのリダイレクト、HSTS、OCSPステープリングまでをほぼ自動で構成する。後の2018年に1.0、2020年に2.0へとメジャー更新され、現在はZeroSSL対応やTailscale連携など、ネットワーク領域への広がりも見せている。
自動HTTPSとACMEとの統合
Caddyに公開ドメインを設定すると、起動時にACMEクライアントが走り、HTTP-01またはTLS-ALPN-01チャレンジで証明書を取得する。DNSベース認証が必要な場合はDNSプロバイダプラグインで拡張できる。取得した証明書は内部のストレージ（デフォルトでローカルファイル、必要に応じてRedisやS3など）に保管され、期限が近づくと自動更新される。
デフォルトではLet's EncryptとZeroSSLの両方を試行する仕組みになっており、片方が一時的に利用不可でももう一方で取得できる仕掛けが入っている。内部向けには自前のCAを発行してmTLSや内部TLSを構成することもでき、サーバ証明書まわりの運用負担を大幅に減らせる点が他のサーバと比べた最大の差別化要因である。
Caddyfileとリバースプロキシ運用
Caddyfileはexample.com { reverse_proxy localhost:8000 }のように、極めて簡潔な構文でリバースプロキシを構成できる。ヘルスチェック、ヘッダ操作、レート制限、Basic認証、ファイル配信、テンプレートレンダリングなど一通りのディレクティブが揃っており、FastAPI／Django／Node.jsアプリの前段に置く構成と相性が良い。
より高度な制御が必要な場合はJSON設定が使え、/loadエンドポイントへPOSTすることで実行中の構成を入れ替えられる。プラグインはGoモジュールとしてバイナリにコンパイルする方式で、xcaddyというビルダで自分の用途に必要なものだけを組み込める。HTTP/3はQUICサポートとして早い段階から有効化されており、最新プロトコルを意識しなくても自然と使える設計である。
NginxやTraefikと比べた使いどころ
Nginxは設定の細かさと枯れた安定性、豊富な事例が魅力だが、TLS自動化は別途certbotなどに頼る必要がある。TraefikはコンテナのサービスディスカバリとTLS自動化を同時に提供し、Kubernetesとの親和性が高い。Caddyはそれらの中間に位置し、シングルバイナリのシンプルさと自動HTTPSの強さを両立している。
個人ブログから中小規模のWebサービス、社内ツール、Tailscaleと組み合わせた内部TLSなど、「TLS運用に手間をかけたくない場面」では特に有効である。一方で大規模なロードバランシングや高度なルーティングが中心ならNginxやHAProxy、サービスメッシュとの統合ならTraefikやEnvoyのほうが向く。
まとめ
CaddyはMatt Holtが「Webはデフォルトで安全であるべき」という発想から作ったWebサーバで、自動HTTPSとシンプルな設定構文、HTTP/3対応などにより、TLS運用の負担を大きく減らす。規模や要件に応じてNginxやTraefikと使い分ければ、現代のWebインフラを軽快に構築できる頼れる選択肢となる。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント