ホスト名ルーティング

dynamic dispatch Worker を使うと、従来の ルート上限 に達せずに、数百万の独自ドメインやサブドメインを Workers へルーティングできます。これらのホスト名は、管理ドメイン配下のサブドメイン（例: customer1.saas.com）でも、エンド顧客が管理する独自ドメイン（例: mystore.com）でも構いません。独自ドメインは カスタムホスト名 で管理できます。

SaaS ドメイン（カスタムホスト名を設定するドメイン）に、dynamic dispatch Worker を指すワイルドカード Route（*/*）を設定します。これにより、次ができます。

• サブドメインと独自ドメインの両方に対応する: customer1.myplatform.com（サブドメイン）と shop.customer.com（カスタムホスト名）を、同じルーティングロジックで処理します。
• ルート上限を避ける: ドメインごとに個別ルートを作ると Routes の上限 に達することがあります。代わりにコード側でルーティングし、数百万ドメインを個別の Workers へプロキシできます。
• ルーティングロジックをプログラムで制御する: ホスト名、custom metadata、パス、その他のプロパティに基づいてリクエストをルーティングするカスタムコードを書けます。

一部のホスト名を dispatch Worker へのルーティングから除外したい場合は、次のいずれかを行います。

• Worker を指定しないルートを追加し、特定のホスト名やパスを dispatcher Worker の実行対象から外す（例: saas.com、api.saas.com など）
• カスタムホスト名と dispatch Worker の管理に 専用ドメイン（例: customers.saas.com）を使い、そのドメインの残りのトラフィックを分けておく

ワイルドカードルートでホスト名ルーティングを設定する手順は次のとおりです。

1. カスタムホスト名を設定する: Cloudflare for SaaS でドメインとカスタムホスト名を用意します。
2. フォールバックオリジンを設定する: フォールバックオリジンサーバー を設定します。カスタムホスト名はすべてここにルーティングされます。別々のオリジンへ送りたい場合は、カスタムオリジンサーバー を使えます。リクエストはオリジンに届く前に Worker を通ります。Worker 自身がオリジンの場合は、フォールバックオリジンにダミーの DNS レコードを置きます（例: A 192.0.2.0）。
3. DNS を設定する: DNS レコード（サブドメインまたはカスタムホスト名）を SaaS ドメインへの CNAME レコード で向けます。顧客が apex ホスト名（例: example.com）をプロキシする必要があり、CNAME レコードを使えない場合は Apex Proxying を確認してください。
4. ワイルドカードルートを作成する: プラットフォームドメイン（例: saas.com）に */* ルートを追加し、dispatch Worker に関連付けます。
5. dispatch ロジックを実装する: dispatch Worker に、ホスト名に基づくルーティング、Workers KV に保存したマッピングの参照、またはカスタムホスト名に付与した custom metadata の利用を追加します。

export default {
	async fetch(request, env) {
		const hostname = new URL(request.url).hostname;

		// Get custom hostname metadata for routing decisions
		const hostnameData = await env.KV.get(`hostname:${hostname}`, {
			type: "json",
		});

		if (!hostnameData?.workerName) {
			return new Response("Hostname not configured", { status: 404 });
		}

		// Route to the appropriate user Worker
		const userWorker = env.DISPATCHER.get(hostnameData.workerName);
		return await userWorker.fetch(request);
	},
};

サブドメインレコード（例: customer1.saas.com）だけをルーティングしたい場合は、より具体的なルート（*.saas.com/*）でリクエストを dispatch Worker へ送れます。

サブドメインルーティングを設定する手順は次のとおりです。

1. オリジンを指す、プロキシ済み（オレンジクラウド）のワイルドカード DNS レコード *.saas.com を作成します。Worker 自身がオリジンの場合は、ダミーの DNS 値を使えます（例: A 192.0.2.0）。
2. ワイルドカードルート *.saas.com/* を設定し、dispatch Worker を指します。
3. dispatch Worker に、サブドメインのリクエストを適切な Worker へ送るロジックを追加します。

export default {
	async fetch(request, env) {
		const url = new URL(request.url);
		const subdomain = url.hostname.split(".")[0];

		// Route based on subdomain
		if (subdomain && subdomain !== "saas") {
			const userWorker = env.DISPATCHER.get(subdomain);
			return await userWorker.fetch(request);
		}

		return new Response("Invalid subdomain", { status: 400 });
	},
};

顧客も Cloudflare を使っており、カスタムドメインを CNAME で SaaS ドメインへ向けている場合（例: mystore.com → saas.com）、Worker のルーティング動作は、顧客の DNS レコードがプロキシ済み（オレンジクラウド）か DNS のみ（グレークラウド）かによって変わります。O2O の構成 の詳細を確認してください。

特定ホスト名のルートを使うと、動作が揃わないことがあります。

• CNAME ターゲット（saas.com）に基づいてルーティングする場合、Worker を呼び出すにはカスタムホスト名の DNS レコードがオレンジクラウドである必要があります。
• カスタムホスト名（mystore.com）に基づいてルーティングする場合、Worker を呼び出すには顧客のレコードがグレークラウドである必要があります。

顧客の DNS プロキシ設定を制御できないことが多いため、DNS の構成にかかわらずルーティングが期待どおり動くよう、*/* のワイルドカードルートを推奨します。

次の表は、ルートパターンと顧客の DNS プロキシ設定に応じて、Worker がいつ呼び出されるかを示します。