ドキュメント
プロジェクト

グローバルオプション

Caddyfileでは、グローバルに適用されるオプションを指定する方法があります。一部のオプションはデフォルト値として機能し、他のオプションはHTTPサーバーをカスタマイズし、特定のサイトだけに適用されるわけではありません。さらに他のオプションは、Caddyfile アダプターの動作をカスタマイズします。

Caddyfileの最上部は、グローバルオプションブロックにすることができます。これはキーを持たないブロックです。

{
	...
}

最大で1つしか存在できず、Caddyfileの最初のブロックである必要があります。

使用可能なオプションは次のとおりです（各オプションをクリックしてドキュメントにジャンプしてください）

{
	# General Options
	debug
	http_port    <port>
	https_port   <port>
	default_bind <hosts...>
	order <dir1> first|last|[before|after <dir2>]
	storage <module_name> {
		<options...>
	}
	storage_clean_interval <duration>
	admin   off|<addr> {
		origins <origins...>
		enforce_origin
	}
	persist_config off
	log [name] {
		output  <writer_module> ...
		format  <encoder_module> ...
		level   <level>
		include <namespaces...>
		exclude <namespaces...>
	}
	grace_period   <duration>
	shutdown_delay <duration>

	# TLS Options
	auto_https off|disable_redirects|ignore_loaded_certs|disable_certs
	email <yours>
	default_sni <name>
	fallback_sni <name>
	local_certs
	skip_install_trust
	acme_ca <directory_url>
	acme_ca_root <pem_file>
	acme_eab {
		key_id <key_id>
		mac_key <mac_key>
	}
	acme_dns <provider> ...
	on_demand_tls {
		ask      <endpoint>
		interval <duration>
		burst    <n>
	}
	key_type ed25519|p256|p384|rsa2048|rsa4096
	cert_issuer <name> ...
	renew_interval <duration>
	ocsp_interval  <duration>
	ocsp_stapling off
	preferred_chains [smallest] {
		root_common_name <common_names...>
		any_common_name  <common_names...>
	}

	# Server Options
	servers [<listener_address>] {
		name <name>
		listener_wrappers {
			<listener_wrappers...>
		}
		timeouts {
			read_body   <duration>
			read_header <duration>
			write       <duration>
			idle        <duration>
		}
		trusted_proxies <module> ...
		client_ip_headers <headers...>
		metrics
		max_header_size <size>
		enable_full_duplex
		log_credentials
		protocols [h1|h2|h2c|h3]
		strict_sni_host [on|insecure_off]
	}

	# PKI Options
	pki {
		ca [<id>] {
			name                  <name>
			root_cn               <name>
			intermediate_cn       <name>
			intermediate_lifetime <duration>
			root {
				format <format>
				cert   <path>
				key    <path>
			}
			intermediate {
				format <format>
				cert   <path>
				key    <path>
			}
		}
	}

	# Event options
	events {
		on <event> <handler...>
	}
}

一般オプション

debug

デバッグモードを有効にします。これは、デフォルトのロガーのログレベルをDEBUGに設定します。これにより、トラブルシューティングに役立つ詳細情報が表示されます（本番環境では非常に冗長です）。コミュニティフォーラムでヘルプを求める前に、これを有効にすることをお勧めします。たとえば、Caddyfileの先頭に、他のグローバルオプションがない場合

{
	debug
}
http_port

サーバーがHTTPに使用するポート。

内部使用のみです。クライアントのHTTPポートは変更されません。これは通常、内部ネットワーク内で、ルーティングのためにCaddyに到達する前に80を別のポート（例：8080）にポートフォワードする必要がある場合に使用されます。

デフォルト：80

https_port

サーバーがHTTPSに使用するポート。

内部使用のみです。クライアントのHTTPSポートは変更されません。これは通常、内部ネットワーク内で、ルーティングのためにCaddyに到達する前に443を別のポート（例：8443）にポートフォワードする必要がある場合に使用されます。

デフォルト：443

default_bind

サイトでbindディレクティブが使用されていない場合、すべてのサイトに使用されるデフォルトのバインドアドレス。デフォルト：空で、すべてのインターフェースにバインドします。

{
	default_bind 10.0.0.1
}
order

