この色の機能は、オプションのプラグインによって提供されています。
概要
Caddyは、HTTPサーバー、TLS証明書マネージャー、PKI機能など、さまざまなアプリケーションを実行できる、本質的に構成管理システムです。 configモジュールと呼ばれるプラグインで拡張できます。
Caddyは、柔軟で強力なHTTPリバースプロキシ、オンライン構成API、堅牢で本番環境対応の静的ファイルサーバーを備えており、自動TLS証明書を使用してすべてのサイトをHTTPS経由で提供します。
全体的なプログラム技術仕様
言語
Webサーバーにとって言語の選択は非常に重要です。言語は、開発速度と容易さ、パフォーマンス、テスト、展開の複雑さ、エコシステムの信頼性、依存関係、ツール、エラー処理と信頼性などに影響を与えます。Goはこれらのすべての分野で大きな利点を提供し、迅速な開発、堅牢な本番パフォーマンス、高いスケーラビリティを実現します。
Go
メモリーセーフティの保証
ほとんどのサーバー（NGINX、Apache、HAProxyなど）とその依存関係はCで記述されており、Heartbleedのような壊滅的なメモリーセーフティのバグ（バッファーオーバーフローなど）に対して脆弱です。CaddyのようなGoプログラムは、一連のセキュリティの脆弱性に対して影響を受けません。
強力
ビルドアートファクト
CaddyはネイティブCPU命令に直接コンパイルされます。インタープリターは必要ありません。多くの命令はアーキテクチャに最適化されています。静的バイナリは、動的リンクがないためより安全です。
プラットフォームネイティブの静的バイナリ
ランタイム依存関係
Caddyは静的にコンパイルされます。動的にリンクされたアプリケーションは、本番環境で簡単に破損し、共有実行可能リソースがシステム内のさまざまな場所からロードされるためセキュリティが低い可能性があります。一般的に、Caddyバイナリは、libcでさえ外部ライブラリを必ずしも必要としません。
なし
コンパイル時間
コンシューマーハードウェアでは、標準的なCaddyビルドはわずか数秒でコンパイルされます。これは、迅速な反復、プラグイン開発、低コストの展開に不可欠です。C / C ++で記述された他のサーバーは数分かかります。
コールドビルド約30秒、
ホットビルド約2秒
ホットビルド約2秒
展開環境
Caddyは事実上どこにでも配置でき、さまざまな方法で展開できます。一般的に、アップグレードはバイナリを置き換えるだけという単純さで済みます。
- コマンドラインインターフェース
- システムサービス
- コンテナ
- Kubernetes
- 組み込み
サプライチェーンとリリース
Goモジュールは依存関係の整合性を検証し、リリースアーティファクトに暗号署名するため、信頼できるものかどうかがわかります。
暗号検証済み
オペレーティングシステム
Caddyは、Goがコンパイルされるすべての主要なプラットフォームで動作します。
- Linux
- Windows
- macOS
- FreeBSD
- OpenBSD
- NetBSD
- Android
マイクロアーキテクチャ
多数のCPUプラットフォームでネイティブコードを使用してCaddyを実行します。
- x86（i386、i686）
- x86-64（AMD64）
- ARM
- ARM 64（AArch64）
- MIPS
- MIPS64[LE]
- PPC64[LE]
- RISCV64
- S390X
- Apple Silicon（Apple ARM; M1、M2など）
正規表現エンジン
Caddyの正規表現言語は、Thompson NFAに基づいており、他のWebサーバーで使用されているPCREよりも多くのパフォーマンスの向上があります。実行時のコストが指数関数的にではなく線形に増加することが保証されています。これは、信頼できない入力の評価に最適です。
RE2
同時実行モデル
Goのランタイムは、ゴルーチンと呼ばれる軽量なユーザー空間スレッドを使用して、オペレーティングシステムよりもスマートな方法でスケジュールされたCPU時間を最適化します。CaddyはすべてのCPUコアを利用し、毎秒数十万のリクエストを容易に処理します。
ゴルーチン（epoll + kqueue）
プラグインモデル
Caddyは、展開時やシステムアップグレード時に破損しない方法で、ネイティブコードとしてコンパイルされるコンパイル時プラグインによって拡張できます。IPCまたはRPC呼び出しがないため、Caddy拡張機能はネイティブコードと同等の性能を発揮します。
コンパイル時静的
高度な機能
構成変更
ゼロダウンタイムのグレースフルリロードにより、Caddyの実行中に構成を変更できます。強力な自動化のためにプログラム可能/スクリプト可能です。
- RESTful HTTP API
- 設定ファイル
- 安全なリモートアクセス
アプリモジュール
最上位の構成構造は、アプリモジュールまたはCaddyアプリと呼ばれます。これらはCaddyの機能の大部分を担っています。誰でもアプリモジュールを作成でき、Caddyにはいくつかの標準アプリが組み込まれています。
- HTTP
- TLS
- PKI
- イベント
- Raw TCPとUDP
- SSH
- PHP
- 動的DNS
- セキュリティ
- プロセス監視
- プロファイリング
ログ
すべてのCaddyモジュールは、Caddyの中央集権化されたロギング機能を使用します。Caddyのロギングは、フォーマット、冗長性、出力などを設定できます。
- レベル付き
- 構造化
- 高効率、ゼロアロケーション
- 拡張可能
- フィールドの削除、フィルタリング、改ざん、検閲
- IPマスキング
- ハッシュ値
- 正規表現置換
ストレージ
証明書やOCSPステープルを含むアセットと状態は、設定可能なストレージバックエンドに保存されます。実際、同じストレージで構成されたCaddyの複数のインスタンスは、クラスタの一部と見なされ、自動的に調整できます。
- ファイルシステム
- 組み込み（インメモリ）
- Postgres
- Redis
- Vault
- Consul
コマンドラインインターフェース
CaddyのCLIは便利であるだけでなく、役に立ちます。ほとんどのサーバーCLIは単にプロセスを実行して構成をリロードするだけですが、CaddyのCLIはさらに一歩進んで、最新のWebサーバーの管理を容易にします。
プラグインは独自のサブコマンドを登録してCaddyのCLIを拡張できます。
コマンドヘルプ
コマンドやフラグのスペルミス、引数の不足、サブコマンドの不明な場合、ヘルプテキストが自動的に表示されます。
caddy helpまたは-hを使用して、全体的なコマンドヘルプまたはサブコマンドヘルプにアクセスすることもできます。組み込み、自動（manページも生成可能）
管理APIラッパー
いくつかのサブコマンドは、ファイルからの構成のロードやサーバーの停止などの一般的なタスクを実行するのに役立つCLIで使用するための管理APIエンドポイントを使用します。
- 構成をJSONに適合させる
- サーバーを起動し、必要に応じて構成を使用する
- 構成をグレースフルにリロードする
- サーバーを停止する
バイナリユーティリティ
Caddyのカスタムビルドは非常に一般的であるため、ビルドの管理と詳細情報の取得に役立ついくつかのコマンドがあります。
- 詳細なビルドメタデータ
- インストールされている構成モジュールのリスト
- 依存関係のリスト
- プラグインパッケージの追加と削除
- バージョンの表示
- Caddyバイナリのアップグレード
構成ユーティリティ
設定ファイルを使用することを選択した場合、CaddyのCLIはそれらの管理に役立ちます。
- Caddyfileのフォーマット
- 構成の検証
- 依存関係のリスト
- プラグインパッケージの追加と削除
- バージョンの表示
モジュールユーティリティ
モジュールは独自のサブコマンドを登録して、構成ドキュメントなしで使用できる一般的な機能を提供できます。
- 静的ファイルサーバー
- HTTPリバースプロキシ
- 静的HTTP応答（テンプレート可能）
- ストレージのインポート/エクスポート（バックアップ/復元）
- HTTP基本認証で使用するパスワードのハッシュ化
- ファイル参照テンプレートのエクスポート
統合ユーティリティ
いくつかのサブコマンドは、Caddyをシェル環境に統合するのに役立ちます。
- シェル補完スクリプトの生成
- 環境の表示
- manページの生成
- Caddy管理のルートCAを信頼ストアにインストールする
- Caddy管理のルートCAを信頼ストアから削除する
システムシグナル
Caddyは、一般的なオペレーティングシステムのシグナル/割り込みをサポートしており、それぞれに微妙な動作の違いがあります。
- INT（グレースフル停止）
- QUIT
- TERM
終了コード
Caddyが正常に終了するかエラーで終了するかにかかわらず、終了コードは、プロセススーパーバイザーまたはスクリプトがどのように処理するかを示唆する可能性があります。
構成
Caddyは、その構成が機能へのアクセスを提供するだけでなく、それ自体が機能であるように設計されています。
どの構成ファイル形式が最適かについて議論する必要はもうありません。好きなものを使用してください！Caddyの構成アダプターを使用すると、好きな構成形式を使用できます。
ネイティブ構成形式
Caddyのネイティブ構成形式は遍在しています。ほぼすべてのオペレーティングシステム、プラットフォーム、プログラミング言語、およびAPIエコシステムにツールがあります。ほとんどの他の形式はJSONに変換でき、人間の可読性とプログラム可能性のバランスが取れています。Webサーバーの強力な味方になるでしょう。
JSON
構成アダプター
常に別の形式で構成を作成でき、構成アダプターを使用すると、Caddyはそれを暗黙的にJSONに変換するため、好きなものを使用できます。
- Caddyfile
- JSON 5
- JSON-C
- NGINX Conf
- YAML
- CUE
- TOML
- HCL
- Dhall
- MySQL
人間に優しい構成
Caddyfile は、その構文が寛容でありながら、可読性と記述容易性を考慮した構造で設計されているため、多くのユーザーがウェブサーバーの設定を手動で記述する際に最も好む方法です。自動的に JSON に変換されます。
Caddyfile
エクスポート
Caddy の管理 API を使用すると、シンプルな GET リクエストで、現在の設定に JSON 形式でランタイムアクセスできます。
設定 API
Caddy は API エンドポイントを介して設定を受け取りますが、JSON または設定アダプターが存在するその他の形式を受け入れることができます。
設定ファイル
設定の管理に通常のシェルコマンドを好む場合は、Caddy の CLI が API エンドポイントをラップします。
自動 HTTPS
CertMagic によって実現された、弊社の主力機能です。Caddy は、デフォルトで HTTPS を有効にし、すべてのサイトの証明書を自動的に取得および更新する、唯一の主要なサーバーです。
完全にネイティブで統合された自動 HTTPS は、外部ツールや cron ジョブを必要とするソリューションよりもはるかに優れています。Caddy の証明書メンテナンスは、他のどのソリューションよりも堅牢で、信頼性が高く、スケーラブルであるため、業界最高です。Caddy はインフラストラクチャを複雑化させるのではなく、簡素化します。
もちろん、Certbot と cron ジョブを使用して 10 万個のサイトをデプロイしようとできますが、それ自体がクラッシュしないとしても、ウェブサーバーはクラッシュします。Caddy だけが、TLS 証明書を水平方向と垂直方向の両方で大量にスケーリングするように設計されています。
CSR を手動で生成する必要はもうありません。メールのリンクをクリックして証明書をダウンロードする必要もありません。それらを使用するためにウェブサーバーを（誤って）設定する必要もありません。数ヶ月ごとに期限が切れる前に、証明書を一つずつ更新するリマインダーを見逃すこともありません。証明書や TLS について考える必要さえありません。
まさに自動魔法です。
コンプライアンス
Caddy の TLS *デフォルト* は、追加の設定なしで安全であり、さまざまな業界のコンプライアンステストに合格しています。
- PCI DSS 準拠
- NIST 準拠
- HIPAA 準拠
- 業界ベストプラクティス
オンデマンド TLS
自分のドメインではないドメインを提供している場合、または多数のドメインを持っている場合でも問題ありません！数行の設定だけで、オンデマンド TLS は TLS ハンドシェイク中に動的に証明書を取得し、デプロイメントを数万件の証明書にスケーリングします。この機能は Caddy 専用です。
証明書発行者
発行機関から、それらと互換性のある方法で証明書を取得します。証明書発行者は CSR を受け取り、証明書リソースを返します。ほとんどのサイトは、証明書の取得に ACME を使用します。しかし、Caddy は内部使用、テスト、または開発のために独自の自己署名証明書を発行することもできます。Caddy の発行元はプラグイン可能なので、Caddy は任意の発行元モジュールから証明書を自動化できます。
- ACME
- 内部（自己署名）
- Microsoft Active Directory Certificate Services
証明書マネージャー
発行者は CSR を受け取って Caddy が管理する必要がある証明書を返すのに対し、証明書マネージャーはオンデマンドで常に有効な証明書を返すことができるモジュールです。つまり、証明書を管理しています。Caddy は、HTTP エンドポイントまたは Tailscale とインターフェースしてこのように証明書を取得できます。プラグインを介して他の方法も利用できます。
- HTTP
- Tailscale
クラスタ調整
同じストレージで設定されたすべての Caddy インスタンス間で、Caddy はリソースをクラスタ全体で自動的に調整および共有します。これには、証明書操作と証明書自体、OCSP ステープル、およびセッションチケットキーが含まれます。これにより、クライアントのレイテンシが軽減され、スケーラビリティが向上します。
- 証明書の取得と更新
- 既存の証明書の読み込み
- OCSP ステープル
- セッションチケットキー (STEK)
HTTP から HTTPS へのリダイレクト
デフォルトでは、HTTP リクエストは HTTPS にリダイレクトされます。
自動リダイレクト
OCSP
OCSP は証明書の失効を示します。サーバーは証明書に OCSP 応答をステープルして、クライアントにより優れたセキュリティとプライバシーを提供する必要があります。Caddy は、これを自動的に、デフォルトで実行する最初のサーバーです。また、OCSP レスポンダの停止に対処するために応答をキャッシュし、クラスタ全体で共有します。必要に応じてすべてを無効にすることができます。
キャッシングによる自動 OCSP ステープリング
Must-Staple
CA がサポートしている場合、Caddy は OCSP ステープリングを強制する証明書を取得できます。これにより、失効の場合にセキュリティレベルが向上する可能性があります。
失効処理
失効した証明書は自動的に置き換えられます。Caddy は OCSP 応答をステープルして更新するため、証明書が失効したかどうかを検出でき、その場合は置き換えます。
セッションチケットの強化
攻撃者がセッションチケットを暗号化するキーを盗んだ場合、TLS 接続は無意味です。Caddy は、攻撃ウィンドウを制限するためにこれらのキーを定期的にローテーションする唯一のサーバーとして学術的に引用されています。
自動 STEK ローテーション
キーの種類
証明書に使用されるキーの種類をカスタマイズできます。
- Ed25519
- ECDSA P256
- ECDSA P384
- RSA 2048
- RSA 4096
証明書の有効期間
ほとんどの ACME クライアントは 90 日間の証明書を想定するか、7 日間未満の証明書を想定していません。Caddy は、時間と分の単位で有効期間を持つ証明書を正常に管理できます。
更新前に特定の期間をハードコーディングする代わりに、Caddy は各証明書の寿命に関連する期間を計算します。これは更新ウィンドウ比率と呼ばれます。デフォルトでは、Caddy は使用可能な寿命の 2/3 後に証明書を更新します。この比率はほとんどの有効期間に有効ですが、調整できます。
任意の有効期間
インテリジェントなエラー処理
Caddy が証明書を取得できない場合、エラーがログに記録され、Caddy は指数関数的にバックオフし、成功するまで必要に応じて再試行します（通常は最大 30 日間ですが、それ以上かかる場合があります）。Caddy は、証明書の更新を維持するためにあらゆる妥当な努力をします。
指数関数的バックオフ
組み込みのスロットリング
Caddy はベストプラクティスに準拠しており、CA に証明書のリクエストを大量に送信しません。代わりに、各注文は、CA サーバーを圧倒しないように慎重にタイミングが計られます。
ACME
Caddy の ACME クライアントは、現在利用可能な他の統合 ACME クライアントよりも信頼性が高く、本番環境での経験が豊富です。Caddy は Let's Encrypt の一般公開前から ACME を使用しており、Caddy は ACME 互換の CA で動作します。
互換性
一部の ACME クライアントは Let's Encrypt でのみテストされています。Caddy は、すべての ACME 対応 CA との互換性が保証されています。
すべての RFC 8555 準拠証明機関、たとえば
- Let's Encrypt
- ZeroSSL
- Google Trust Services
- BuyPass
- DigiCert
- GlobalSign
- SSL.com
- Smallstep
テストエンドポイント
デフォルトでは、証明書の取得に失敗した後に、Caddy は CA が設定した本番環境の速度制限に達しないように、CA のテストまたはステージングエンドポイント（存在する場合）にフォールバックします。これは、DNS 設定の検証専用に設定した ACME サーバーの場合もあります。
Let's Encrypt（その他は設定可能）
外部アカウントバインディング
必要に応じて外部アカウントバインディング (EAB) を設定して、Caddy が、別途アカウントを持つ必要がある CA と連携できるようにします。
チャレンジの種類
Caddy は主要な ACME チャレンジタイプをすべてサポートしており、他のタイプもサポートするように拡張できます。
- HTTP-01
- TLS-ALPN-01
- DNS-01
代替チャレンジポート
特定の ACME チャレンジは標準ポート 80 と 443 を使用する必要がありますが、ルーターを介して転送している場合は、Caddy は代替ポートでこれらをリッスンすることをサポートします。
- HTTP（デフォルト 80）
- TLS-ALPN（デフォルト 443）
スマートチャレンジの選択
Caddy は、成功する可能性が最も高いチャレンジタイプを学習し、最初にそれらを試みます。たとえば、ポート 80 がブロックされている場合、ポート 80 を使用しない TLS-ALPN チャレンジを優先するように学習します。
DNS チャレンジ統合
DNS チャレンジは、CA がサーバーにアクセスできる必要がない唯一のチャレンジです。libdns を介して数十の DNS プロバイダーの統合を使用して、DNS チャレンジを解決します。**このリストは不完全です。** DNS プロバイダーの完全なリストを参照してください。
- ACME-DNS
- AliDNS
- Cloudflare
- DigitalOcean
- DNSPod
- DuckDNS
- DynDNS
- EasyDNS
- Gandi
- GoDaddy
- Google Cloud DNS
- Hetzner
- Linode
- Name.com
- Namecheap
- Namesilo
- Netlify
- OVH
- Porkbun
- PowerDNS
- RFC 2136
- Route 53
- Scaleway
- Vercel
- Vultr
- すべてを見る...
信頼できる CA 証明書
選択した CA とやり取りする際に信頼するルート証明書をオプションで設定します。これは、公開 CA なしで信頼が確立されている内部 PKI に役立ちます。
優先チェーン
CA が複数の証明書チェーンを提供する場合、Caddy はダウンロードして使用するチェーンをカスタマイズする機能を提供します。
- 最小
- ルートの CommonName
- 任意の CommonName
HTTP サーバー
Caddy の HTTP サーバーは、強力で、拡張性が高く、効率的で、最新のものです。
HTTP バージョン
Caddy の HTTP サーバーは、主要な HTTP バージョンをすべてサポートし、デフォルトで有効にします（安全ではない H2C を除くが、利用可能です）。提供するバージョンを正確にカスタマイズできます。
- HTTP/1.1
- HTTP/2
- クリアテキスト上の HTTP/2 (H2C)
- HTTP/3
HTTPS
Caddy の主力機能は、HTTPS を自動的に、デフォルトで有効にすることです。その動作方法を制御したり、側面（HTTP リダイレクト、証明書管理、特定のホスト名など）を無効にしたりできます。
自動
リスンインターフェース
各 HTTP サーバーは、1 つ以上のソケットとネットワークインターフェースにバインドできます。ポートの場合、特定のホストインターフェースまたはポートだけのすべてのインターフェースを指定できます。すべての種類の Unix ソケットもサポートされています。
- TCP
- UDP
- Unix ソケット
リスナーラッパー
リスナーは、接続受け入れレベルで動作するモジュールによってラップできます。
- HTTPS ポートで HTTP をリダイレクト
- PROXY プロトコル
- Tailscale
タイムアウト
タイムアウトの設定は、本番環境にとって重要な防御策ですが、大規模なダウンロードやアップロードを行う正当な低速クライアントに対応するように注意深く調整する必要があります。
- 読み取りタイムアウト
- HTTP ヘッダーの読み取りタイムアウト
- 書き込みタイムアウト
- アイドルタイムアウト
- TCP キープアライブ間隔
全二重通信
HTTP/1 の同時読み書きは、すべてのクライアントでサポートされているわけではありませんが、それを必要とする特定のクライアントやアプリケーションに対して有効にすることができます。
- HTTP/1 で設定可能
- HTTP/2 のデフォルト
エラー処理
Caddy は、クライアントに最適な/望ましいエクスペリエンスを提供するために、エラー処理を完全に制御できます。
カスタムエラールート
TLS ターミネーション
（旧称「SSL」）TLS を終了します。適切なデフォルト値を使用し、カスタマイズして TLS ハンドシェイクを細かく制御できます。ServerName (SNI) やリモート IP などのさまざまな要因に基づいて、クライアントにポリシーを割り当てることができます。
- TLS 1.2
- TLS 1.3
- クライアント認証（TLS 相互認証; mTLS）
- クライアント認証モード：リクエスト、必須、指定された場合の検証、必須かつ検証
- 暗号スイート
- カーブ
- ALPN
- プロトコルバージョンの制限
- デフォルト SNI
- フォールバック SNI
クロスサイトセキュリティ
Caddy は多くの場合、同じソケットで複数のサイトを提供するため、Caddy は TLS クライアント認証が有効になっているサイトがある場合でも、サイトを安全に保つための保護を自動的に有効にします。
TLS ServerNameとHTTP Hostヘッダーの一致検証
アクセスログ
クライアントのリクエストとレスポンスを完全に理解するために、ゼロ割り当ての構造化アクセスログを有効化します。Caddyの組み込みロギング設定、またはサードパーティモジュールの使用によるカスタマイズが可能です。
- 共通ログ形式（CLF）よりも有用
- リクエストヘッダー（機密フィールドを除く）
- レスポンスヘッダー
- リモートIP
- レイテンシ
可観測性
Webサーバーは、標準に準拠したメトリクスを使用して監視できます。
Prometheusメトリクス、OpenTelemetry
リクエスト処理
HTTPサーバーは、定義した順序で特定のハンドラーからなるカスタムルートを使用してリクエストを処理します。カスタムエラー処理のために、個別のエラールートを定義することもできます。HTTP処理には高い柔軟性があります。利用可能なHTTPハンドラーモジュールについては、以下を参照してください。
合成可能なルート（および個別のエラー処理ルート）
リクエストフィルター
様々なプロパティに基づいてリクエストを分類するマッチャーを使用して、特定のリクエストのみにハンドラーを適用します。マッチャーはフィルタリングにも使用されます。拡張可能でプラグイン可能なので、ルートの特定性とカスタマイズに制限はありません！一部のマッチャーは正規表現をサポートしています。すべて非常に高速です。また、マッチャーはセットで組み合わせることができ、AND、OR、NOTロジックで結合できます。
- ホスト
- パス
- メソッド
- ヘッダー
- プロトコル
- リモートIP
- 任意のCEL式
- ファイル（存在、サイズ、変更日時）
- HTTPルート変数
- 論理否定
- 位置情報
- リモートホスト
HTTPハンドラー
ハンドラーは、着信リクエストを正確に希望する通りに処理するために、組み合わせて使用できるモジュールです。ハンドラーモジュールは、Caddyの他の部分と同様に、拡張可能でプラグイン可能です。ここにすべてのハンドラーをリストアップすることは現実的ではありません。
実際には、ハンドラーは、パス、ヘッダー、クエリ文字列、メソッドなど、様々なプロパティに基づいてリクエストをフィルタリングまたは分類するマッチャーとペアになっています。これにより、これらのハンドラーのすべてまたは一部を特定のリクエストに選択的に適用できます。
ACMEサーバー
Caddyには、すぐに使える本番環境対応のACMEサーバーが付属しており、内部PKIに最適です。インフラストラクチャ内のmTLS証明書を簡単に自動化できます。Smallstepライブラリによって実現されています。
Authelia
Autheliaを使用した認証によるセキュアリット
認証
拡張可能な認証モジュールを使用してユーザーを認証します。認証プロバイダーによって拡張され、ユーザーが設定されているプロバイダーによって認証できない場合、このハンドラーはエラーを返します。HTTP basic認証は標準で含まれており、他のサーバーとは異なり、basic認証の設定時にパスワードはハッシュ化されます（パスワードデータベースであるため）、セキュリティが強化されます。
- HTTP Basic認証
- JWT
- Discord
- フォーム
- SAML
高度な認証
Caddy-securityモジュールは、完全な認証と認可機能のスイートを備えており、様々な堅牢な認証ソリューションを提供します。
- フォームベース
- ローカル
- 基本
- LDAP
- OpenID Connect
- OAuth 2
- SAML
キャッシュ
キャッシュを簡単に有効化して、より多くのクライアントにサービスを提供し、パフォーマンスを向上させることができます。このキャッシュモジュールはRFC 7234に準拠しており、タグベースのキャッシュパージ、分散およびローカルストレージ、キー生成の調整などをサポートしています。複数のバックエンドがサポートされています！
- Badger
- Etcd
- NutsDB
- Olric
- Redis
エンコード
プラグイン可能なエンコーディングモジュールを使用して、HTTPレスポンスをオンザフライで圧縮、エンコード、またはその他の方法で変換します。レスポンスの圧縮は、1行の構成で簡単に実行でき、エンコードは既に圧縮形式であるレスポンスまたは小さすぎて価値がないレスポンスには適用されません。
- Gzip
- Zstandard (zstd)
- Brotli
ファイルサーバー
以下に詳細に説明されている、強力で柔軟性があり、効率的な静的ファイルサーバーです。
Goパッケージバニティパス
Goパッケージのバニティインポートパスを実装するシンプルなハンドラーです。
gRPC-Webブリッジング
バックエンドアプリのためにgRPC-WebリクエストをgRPCにブリッジ/変換します。
ヘッダー操作
HTTPリクエストとレスポンスヘッダーを変更します。ヘッダーフィールドへの文字列の追加、設定、削除、置換は高速ですが、高度な用途には正規表現もサポートされています。レスポンスヘッダーの操作は、レスポンスの書き込み開始時まで延期でき、レスポンスのステータスコードまたはヘッダー値に応じて条件付きで実行することもできます。
- 追加
- 設定（上書き）
- 削除
- 部分文字列置換
画像フィルタリング
画像をオンザフライで調整します。
- トリミング
- フィット
- 反転
- リサイズ
- 回転
- シャープニング
マップ
入力値に基づいて変数/プレースホルダー値を割り当てます。ルックアップテーブルに似ています。
Mercure
CaddyインスタンスをMercureハブにします。リアルタイム通信のためのオープンで簡単、高速、信頼性が高く、省電力なソリューションです。
メトリクス
Prometheus互換システムやその他の監視ツールで使用するための/metricsエンドポイントを公開します。
HTTP/2サーバープッシュ
HTTP/2を使用する場合、クライアントがリクエストする前にプロアクティブにリソースをクライアントにプッシュします。（ブラウザによって非推奨になる可能性がありますが、Caddyには特定のアプリケーションで役立つ有効な実装がまだあります。）
レート制限
リングバッファーとスライディングウィンドウアルゴリズムを使用して実装された、高度なエンタープライズグレードのレートリミッターは、ゾーンキーに基づいて大規模にスケーリングします。同じストレージを使用してCaddyインスタンスのクラスタを設定して、フリート全体でレート制限を分散します。他のエンタープライズサーバーのように、メモリバインドは必要ありません。
- ローカルまたは分散
- 複数のゾーン
- バッファー・プーリング
- ゴルーチンは1つだけ
- 構成可能なO(Kn)メモリ管理
- リロードによる状態の永続化
- Retry-Afterヘッダーの設定
- オプションのジッター
- 高度にプログラム可能
リクエストボディ制御
大きすぎるリクエストを拒否することにより、リクエストボディのサイズを制限します。
リバースプロキシ
Caddyには世界クラスのリバースプロキシがあり、詳細は以下のセクションで説明されています。
リクエストの書き換え
処理を続行する前に、リクエストに内部的な変更を加えます。これは、後で期待に準拠するように変更する必要があるリクエストを受け入れるのに役立ちます。メソッドやURIなど、リクエストの様々な側面を変更できます。
- メソッド
- URI（パス、クエリ文字列）
- パスのプレフィックスまたはサフィックスの削除
- 正規表現のサポート
- インテリジェントなURLエンコードとフォワードスラッシュの処理
静的レスポンス
構成に静的レスポンスをハードコードし、ステータスコード、ヘッダーフィールド、ボディを設定できます。（これは多くの場合、HTTPリダイレクトで応答するために使用されます。）その後、接続を正常に閉じることも、必要に応じて強制的に中断することもできます。
サブルーティング
ハンドラーを「サブルート」にグループ化して、複数のハンドラーを1つとして扱い、特定のロジックの推論を容易にします。
テンプレート
レスポンスはテンプレートとして評価でき、変数、if文、マークダウンレンダリング（フロントマターサポート付き）などを用いて、プロキシされたコンテンツや静的コンテンツを豊富で動的なコンテンツに変換できます。
トレース
OpenTelemetryを使用した分散トレースのサポート。
変数
リクエストの処理中に内部的に使用できる変数の読み書きを行います。
WebDAV
1行または2行の構成でWebDAVサーバーになります。ほとんどのWebDAVクライアントと互換性があります。
リバースプロキシ
Caddyは、世界で最も柔軟な汎用リバースプロキシであり、高度なリクエストとレスポンス処理、動的ルーティング、ヘルスチェック、ロードバランシング、サーキットブレーカーなどを備えています。
Caddyのプロキシをユニークにしているのは、その設計です。プロキシのクライアント側のみにHTTPが必要であり、バックエンドとのラウンドトリップを支えるトランスポートは、任意のプロトコルで実現できます！
さらに、プロキシは非常に動的なアップストリームでプログラムできます。つまり、利用可能なアップストリームは、処理中のリクエスト中に変更できます！バックエンドが利用できない場合、Caddyはバックエンドが利用可能になるまでリクエストを保持できます。
ハイレベルプロキシ機能
トランスポート
トランスポートは、Caddyがバックエンドからレスポンスを取得する方法です。Caddyのプロキシは、代替トランスポートモジュールを使用することで、HTTP以外のプロトコルのフロントエンドになることができます。これにより、CaddyはHTTPを話すことさえできないバックエンドからHTTPレスポンスを生成できます！
- HTTP
- FastCGI
- NTLM
ロードバランシング
アップストリームの選択は、最新のすべてのリバースプロキシの重要な機能です。Caddyには、あらゆる本番サービスに適した、さまざまな組み込みロードバランシングポリシーがあります。一部のポリシーは非常に高速で軽量です。他のポリシーは、クライアントまたはリクエストのプロパティに基づいてアップストリームアフィニティを提供します。他のポリシーは、接続をカウントしたり、ランダム性と重みを使用したりすることで、均等な分散を図ります。
- ランダム
- ランダム選択-N
- 最小接続数
- ラウンドロビン
- 加重ラウンドロビン
- 最初に利用可能なもの
- リモートIPハッシュ
- クライアントIPハッシュ
- URIハッシュ
- クエリハッシュ
- ヘッダーハッシュ
- Cookieハッシュ
サーキットブレーカー
サーキットブレーカーモジュールは、バックエンドが実際にダウンする前に一時的にバックエンドをダウンとしてマークして、稼働状態を維持できます。
レイテンシベース
ヘルスチェック
ヘルスチェックは、アップストリームが利用できない場合を検出します。パッシブヘルスチェックは、実際のリクエストからステータスを推測します。アクティブヘルスチェックは、クライアントリクエストの帯域外でバックグラウンドで動作します。
- アクティブ
- パッシブ
可観測性
管理APIは、プロキシアップストリームのトラフィックカウントとヘルスステータスを取得するためのエンドポイントを公開します。
アップストリームソース
Caddyは、さまざまな方法でアップストリームのリストを取得できます。最も一般的な方法は、構成に書き込むことです（静的）。他の方法は動的であり、各リクエストに対してアップストリームのリストが返されます（これらは構成可能なキャッシングを使用してパフォーマンスを向上させます）。
- 静的
- 動的：Aレコード
- 動的：SRVレコード
- 動的：複数のソースの組み合わせ
再試行
バックエンドがリクエストを正常に処理できるようになるまで、リクエストを再試行できます。この間、リクエストが保留中の間でも、アップストリームのリストが更新される可能性があります！
ストリーミング
レスポンスはクライアントに直接ストリーミングすることも、ワイヤパフォーマンスを向上させるためにわずかにバッファリングして定期的にフラッシュすることもできます。
信頼できるプロキシ
X-Forwarded-Forなどのプロキシ関連ヘッダーを使用するには、信頼できるプロキシのIP範囲のリストを指定できます。デフォルトでは、Caddyはクライアントを信頼しません。
ヘッダー操作
ヘッダーは、バックエンドへのリクエストとバックエンドからのレスポンスで変更できます。これは一般的なHTTPサーバーのヘッダーハンドラーに似ていますが、プロキシ中に適用されます。
- 追加
- 設定（上書き）
- 削除
- 部分文字列置換
バッファリング
プロキシは、フラッシュする前にボディ全体を読み取ることもできます。これにより、より多くのメモリを使用しますが、一部のバックエンドアプリケーションやクライアントでは、場合によっては必要になることがあります。
- リクエスト
- レスポンス
リクエストの書き換え
書き換えはプロキシとは異なる懸念事項であり、通常は別々に処理されますが、選択されたアップストリームなどのプロキシからの情報を使用してリクエストを書き換える必要がある場合があります。Caddyのプロキシを使用すると、これを行うことができます。
レスポンスのインターセプト
デフォルトでは、Caddyのプロキシはレスポンスをクライアントに単純に書き込みます。ただし、アップストリームのレスポンスをインターセプトして、他の方法で処理できます。これには、特定のレスポンスのみに一致し、指定したカスタムハンドラーチェーンを呼び出すことが含まれます。
アクティブヘルスチェック
アクティブヘルスチェックは、ヘルスチェックによってそれ以外が確認されるまで、デフォルトでバックエンドがダウンしていると想定します。
HTTPリクエストパラメーター
アクティブヘルスチェックは、アップストリームのHTTPエンドポイントに対して実行されます。これらのHTTPリクエストのパラメーターをカスタマイズして、ニーズに合わせて動作させることができます。
- パスとクエリ文字列
- ポート
- ヘッダー
タイミング
アクティブヘルスチェックを実行する間隔をカスタマイズできます。
成功基準
各アクティブヘルスチェックは、正常または異常な状態を決定するための基準のセットでカスタマイズできます。
- レスポンスタイムアウト
- HTTPステータスコード
- ボディへの正規表現の一致
障害時の安全性
バグや問題が発生しているバックエンドは、予期せず大きなレスポンスボディを返すことがあります。Caddyは、プロキシリソースを保護するためにこれを制限できます。
レスポンスサイズ制限
パッシブヘルスチェック
パッシブヘルスチェックは、プロキシリクエスト中に障害基準を満たすまで、バックエンドがデフォルトで稼働していると仮定します。
障害基準
すべてのパッシブヘルスチェックは接続障害をカウントします。さらに、リクエスト中にバックエンドを正常とみなすために必要な基準を追加で設定できます。
- 同時リクエスト制限超過
- HTTPステータス
- レイテンシ
障害メモリ
障害を記憶しておく時間と、バックエンドをダウンと見なすためにメモリに保持する必要がある障害の数をカスタマイズできます。
HTTPトランスポート
これはデフォルトのトランスポートモジュールです。バックエンドからHTTPレスポンスを取得するために、プロキシされたHTTPリクエストを作成します。
DNSリゾルバ
デフォルトではシステムリゾルバが使用されますが、プロキシハンドラごとにカスタムDNSリゾルバを指定できます。
TLS
Caddyは、アップストリームへのTLS（旧称SSL）をサポートするように設定できます。
- カスタムルートCAプール
- バックエンドへのクライアント認証
- カスタムハンドシェイクタイムアウト
- サーバーネームインジケーター（SNI）
- 再交渉レベル
- 特定のポートをTLSから除外
接続プーリング
バックエンドへの接続は、最大限の効率と最小限のレイテンシを実現するためにプールされます。
- HTTP Keep-Alive
- カスタムプローブ間隔
- 最大アイドル接続数（合計およびホストごと）
- アイドル接続タイムアウト
圧縮
Caddyは、バックエンドとのラウンドトリップの要求を圧縮できます。
Gzip
接続制限
ホストごとの接続数を制限できます。
PROXYプロトコル
アップストリームへの接続時に、PROXYプロトコルv1とv2の両方がサポートされています。
タイムアウト
さまざまなタイムアウトを設定できます。一部には適切なデフォルト値があります。
- 接続（ダイヤル）
- RFC 6555フォールバック
- レスポンスヘッダーの読み取り
- Expect continue
- 読み取り
- 書き込み
カスタムバッファサイズ
アプリケーションが特定の設定でより良いパフォーマンスを発揮する場合、読み取り/書き込みバッファのサイズを調整します。
- 読み取りバッファ
- 書き込みバッファ
HTTP バージョン
Caddyのプロキシは、バックエンドとの間で複数のHTTPバージョンをサポートしています。デフォルトでは、HTTP/1.1とHTTP/2がサポートされています。
- HTTP/1.1
- HTTP/2
- H2C（クリアテキスト上のHTTP/2）
FastCGIトランスポート
FastCGIは通常、php-fpmを介してPHPアプリケーションを提供するために使用されます。FastCGIレスポンダは、スクリプト名、ルートからの相対パスなど、実行中のスクリプトに関する追加情報が必要になる場合があり、CaddyのFastCGIトランスポートはそれらすべてを処理し、設定可能にします。
高効率
CaddyのFastCGIクライアント実装は、Cで記述されたメモリセーフではないクライアントのパフォーマンスに匹敵するように最適化されており、場合によってはそれらのパフォーマンスを上回ることさえあります。
パス分割
通常は拡張子でパスを分割して、適切なPATH_INFO変数を計算します。
ルートシンボリックリンクの解決
php-fpmを再起動せずにシンボリックリンクが変更された場合、シンボリックリンクに宣言されたパスを更新する必要があることをオプションで要求します。
環境変数
親環境から読み取り、CGIスクリプトのカスタム環境変数も設定します。
タイムアウト
リソースを節約するためにタイムアウトを設定します。
- ダイヤル（接続）
- 読み取り
- 書き込み
stderrのキャプチャ
Caddyは、アップストリームからのstderrへの出力をキャプチャし、可視性のためにログに記録できます。
静的ファイルサーバー
Caddyのファイルサーバーは、ウェブサイトの静的ファイルを配信するための主要な方法です。
シンプルです。ファイルを配信するルートディレクトリを指定すると、各リクエストパスは自動的にルートに追加されて、配信するファイルのフルパスを取得します。
カーネルアクセラレーション
Caddyは、可能な限りユーザー空間バッファをバイパスして、ファイルダウンロードの速度を大幅に向上させます。
sendfile
仮想ファイルシステム
デフォルトでは、Caddyはローカルディスクで指定したディレクトリからファイルを配信しますが、このファイルアクセスはプラグイン可能であり、任意の仮想化ファイルシステムモジュールに置き換えることができます。これにより、データベース、クラウドストレージ、またはWebサーバーバイナリに直接埋め込まれたアセットなど、任意のファイルストアから静的ファイルを配信できます。
- ローカルディスク
- 埋め込みアセット
- Amazon AWS S3
事前に圧縮されたファイル
デプロイメントパイプラインがサイトリソースを圧縮する場合、Caddyはそれらを自動的に検出して「事前に圧縮された」エンコーディングで配信し、効率とスループットを向上させることができます。
- Gzip
- Brotli
- Zstandard
ファイルとフォルダーの非表示
サイトルートに存在する可能性のある、機密性の高いファイルやフォルダーを事前に非表示にすることで、セキュリティ体制を強化できます。個々のファイル/フォルダーパス、パスに関係なくファイル名、または特定のパターンを持つファイル/フォルダーを非表示にするグロブマッチを指定できます。
正確なパス、ファイル名、グロブマッチング
インデックスファイル名
インデックスファイルは、クライアントによってディレクトリが要求された場合に配信されるファイルです。検索するインデックスファイルのファイル名はカスタマイズ可能です。要求されたディレクトリにインデックスファイルが見つからない場合は、ディレクトリのブラウジングをオプションで有効にできます。
index.html、index.txt（カスタマイズ可能）
条件付きリクエスト
Etag、Last-Modified、および関連ヘッダーがサポートされています。
- Etag
- Last-Modified
- If-Match
- If-None-Match
- If-Modified-Since
- If-Unmodified-Since
- If-Range
範囲リクエスト
大規模なファイルのストリーミングやダウンロードの再開によく使用されます。特定のファイル範囲を要求するクライアントは、失望したり驚いたりすることはありません。Caddyは、Rangeヘッダー付きのHTTPリクエストを適切に処理します。
正規パス
一般的に、単一のファイルまたはディレクトリには複数のURIがあります。例：/、/index.html、および/index.html/は同じリソースを表します。CaddyはHTTPリダイレクトを使用してパス正規化（ファイルからの末尾のスラッシュの削除、およびディレクトリへの追加）を強制します。
パススルーモード
ファイルが存在する場合にのみファイルを配信し、クライアントにエラーを返すのではなく、チェーン内の次のハンドラを続行する場合があります。
ファイルブラウザ
Caddyのファイルサーバーは、モバイルとデスクトップで魅力的に見える最新のファイルブラウザを通じて動作します。他の標準的なHTTPファイルサーバーよりも多くの機能とユーティリティがあります！
フォルダーリスト
そのフォルダーにインデックスファイル（下記）がない場合、フォルダー内のファイルのリストを表示します。
正確なパス、ファイル名、グロブマッチング
昼夜テーマ
カラースキームは、明るいか暗いかに関わらず、システムテーマに合わせて自動的に調整され、目がくらんだり、読みづらくなったりすることを防ぎます。
- ライトモード
- ダークモード
列でソート
スティッキー列ソートを使用して、各ディレクトリに関する情報を迅速に抽出し、アイテムをより迅速に見つけます。
- ファイル/ディレクトリ
- 名前
- サイズ
- 変更日時
フィルター
すべてのページ読み込み時に、カーソルが検索ボックスに自動的にフォーカスされるため、ファイル名を入力して大きなリストをすぐにフィルタリングできます。
レイアウト
リストの表示方法に応じて、ファイルをさまざまなレイアウトで表示できます。たとえば、グリッドビューはギャラリーに最適です。
- リスト
- グリッド
レスポンシブデザイン
ページの幅は、あらゆるサイズの画面に対応するように柔軟に調整されます。リンクは、タッチスクリーンで簡単にタップできるサイズになっており、情報量も十分です。
JSON API
Accept-Encoding: application/jsonヘッダー付きのリクエストには、JSONペイロードで応答され、ファイルリストへのプログラムによるアクセスまたはスクリプトによるアクセスが可能になります。カスタマイズ可能なリストテンプレート
デフォルトのテンプレートが適切でない場合、または機能を向上させたい場合は、ブラウズテンプレートをカスタマイズして、自由に見た目と動作を変更できます！
ファイルサイズ可視化
ファイルサイズは、ファイルの後ろにあるバーの長さで示されるため、異常値である大規模なファイルや小規模なファイルを見つけたり、相対サイズを一見して比較したりするのが簡単です。
ファイルタイプアイコン
ファイルサーバーは数十種類の一般的なファイルタイプを認識し、関連するアイコンを表示して、ページをスキャンするときの識別を容易にします。
Caddyは、多くの機能を備えた活発なプロジェクトです。このページは、言及すべきことが多すぎるため、Caddyによって提供されるすべての機能と利点を網羅したリストではありません。GitHubへの貢献を歓迎します！