一般的な Caddyfile パターン

このページでは、一般的なユースケースに対応する、完全で最小限の Caddyfile 設定をいくつか示します。これらは、独自の Caddyfile ドキュメントを作成する際の出発点として役立ちます。

これらはそのまま使えるソリューションではありません。ドメイン名、ポート/ソケット、ディレクトリパスなどをカスタマイズする必要があります。最も一般的な設定パターンをいくつか示すことを目的としています。

• 静的ファイルサーバー
• リバースプロキシ
• PHP
• www. サブドメインのリダイレクト
• 末尾のスラッシュ
• ワイルドカード証明書
• シングルページアプリケーション (SPA)
• Caddy から別の Caddy へのプロキシ

静的ファイルサーバー

example.com {
	root * /var/www
	file_server
}

通常どおり、最初の行はサイトアドレスです。 root ディレクティブ は、サイトのルートへのパスを指定します (* はすべてのリクエストに一致することを意味し、パス マッチャー と区別するためです)。現在の作業ディレクトリでない場合は、サイトへのパスを変更してください。最後に、静的ファイルサーバー を有効にします。

リバースプロキシ

すべてのリクエストをプロキシする

example.com {
	reverse_proxy localhost:5000
}

パスが /api/ で始まるリクエストのみをプロキシし、その他すべてのリクエストに対して静的ファイルを配信する