HTTPハンドラーディレクティブに順序を割り当てます。HTTPハンドラーは順次チェーンで実行されるため、ハンドラーを正しい順序で実行する必要があります。標準ディレクティブには定義済みの順序がありますが、サードパーティのHTTPハンドラーモジュールを使用する場合は、このオプションを使用するか、routeブロックにディレクティブを配置して、順序を明示的に定義する必要があります。順序付けは、絶対的に（firstまたはlast）、または別のディレクティブに対して相対的に（beforeまたはafter）記述できます。

たとえば、replace-responseプラグインを使用するには、レスポンスがエンコードされる前に置換を実行できるように、そのディレクティブがencodeの後に順序付けられていることを確認する必要があります（レスポンスはハンドラーチェーンを下に流れるのではなく、上に流れるためです）。

{
	order replace after encode
}
storage

Caddyのストレージメカニズムを設定します。デフォルトは`file_system`です。プラグインとして提供される他の多くのストレージモジュールがあります。

たとえば、ファイルシステムのストレージの場所を変更するには、次のようにします。

{
	storage file_system /path/to/custom/location
}

Caddyの複数のインスタンス間でCaddyのストレージを同期して、すべて同じ証明書とキーを使用するようにするには、通常、ストレージモジュールのカスタマイズが必要です。詳細については、ストレージに関する自動HTTPSセクションを参照してください。

storage_clean_interval

古いまたは期限切れのアセットをスキャンして削除する頻度。これらのスキャンは、ストレージモジュールに対して多くの読み取り（およびリスト操作）を実行するため、大規模なデプロイメントの場合は、より長い間隔を選択してください。期間値を受け入れます。

ストレージは、プロセスが最初に開始されたときに常にクリーンアップされます。その後、前のクリーニングが開始されてからこの期間後に新しいクリーニングが開始されます。ただし、前のクリーニングがこの間隔の半分の時間未満で終了した場合に限ります（そうでない場合は、次の開始はスキップされます）。

デフォルト：`24h`

{
	storage_clean_interval 7d
}
admin

管理APIエンドポイントをカスタマイズします. プレースホルダーを受け入れます。 ネットワークアドレスを取ります.

デフォルト: `localhost:2019`、ただし`CADDY_ADMIN`環境変数が設定されている場合を除きます.

`off`に設定すると、管理エンドポイントは無効になります. 無効にすると、`caddy reload`コマンドは管理APIを使用して新しい設定を実行中のサーバーにプッシュするため、サーバーを停止して再起動せずに**設定を変更することはできません**.

実行中のサーバーのアドレスがデフォルトから変更された場合、互換性のあるコマンドで`--address` CLIフラグを使用して、現在の管理エンドポイントを指定することを忘れないでください.

また、次のサブオプションもサポートしています.

  • **origins** エンドポイントへの接続が許可されているオリジンのリストを設定します.

    デフォルトはインテリジェントに選択されます.

    • リッスンアドレスがループバック（例：`localhost`またはループバックIP、またはunixソケット）の場合、許可されるオリジンは`localhost`、`::1`、`127.0.0.1`で、リッスンアドレスポートと結合されます（そのため、`localhost:2019`は有効なオリジンです）.
    • リッスンアドレスがループバックでない場合、許可されるオリジンはリッスンアドレスと同じです.

    リッスンアドレスホストがワイルドカードインターフェースでない場合（ワイルドカードには、空の文字列、または`0.0.0.0`、または`[::]`が含まれます）、`Host`ヘッダーの強制が実行されます. 実際には、これはデフォルトでは、インターフェースが`localhost`であるため、`Host`ヘッダーが`origins`にあることが検証されることを意味します. ただし、ワイルドカードインターフェースを持つ`:2020`のようなアドレスの場合、`Host`ヘッダーの検証は実行されません.

  • **enforce_origin** `Origin`リクエストヘッダーの強制を有効にします.

    これは、リッスンアドレスがワイルドカードインターフェースであり（`Host`は検証されないため）、管理APIがパブリックインターネットに公開されている場合に最も役立ちます. CORSプリフライトチェックを有効にし、`Origin`ヘッダーが`origins`リストに対して検証されるようにします. 開発マシンでCaddyを実行していて、Webブラウザーから管理APIにアクセスする必要がある場合にのみ使用してください.

