コンテンツにスキップ

ルート

背景

ルートを使用すると、ユーザーはURLパターンをWorkerにマッピングできます。指定されたURLパターンに一致するリクエストがCloudflareネットワークに到着すると、そのルートであなたのWorkerが実行されます。

ルートは、リクエストのURLに対して評価される一連のルールです。特定のアプリケーションサーバーと常に通信する必要がある場合は、ルートを使用することをお勧めします。受信したRequestオブジェクトでfetch()を呼び出すと、CloudflareゾーンのDNS設定で定義されたアプリケーションサーバーへのサブリクエストがトリガーされます。

ルートは、既存のプロキシホスト名にWorkers機能を追加し、アプリケーションサーバーの前に配置します。これにより、Workersはプロキシとして機能し、Cloudflareの背後にあるアプリケーションサーバーに接続する前に必要な作業を実行できます。

ルートはCloudflare DNSで定義されたアプリケーションと連携します

ルートは、カスタムドメインをfetch()することもでき、同じホスト名で設定されている場合は優先されます。たとえば、アプリケーションの前にロギングWorkerを実行したい場合、app.example.comのアプリケーションWorkerにカスタムドメインを作成し、app.example.com/*でロギングWorkerのルートを作成できます。fetch()を呼び出すと、カスタムドメイン上のアプリケーションWorkerが呼び出されます。ルートは、同じゾーンのfetch()呼び出しのターゲットにはできないことに注意してください。

ルートの設定

ルートを追加するには、次のものが必要です。

  1. アクティブなCloudflareゾーン。
  2. 呼び出すWorker。
  3. ルートを設定したいドメインまたはサブドメインのために設定されたオレンジの雲のDNSレコード。

Workerがアプリケーションのオリジンでない場合は、以下の手順に従ってルートを設定してください。

ダッシュボードでのルートの設定

ルートを設定する前に、ルートを設定したいドメインまたはサブドメインのためにDNSレコードが設定されていることを確認してください。

ダッシュボードでルートを設定するには：

  1. Cloudflareダッシュボード ↗にログインし、アカウントを選択します。
  2. Workers & Pagesに移動し、概要でWorkerを選択します。
  3. 設定 > トリガー > ルート > ルートを追加に移動します。
  4. ルートを入力し、それが適用されるゾーンを選択します。
  5. ルートを追加を選択します。

wrangler.tomlでのルートの設定

ルートを設定する前に、ルートを設定したいドメインまたはサブドメインのためにDNSレコードが設定されていることを確認してください。

wrangler.tomlファイルを使用してルートを構成するには、以下の例を参照してください。

routes = [
  { pattern = "subdomain.example.com/*", zone_name = "example.com" }
  # または
  { pattern = "subdomain.example.com/*", zone_id = "<YOUR_ZONE_ID>" }
]

各ルートの後にzone_nameまたはzone_idオプションを追加します。zone_nameとzone_idオプションは互換性があります。zone_idを使用する場合は、Cloudflareダッシュボード ↗にログインし、アカウントを選択し、ウェブサイトを選択し、概要の左側にあるゾーンIDを見つけてください。

複数のルートを追加するには：

routes = [
  { pattern = "subdomain.example.com/*", zone_name = "example.com" },
  { pattern = "subdomain-two.example.com/example", zone_id = "<YOUR_ZONE_ID>" }
]

workers.devを使用したルート

Workerを作成すると、workers.devルートが自動的に設定されます。Worker > トリガー > ルートでworkers.devルートを確認してください。

workers.devルートを無効にするには、Workerのwrangler.tomlファイルに次の内容を含めます。

workers_dev = false

この変更でWorkerを再デプロイすると、workers.devルートが無効になります。

workers_dev = falseを指定しないが、wrangler.tomlにroutesコンポーネントを追加した場合、次回のデプロイ時にworkers_devの値はfalseとして推測されます。

マッチング動作

ルートパターンは次のようになります：

https://*.example.com/images/*

このパターンは、example.comのサブホストに向けられたすべてのHTTPSリクエストと、そのパスが/images/で始まるものに一致します。

すべてのリクエストに一致するパターンは次のようになります：

*example.com/*

これらは正規表現 ↗パターンに似ていますが、ルートパターンは特定のルールに従います：

  • サポートされている唯一の演算子はワイルドカード（*）で、これは任意の文字のゼロ個以上に一致します。

  • ルートパターンには中間ワイルドカードやクエリパラメータを含めることはできません。たとえば、example.com/*.jpgやexample.com/?foo=*は有効なルートパターンではありません。

  • 複数のルートパターンがリクエストURLに一致する場合、最も特異なルートパターンが勝ちます。たとえば、パターンwww.example.com/*は、https://www.example.com/のリクエストに対して*.example.com/*よりも優先されます。パターンexample.com/hello/*は、example.com/*よりもexample.com/hello/worldのリクエストに対して優先されます。

  • ルートパターンのマッチングは、クエリパラメータ文字列を含むリクエストURL全体を考慮します。ルートパターンにはクエリパラメータを含めることができないため、クエリパラメータを持つURLに一致させる唯一の方法は、ワイルドカード*で終了させることです。

  • ルートパターンのパスコンポーネントは大文字と小文字を区別します。たとえば、example.com/Images/*とexample.com/images/*は2つの異なるルートです。

  • 2023年10月15日以前に作成されたルートでは、ルートパターンのホストコンポーネントは大文字と小文字を区別します。たとえば、example.com/*とExample.com/*は2つの異なるルートです。

  • 2023年10月15日以降に作成されたルートでは、ルートパターンのホストコンポーネントは大文字と小文字を区別しません。たとえば、example.com/*とExample.com/*は同等のルートです。

ルートはWorkerに関連付けられずに指定することもできます。これにより、より特異性の低いパターンが無効になります。たとえば、次のルートパターンのペアを考えてみましょう。一方はWorkersスクリプトを持ち、もう一方は持たないものです：

*example.com/images/cat.png -> <no script>
*example.com/images/*       -> worker-script

この例では、example.comに向けられ、パスが/images/で始まるすべてのリクエストはworker-scriptにルーティングされますが、/images/cat.pngはWorkersを完全にバイパスします。/images/cat.png?foo=barというパスのリクエストは、クエリ文字列が存在するため、worker-scriptにルーティングされます。

有効性

ルートパターンの有効性を管理する一連のルールがあります。

ルートパターンにはゾーンを含める必要があります

ゾーンがexample.comの場合、最も単純なルートパターンはexample.comであり、これはhttp://example.com/およびhttps://example.com/に一致し、他には何も一致しません。URLと同様に、指定しない場合は/の暗黙のパスがあります。

ルートパターンにはクエリパラメータを含めることはできません

たとえば、https://example.com/?anythingは有効なルートパターンではありません。

ルートパターンはhttp://またはhttps://で始めることができます

ルートパターンでスキームを省略すると、http://およびhttps://の両方のURLに一致します。http://またはhttps://を含めると、それぞれHTTPまたはHTTPSリクエストのみに一致します。

  • https://*.example.com/はhttps://www.example.com/に一致しますが、http://www.example.com/には一致しません。

  • *.example.com/はhttps://www.example.com/とhttp://www.example.com/の両方に一致します。

ホスト名は*で始めることができます

ルートパターンのホスト名が*で始まる場合、それはホストとすべてのサブホストに一致します。ルートパターンのホスト名が*.で始まる場合、それはすべてのサブホストにのみ一致します。

  • *example.com/はhttps://example.com/とhttps://www.example.com/に一致します。

  • *.example.com/はhttps://www.example.com/に一致しますが、https://example.com/には一致しません。

パスは*で終わることができます

ルートパターンのパスが*で終わる場合、そのパスのすべてのサフィックスに一致します。

  • https://example.com/path*はhttps://example.com/path、https://example.com/path2、https://example.com/path/readme.txtに一致します。

ドメインとサブドメインにはDNSレコードが必要です

すべてのドメインとサブドメインは、Cloudflareでプロキシされ、Workerを呼び出すためにDNSレコードを持っている必要があります。たとえば、myname.example.comにWorkerを配置したい場合、example.comをCloudflareに追加したが、myname.example.comのDNSレコードを追加していない場合、myname.example.comへのリクエストはERR_NAME_NOT_RESOLVEDエラーになります。

Cloudflare DashboardDiscordCommunityLearning CenterSupport Portal
Cookie Settings