example.com {
	root * /var/www
	reverse_proxy /api/* localhost:5000
	file_server
}

これは、リクエスト マッチャー を使用して、/api/ で始まるリクエストのみを一致させ、バックエンドにプロキシします。他のすべてのリクエストは、サイトの root から 静的ファイルサーバー を使用して配信されます。これは、reverse_proxy が ディレクティブの順序 で file_server よりも上位にあるという事実にも依存しています。

こちらに reverse_proxy の例がさらに多くあります。

PHP

PHP-FPM

PHP FastCGI サービスが実行されている場合、ほとんどの最新の PHP アプリケーションではこのような設定が有効です。

example.com {
	root * /srv/public
	encode gzip
	php_fastcgi localhost:9000
	file_server
}

サイトのルートを適宜カスタマイズしてください。この例では、PHP アプリケーションの Web ルートが public ディレクトリ内にあることを前提としています。ディスク上に存在するファイルのリクエストは file_server で配信され、その他のリクエストは PHP アプリケーションによって処理されるために index.php にルーティングされます。

PHP-FPM に接続するために Unix ソケットを使用する場合があります。

php_fastcgi unix//run/php/php8.2-fpm.sock

php_fastcgi ディレクティブ は、実際には いくつかの設定のショートカット です。

FrankenPHP

代わりに、FrankenPHP を使用することもできます。これは、CGO (Go から C へのバインディング) を使用して PHP を直接呼び出す Caddy のディストリビューションです。これは PHP-FPM よりも最大 4 倍高速で、ワーカーモードを使用できる場合はさらに高速になります。

{
    frankenphp
    order php_server before file_server
}

example.com {
	root * /srv/public
    encode zstd br gzip
    php_server
}

www. サブドメインのリダイレクト

HTTP リダイレクトを使用して www. サブドメインを**追加**するには

example.com {
	redir https://www.{host}{uri}
}

www.example.com {
}

**削除**するには

www.example.com {
	redir https://example.com{uri}
}

example.com {
}

**複数のドメイン** を一度に削除するには。これは、ホスト名の部分である {labels.*} プレースホルダーを使用します。右から 0 でインデックス付けされます (例: 0=com、1=example-one、2=www)。

www.example-one.com, www.example-two.com {
	redir https://{labels.1}.{labels.0}{uri}
}

example-one.com, example-two.com {
}

末尾のスラッシュ

通常、これを自分で設定する必要はありません。 file_server ディレクティブ は、リクエストされたリソースがディレクトリかファイルかによって、HTTP リダイレクトを使用してリクエストから末尾のスラッシュを自動的に追加または削除します。

ただし、必要な場合は、設定で末尾のスラッシュを強制することができます。内部的に強制する方法と外部的に強制する方法の 2 つがあります。

内部強制

これは rewrite ディレクティブを使用します。Caddy は URI を内部的に書き換えて、末尾のスラッシュを追加または削除します。

example.com {
	rewrite /add     /add/
	rewrite /remove/ /remove
}

書き換えを使用すると、末尾のスラッシュの有無にかかわらずリクエストは同じになります。

外部強制

これは redir ディレクティブを使用します。Caddy はブラウザに、URI を変更して末尾のスラッシュを追加または削除するように要求します。

example.com {
	redir /add     /add/
	redir /remove/ /remove
}

リダイレクトを使用すると、クライアントはリクエストを再発行する必要があり、リソースに対して許容される URI が 1 つに強制されます。

ワイルドカード証明書

同じワイルドカード証明書で複数のサブドメインを提供する必要がある場合は、handle ディレクティブ と host マッチャー を使用した次のような Caddyfile を使用するのが最良の方法です。

*.example.com {
	tls {
		dns <provider_name> [<params...>]
	}

	@foo host foo.example.com
	handle @foo {
		respond "Foo!"
	}

	@bar host bar.example.com
	handle @bar {
		respond "Bar!"
	}

	# Fallback for otherwise unhandled domains
	handle {
		abort
	}
}

Caddy がワイルドカード証明書を自動的に管理するには、ACME DNS チャレンジ を有効にする必要があります。

シングルページアプリケーション (SPA)

Web ページが独自のルーティングを行う場合、サーバーはサーバー側には存在しないが、単一のインデックスファイルが代わりに提供される限りクライアント側でレンダリング可能なページに対するリクエストを多数受信することがあります。このように設計された Web アプリケーションは、SPA またはシングルページ アプリケーションと呼ばれます。

主なアイデアは、サーバーに「ファイルを試し」て、リクエストされたファイルがサーバー側に存在するかどうかを確認させ、存在しない場合は、クライアントがルーティングを行う (通常はクライアント側の JavaScript を使用して) インデックスファイルにフォールバックさせることです。

典型的な SPA 設定は、通常はこのようになります。

example.com {
	root * /srv
	encode gzip
	try_files {path} /index.html
	file_server
}

SPA が API または他のサーバー側のみのエンドポイントと結合されている場合は、handle ブロックを使用してそれらを排他的に処理する必要があります。

example.com {
	encode gzip

	handle /api/* {
		reverse_proxy backend:8000
	}

	handle {
		root * /srv
		try_files {path} /index.html
		file_server
	}
}

Caddy から別の Caddy へのプロキシ

パブリックにアクセスできる Caddy インスタンス (「フロント」と呼ぶ) と、実際のアプリケーションを提供するプライベートネットワーク内の別の Caddy インスタンス (「バック」と呼ぶ) がある場合、reverse_proxy ディレクティブ を使用してリクエストを渡すことができます。

フロントインスタンス

foo.example.com, bar.example.com {
	reverse_proxy 10.0.0.1:80
}

バックインスタンス

{
	servers {
		trusted_proxies static private_ranges
	}
}

http://foo.example.com {
	reverse_proxy foo-app:8080
}

http://bar.example.com {
	reverse_proxy bar-app:9000
}

• この例では、2 つの異なるドメインを提供し、どちらもポート 80 の同じバック Caddy インスタンスにプロキシします。バックインスタンスは 2 つのドメインを異なる方法で提供しているため、2 つの個別のサイトブロックで構成されています。

• バックでは、http:// を使用してポート 80 で HTTP を受け入れます。フロントインスタンスは TLS を終端し、フロントとバック間のトラフィックはプライベートネットワーク上にあるため、再暗号化する必要はありません。

• 必要な場合は、バックインスタンスで 8080 などの別のポートを使用できます。バックの設定の各サイトアドレスに :8080 を追加するか、http_port グローバルオプション を 8080 に設定するだけです。

• バックでは、trusted_proxies グローバルオプション を使用して、フロントインスタンスをプロキシとして信頼するように Caddy に指示します。これにより、実際のクライアント IP が保持されます。

• さらに、負荷分散 する複数のバックインスタンスを持つことができます。フロントインスタンスで acme_server を使用して mTLS (相互 TLS) を設定し、バックインスタンスの CA として機能させることができます (フロントとバック間のトラフィックが信頼されていないネットワークを通過する場合に役立ちます)。