たとえば、すべてのインターフェースで異なるポートで管理APIを公開するには、—⚠️このポートは**公に公開しないでください**. そうしないと、誰でもサーバーを制御できます. 公開する必要がある場合は、オリジンの強制を有効にすることを検討してください.

{
	admin :2020
}

管理APIを無効にするには、—⚠️これにより、サーバーを停止して再起動せずに**設定の再読み込みができなくなります**.

{
	admin off
}

ファイルのアクセス許可によるアクセス制御を許可する、管理APIにunixソケットを使用するには、次のようにします.

{
	admin unix//run/caddy-admin.sock
}

一致する`Origin`ヘッダーを持つリクエストのみを許可するには、次のようにします.

{
	admin :2019 {
		origins localhost
		enforce_origin
	}
}
persist_config

管理APIを介して実行された設定変更が失われないように、現在のJSON設定を設定ディレクトリに永続化するかどうかを制御します. 現在、`off`オプションのみがサポートされています. デフォルトでは、設定は永続化されます.

{
	persist_config off
}
log

名前付きロガーを設定します.

名前を渡して、動作をカスタマイズする特定のロガーを示すことができます. 名前が指定されていない場合、`default`ロガーの動作が変更されます. `default`ロガーの詳細とCaddyでのロギングの仕組みの説明を読むことができます.

`log`を複数回使用することにより、異なる名前の複数のロガーを設定できます.

これは、HTTPリクエストロギング（アクセスログとも呼ばれます）のみを設定する`log`ディレクティブとは異なります. `log`グローバルオプションは、その設定構造をディレクティブと共有します（`include`と`exclude`を除く）. 完全なドキュメントは、ディレクティブのページにあります.

  • **output** ログの書き込み先を設定します.

    完全なドキュメントについては、`log`ディレクティブを参照してください.

  • **format** ログのエンコードまたはフォーマット方法を記述します.

    完全なドキュメントについては、`log`ディレクティブを参照してください.

  • **level** ログに記録する最小のエントリレベルです.

    デフォルト: `INFO`.

    可能な値: `DEBUG`、`INFO`、`WARN`、`ERROR`、およびまれに`PANIC`、`FATAL`.

  • **include** このロガーに含めるログ名を指定します.

    デフォルトでは、このリストは空です（つまり、すべてのログが含まれます）.

    たとえば、管理APIによって出力されたログのみを含めるには、`admin.api`を含めます.

  • **exclude** このロガーから除外するログ名を指定します.

    デフォルトでは、このリストは空です（つまり、ログは除外されません）.

    たとえば、HTTPアクセスログのみを除外するには、`http.log.access`を除外します.

`include`と`exclude`が受け入れるロガー名は、使用されるモジュールによって異なり、それらを検出する最も簡単な方法は、以前のログからです.

すべてのhttpアクセスログと管理ログをstdoutにjsonとして記録する例を次に示します.

{
	log default {
		output stdout
		format json
		include http.log.access admin.api
	}
}
grace_period

HTTPサーバーのシャットダウン（つまり、設定の変更中またはCaddyの停止時）の猶予期間を定義します.

猶予期間中、新しい接続は受け入れられず、アイドル状態の接続は閉じられ、アクティブな接続はリクエストを完了するまで辛抱強く待機されます. クライアントが猶予期間内にリクエストを完了しない場合、再読み込みを完了し、リソースを解放するために、サーバーは強制終了されます. 期間値を受け入れます.

デフォルトでは、猶予期間は永遠です。つまり、接続は強制的に閉じられることはありません.

{
	grace_period 10s
}
shutdown_delay

停止されるサーバーが正常に動作し続ける猶予期間の*前*の期間を定義します. ただし、`{http.shutting_down}`プレースホルダーは`true`と評価され、`{http.time_until_shutdown}`は猶予期間が開始されるまでの時間を示します.

これは、設定変更の一部としてサーバーがシャットダウンされている場合に遅延を引き起こし、事実上、変更を後の時刻にスケジュールします。 このサーバーの差し迫った終焉をヘルスチェッカーに通知し、ロードバランサーがローテーションから除外する時間を与えるのに役立ちます。 例えば

{
	shutdown_delay 30s
}

example.com {
	handle /health-check {
		@goingDown vars {http.shutting_down} true
		respond @goingDown "Bye-bye in {http.time_until_shutdown}" 503
		respond 200
	}
	handle {
		respond "Hello, world!"
	}
}

TLS オプション

auto_https

Caddy がサイトの証明書管理と HTTP から HTTPS へのリダイレクトを自動化できるようにする機能である自動 HTTPSを設定します。

選択できるモードがいくつかあります

  • off：証明書の自動化と HTTP から HTTPS へのリダイレクトの両方を無効にします。

  • disable_redirects：HTTP から HTTPS へのリダイレクトのみを無効にします。

  • disable_certs：証明書の自動化のみを無効にします。

  • ignore_loaded_certs：手動でロードされた証明書に名前が表示されている場合でも、証明書を自動化します。 tls ディレクティブを使用して、代わりに自動的に管理したい名前（またはワイルドカード）を含む証明書を指定した場合に役立ちます。

{
	auto_https disable_redirects
}
email

あなたのメールアドレス。 主に CA で ACME アカウントを作成するときに使用され、証明書に問題が発生した場合に強く推奨されます。

{
	email admin@example.com
}
default_sni

クライアントが ClientHello で SNI を使用しない場合のデフォルトの TLS ServerName を設定します。

{
	default_sni example.com
}
fallback_sni

⚠️ *実験的*

設定されている場合、元の ServerName がキャッシュ内の証明書と一致しない場合、フォールバックは ClientHello の TLS ServerName になります。

これは非常に特殊な用途に使用されます。 通常、クライアントが CDN であり、ダウンストリームハンドシェイクの ServerName をパススルーするが、代わりにオリジンのホスト名を持つ証明書を受け入れることができる場合は、これをオリジンのホスト名として設定します。 Caddy はこの名前の証明書を管理している必要があることに注意してください。

{
	fallback_sni example.com
}
local_certs

デフォルトでは、Let's Encrypt などの（パブリック）ACME CA を介さずに、**すべて**の証明書が内部で発行されるようになります。 これは、開発環境で簡単に切り替えるのに役立ちます。

{
	local_certs
}
skip_install_trust

ローカル CA のルートをシステムの信頼ストア、および Java と Mozilla Firefox の信頼ストアにインストールしようとしないでください。

{
	skip_install_trust
}
acme_ca

ACME CA のディレクトリへの URL を指定します。 テストまたは開発には、これを Let's Encrypt のステージングエンドポイント に設定することを強くお勧めします。 デフォルト：ZeroSSL と Let's Encrypt の本番エンドポイント。

グローバルに設定された ACME CA がすべてのサイトに適用されない場合があることに注意してください。 デフォルトの ACME 発行者を使用するためのホスト名要件を参照してください。

{
	acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}
acme_ca_root

システムの信頼ストアにない場合、ACME CA エンドポイントの信頼できるルート証明書を含む PEM ファイルを指定します。

{
	acme_ca_root /path/to/ca/root.pem
}
acme_eab

すべての ACME トランザクションに使用する外部アカウントバインディングを指定します。

たとえば、モック ZeroSSL 資格情報を使用すると

{
	acme_eab {
		key_id GD-VvWydSVFuss_GhBwYQQ
		mac_key MjXU3MH-Z0WQ7piMAnVsCpD1shgMiWx6ggPWiTmydgUaj7dWWWfQfA
	}
}
acme_dns

すべての ACME トランザクションに使用するACME DNS チャレンジプロバイダーを設定します。

DNS プロバイダーのプラグインを使用して、Caddy をカスタムビルドする必要があります。

プロバイダーの名前の後に続くトークンは、tls ディレクティブの acme 発行者で指定されている場合と同じようにプロバイダーを設定します。

{
	acme_dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
on_demand_tls

オンデマンド TLSが有効になっている場所を設定しますが、有効にしません（有効にするには、tls ディレクティブの on_demand サブディレクティブを使用します）。 乱用を防ぐために、本番環境での使用が必要です。

  • ask は、Caddy に指定された URL に HTTP リクエストを実行させ、ドメインに証明書を発行できるかどうかを尋ねます。

    リクエストには、ドメイン名の値を含む ?domain= のクエリ文字列があります。

    エンドポイントが 2xx ステータスコードを返すと、Caddy はその名前の証明書を取得する権限を与えられます。 他のステータスコードは、証明書の発行をキャンセルし、TLS ハンドシェイクでエラーが発生します。

  • interval と burst を使用すると、<duration> 間隔内に <n> 証明書操作を実行できます。
{
	on_demand_tls {
		ask http://localhost:9123/ask
	}
}

https:// {
	tls {
		on_demand
	}
}
key_type

TLS 証明書に生成するキーのタイプを指定します。 カスタマイズする必要がある場合にのみ、これを変更してください。

可能な値は、ed25519、p256、p384、rsa2048、rsa4096 です。

{
	key_type ed25519
}
cert_issuer

TLS 証明書の発行者（またはソース）を定義します。

これにより、tls ディレクティブの issuer サブディレクティブを使用する場合のように、サイトごとではなく、グローバルに発行者を設定できます。

試したい発行者が複数ある場合は、繰り返すことができます。 それらは定義された順序で試行されます。

{
	cert_issuer acme {
		...
	}
	cert_issuer zerossl {
		...
	}
}
renew_interval

ロードされ、管理されているすべての証明書の有効期限をスキャンし、有効期限が切れている場合は更新をトリガーする頻度。

デフォルト：10m

{
	renew_interval 30m
}
ocsp_interval

OCSP ステープル を更新する必要があるかどうかを確認する頻度。

デフォルト：1h

{
	ocsp_interval 2h
}
ocsp_stapling

OCSP ステープリングを無効にするには、off に設定できます。 ファイアウォールのためにレスポンダーにアクセスできない環境で役立ちます。

{
	ocsp_stapling off
}
preferred_chains

CA が複数の証明書チェーンを提供している場合、このオプションを使用して、Caddy がどのチェーンを優先するかを指定できます。 次のオプションのいずれかを設定します

  • smallest は、Caddy にバイト数が最も少ないチェーンを優先するように指示します。

  • root_common_name は、1 つ以上の共通名のリストです。 Caddy は、指定された共通名の少なくとも 1 つと一致するルートを持つ最初のチェーンを選択します。

  • any_common_name は、1 つ以上の共通名のリストです。 Caddy は、指定された共通名の少なくとも 1 つと一致する発行者を持つ最初のチェーンを選択します。

preferred_chains をグローバルオプションとして指定すると、オーバーライドする発行者レベルの設定がない場合、すべての発行者に影響することに注意してください。

{
	preferred_chains smallest
}

{
	preferred_chains {
		root_common_name "ISRG Root X2"
	}
}

サーバーオプション

HTTP サーバーを、複数のサイトにまたがる可能性のある設定でカスタマイズします。そのため、サイトブロックで正しく設定できません。 これらのオプションは、リスナー/ソケット、または HTTP 層の下にある他の機能に影響します。

異なる listener_address 値で複数回指定して、サーバーごとに異なるオプションを設定できます。 たとえば、servers :443 は、リスナーアドレス :443 にバインドされているサーバーにのみ適用されます。 リスナーアドレスを省略すると、残りのサーバーにオプションが適用されます。

たとえば、ポート :80 と :443 のサーバーに異なるオプションを設定するには、2 つの servers ブロックを指定します

{
	servers :443 {
		listener_wrappers {
			http_redirect
			tls
		}
	}

	servers :80 {
		protocols h1 h2c
	}
}

servers を使用すると、Caddyfile に**実際に表示される**サーバー（つまり、サイトブロックによって生成されるサーバー）に**のみ**適用されます。 自動 HTTPS は、ポート 80（または http_port オプション）でリッスンするサーバーを作成して、HTTP->HTTPS リダイレクトを提供し、ACME HTTP チャレンジを解決します。 これは実行時、つまり Caddyfile アダプターが servers を適用した*後*に発生します。 つまり、http:// や :80 のようなサイトブロックを明示的に宣言しない限り、servers は :80 には**適用されません**。

name

このサーバーに割り当てるカスタム名。 通常、ログやメトリックで名前でサーバーを識別するのに役立ちます。 設定されていない場合、Caddy は srvX パターンを使用して動的に定義します。ここで、X は 0 で始まり、設定内のサーバーの数に基づいて増加します。

設定内のサイトブロックによって生成されたサーバーにのみ設定が適用されることに注意してください。 自動 HTTPS は実行時に :80 サーバー（または http_port）を作成するため、名前を変更する場合は、少なくとも空の http:// サイトブロックが必要です。

例えば

{
	servers :443 {
		name https
	}
	
	servers :80 {
		name http
	}
}

example.com {
}

http:// {
}
listener_wrappers

リスナーラッパーの設定を許可します。これにより、ソケットリスナーの動作を変更できます。 指定された順序で適用されます。

標準モジュールとして提供される特別な操作なしの tls リスナーラッパーがあり、TLS をリスナーラッパーのチェーンのどこで処理するかをマークします。 別のリスナーラッパーを TLS ハンドシェイクの前に配置する必要がある場合にのみ使用する必要があります。 これはサーバーの TLS を*有効にしません*。 たとえば、これが :80 HTTP サーバーで使用されている場合でも、操作なしとして機能します。

付属の http_redirect リスナーラッパーは、受信リクエストの最初の数バイトを調べて HTTP（TLS ではなく）である可能性があるかどうかを判断し、同じポートで HTTP から HTTPS へのリダイレクトをトリガーできますが、https:// スキームを使用します。 これは、ブラウザがスキームが指定されていない限り HTTP を試行するため、非標準ポート（443 以外）で HTTPS を提供する場合に最も役立ちます。 これを HTTP サーバーで使用しないでください。 tls リスナーラッパーの*前*に配置する必要があります。 例えば

{
	servers {
		listener_wrappers {
			http_redirect
			tls
		}
	}
}

また、proxy_protocol リスナーラッパーも含まれています（v2.7.0 より前はプラグインを介してのみ利用可能でした）。これは、PROXY プロトコルの解析を有効にします（HAProxy によって普及）。 接続の開始時にプレーンテキストデータを解析するため、これは tls リスナーラッパーの*前*に使用する必要があります

{
	servers {
		listener_wrappers {
			proxy_protocol {
				timeout 2s
				allow 192.168.86.1/24 192.168.86.1/24
			}
			tls
		}
	}
}
timeouts

  • read_body は、クライアントのアップロードからの読み取りを許可する時間を設定する期間値です。 これを短くてゼロ以外の値に設定すると、slowloris 攻撃を軽減できますが、正当に遅いクライアントにも影響を与える可能性があります。 デフォルトはタイムアウトなしです。

  • read_header は、クライアントのリクエストヘッダーからの読み取りを許可する時間を設定する期間値です。 デフォルトはタイムアウトなしです。

  • write は、クライアントへの書き込みを許可する時間を設定する 期間値 です。大きなファイルを提供する際に小さな値を設定すると、正当に低速なクライアントに悪影響を与える可能性があります。デフォルトはタイムアウトなしです。

  • idle は、キープアライブが有効な場合に次のリクエストを待機する最大時間を設定する 期間値 です。リソースの枯渇を防ぐために、デフォルトは5分です。

{
	servers {
		timeouts {
			read_body   10s
			read_header 5s
			write       30s
			idle        10m
		}
	}
}
trusted_proxies

リクエストを信頼するべきプロキシサーバーのIP範囲（CIDR）を設定できます。デフォルトでは、プロキシは信頼されません。

これを有効にすると、信頼されたリクエストはHTTPヘッダーから解析された*実際の*クライアントIPを持ちます（デフォルトは X-Forwarded-For です。他のヘッダーを設定するには client_ip_headers を参照してください）。信頼されている場合、クライアントIPは アクセスログ に追加され、{client_ip} プレースホルダー として使用でき、client_ip マッチャー を使用できます。リクエストが信頼されたプロキシからのものでない場合、クライアントIPは直接の受信接続のリモートIPアドレスに設定されます。

一部のマッチャーまたはハンドラーは、リクエストの信頼ステータスを使用して決定を下す場合があります。たとえば、信頼されている場合、reverse_proxy ハンドラーは機密性の高い X-Forwarded-* リクエストヘッダーをプロキシして追加します。

現在、Caddyの標準ディストリビューションには static IPソースモジュール のみが含まれていますが、これはプラグインで 拡張 して動的なIP範囲のリストを維持できます。

static

信頼する静的（不変）なIP範囲（CIDR）のリストを受け取ります。

ショートカットとして、private_ranges を使用してすべてのプライベートIPv4およびIPv6範囲と一致させることができます。これは、次のすべての範囲を指定するのと同じです：192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 127.0.0.1/8 fd00::/8 ::1。

構文は次のとおりです

trusted_proxies static [private_ranges] <ranges...>

IPv4範囲とIPv6範囲の例を信頼する完全な例を次に示します

{
	servers {
		trusted_proxies static 12.34.56.0/24 1200:ab00::/32
	}
}
client_ip_headers

trusted_proxies と組み合わせて、クライアントのIPアドレスを決定するために使用するヘッダーを設定できます。デフォルトでは、X-Forwarded-For のみが考慮されます。複数のヘッダーフィールドを指定できます。その場合、最初の空でないヘッダー値が使用されます。

{
	servers {
		trusted_proxies static private_ranges
		client_ip_headers X-Forwarded-For X-Real-IP
	}
}
metrics

Prometheusメトリクスの収集を有効にします。メトリクスをスクレイピングする前に必要です。メトリクスは、非常にビジーなサーバーのパフォーマンスを低下させることに注意してください。（私たちのコミュニティはこれを改善するために取り組んでいます。ぜひご参加ください！）

{
	servers {
		metrics
	}
}
max_header_size

クライアントのHTTPリクエストヘッダーから解析する最大サイズ。制限を超えると、サーバーはHTTPステータス 431 Request Header Fields Too Large で応答します。go-humanize でサポートされているすべてのフォーマットを受け入れます。デフォルトでは、制限は 1MB です。

{
	servers {
		max_header_size 5MB
	}
}
enable_full_duplex

HTTP/1リクエストの全二重通信を有効にします。CaddyがGo 1.21以降でビルドされている場合にのみ効果があります。

HTTP/1リクエストの場合、Go HTTPサーバーはデフォルトで、レスポンスの書き込みを開始する前に、リクエストボディの未読部分をすべて消費します。これにより、ハンドラーがリクエストからの読み取りとレスポンスへの書き込みを同時に行うことができなくなります。このオプションを有効にすると、この動作が無効になり、ハンドラーはレスポンスの書き込みと同時にリクエストからの読み取りを続行できます。

HTTP/2+リクエストの場合、Go HTTPサーバーは常に同時読み取りとレスポンスを許可するため、このオプションは効果がありません。

一部の古いクライアントは全二重HTTP/1をサポートしていないため、デッドロックが発生する可能性があるため、HTTPクライアントで徹底的にテストしてください。詳細については、golang/go#57786 を参照してください。

⚠️ これは実験的な機能です。変更または削除される可能性があります。

{
	servers {
		enable_full_duplex
	}
}
log_credentials

Caddy v2.5以降、デフォルトでは、機密情報を含む可能性のあるヘッダー（Cookie、Set-Cookie、Authorization、Proxy-Authorization）は、アクセスログに空の値で記録されます（log ディレクティブ を参照）。

これらのヘッダーを編集*しない*場合は、log_credentials オプションを有効にすることができます。

{
	servers {
		log_credentials
	}
}
protocols

サポートするHTTPプロトコルのスペース区切りのリスト。

デフォルト：h1 h2 h3

受け入れられる値は

  • h1 (HTTP/1.1)
  • h2 (HTTP/2)
  • h2c (クリアテキスト上のHTTP/2)
  • h3 (HTTP/3)

現在、HTTP/2（H2Cを含む）を有効にすると、必然的にHTTP/1.1が有効になります。これは、Go標準ライブラリでは、HTTPサーバーを使用する場合にHTTP/1.1を無効にすることができないためです。ただし、HTTP/1.1またはHTTP/3は個別に有効にすることができます。

H2C（「クリアテキストHTTP/2」または「TCP上のH2」）とHTTP/3はGo標準ライブラリでは実装されていないため、一部の機能が制限される可能性があることに注意してください。アプリケーションに絶対に必要な場合を除き、H2Cを有効にすることはお勧めしません。

{
	servers :80 {
		protocols h1 h2c
	}
}
strict_sni_host

これを有効にすると、リクエストの Host ヘッダーが、クライアントのTLS ClientHelloによって送信された ServerName の値と一致する必要があります。これは、TLSクライアント認証を使用する場合に必要な安全対策です。不一致がある場合、HTTPステータス 421 Misdirected Request レスポンスがクライアントに書き込まれます。

このオプションは、クライアント認証 が構成されている場合、自動的に有効になります。これにより、TLSハンドシェイク中に保護されていないSNI値を送信し、接続確立後に保護されたドメインをHostヘッダーに配置することで悪用される可能性のあるTLSクライアント認証バイパス（ドメインフロンティング）が許可されなくなります。この動作は安全なデフォルトですが、insecure_off を使用して明示的に無効にすることができます。たとえば、ドメインフロンティングが望ましく、ホスト名に基づいてアクセスが制限されていないプロキシを実行する場合などです。

{
	servers {
		strict_sni_host on
	}
}

PKIオプション

PKI（公開鍵基盤）アプリは、Caddyの ローカルHTTPS および ACMEサーバー 機能の基盤です。アプリは、証明書に署名できる認証局（CA）を定義します。

デフォルトのCA IDは local です。ca を設定するときにIDが省略された場合、local と見なされます。

name

認証局のユーザー向けの名前。

デフォルト：Caddy Local Authority

{
	pki {
		ca local {
			name "My Local CA"
		}
	}
}
root_cn

ルート証明書のCommonNameフィールドに配置する名前。

デフォルト：{pki.ca.name} - {time.now.year} ECC Root

{
	pki {
		ca local {
			root_cn "My Local CA - 2024 ECC Root"
		}
	}
}
intermediate_cn

中間証明書のCommonNameフィールドに配置する名前。

デフォルト：{pki.ca.name} - ECC Intermediate

{
	pki {
		ca local {
			intermediate_cn "My Local CA - ECC Intermediate"
		}
	}
}
intermediate_lifetime

中間証明書が有効な 期間。この値は、ルート証明書の有効期間（3600d または10年）よりも*短くする必要があります*。

デフォルト：7d。絶対に必要な場合を除き、これを変更することは*お勧めしません*。

{
	pki {
		ca local {
			intermediate_lifetime 30d
		}
	}
}
root

CAのルートとして使用するキーペア（証明書と秘密鍵）。指定しない場合は、自動的に生成および管理されます。

  • format は、証明書と秘密鍵が提供される形式です。現在、pem_file のみがサポートされています。これはデフォルトであるため、このフィールドはオプションです。
  • cert は証明書です。pem_file 形式を使用する場合、これはPEMファイルへのパスである必要があります。
  • key は秘密鍵です。pem_file 形式を使用する場合、これはPEMファイルへのパスである必要があります。
intermediate

CAの中間体として使用するキーペア（証明書と秘密鍵）。指定しない場合は、自動的に生成および管理されます。

  • format は、証明書と秘密鍵が提供される形式です。現在、pem_file のみがサポートされています。これはデフォルトであるため、このフィールドはオプションです。
  • cert は証明書です。pem_file 形式を使用する場合、これはPEMファイルへのパスである必要があります。
  • key は秘密鍵です。pem_file 形式を使用する場合、これはPEMファイルへのパスである必要があります。
{
	pki {
		ca local {
			root {
				format pem_file
				cert /path/to/root.pem
				key /path/to/root.key
			}
			intermediate {
				format pem_file
				cert /path/to/intermediate.pem
				key /path/to/intermediate.key
			}
		}
	}
}

イベントオプション

Caddyモジュールは、興味深いことが起こったとき（または起こりそうなとき）にイベントを発行します。

イベントには通常、メタデータペイロードが含まれます。イベントとそのペイロードについて学ぶ最良の方法は、各モジュールのドキュメントを参照することですが、debug グローバルオプション を有効にしてログを読み取ることで、イベントとそのデータペイロードを確認することもできます。

on

イベントハンドラーを名前付きイベントにバインドします。イベントハンドラーモジュールの名前とその構成を指定します。

たとえば、証明書が取得された後にコマンドを実行するには（サードパーティプラグイン が必要）、プレースホルダーを使用してイベントペイロードの一部をスクリプトに渡します

{
	events {
		on cert_obtained exec ./my-script.sh {event.data.certificate_path}
	}
}

イベント

これらの標準イベントはCaddyによって発行されます

プラグインもイベントを発行する可能性があるため、詳細については、そのドキュメントを確認してください。