ドメイン名をトリガーとして設定し、カスタム公開パス経由で Functions and Pages にアクセスできます。Edge Security Acceleration (ESA) は、HTTP または HTTPS リクエストを Functions and Pages サービスに転送するために、ドメイン名の関連付け と ルート の 2 つのメソッドを提供します。
事前準備
ドメイン名の関連付け と ルート の両方で、アカウントにアクティブなサイトが必要です。
アクティブなサイトとは、プランを購入済みで、NS レコードまたは CNAME レコードを使用して接続されているサイトのことです。
適切な設定方法の選択

属性 | ドメイン名の関連付け | ルート |
主な目的 |
| 特定のドメイン名配下で、 |
スコープ | ドメイン名配下のすべてのトラフィック | ルールに一致する一部のトラフィック |
設定方法 | シンプル、ワンステップ設定 | 柔軟。マッチングルールの設定が必要。 |
利用シーン |
|
|
ドメインバインディングの使用
ドメイン名の関連付け を使用して、ドメイン名からのすべてのトラフィックを特定の Functions and Pages サービスに転送して処理します。
ドメインバインディング機能を使用すると、Functions and Pages サービスをご利用サイトのドメイン名にリンクできます。ドメイン名がバインドされると、それを使用して Functions and Pages サービスに直接アクセスできます。Functions and Pages サービスにバインドされるドメイン名は、アクティブなサイトに属している必要があります。コンソールでバインディングを設定すると、ESA はバインドされたドメイン名の DNS レコードをサイトに自動的に追加します。
ESA コンソールにログインします。左側のナビゲーションウィンドウで、 を選択します。設定する Functions and Pages サービスをクリックします。
[ドメイン] タブをクリックします。ドメイン名の関連付け セクションで、ドメイン名を追加 をクリックします。

Functions and Pages サービスにバインドするドメイン名 (例:
pages.example.com) を入力します。ドメイン名が追加されると、対応するサイトに新しい DNS レコードが作成されます。説明新しいドメイン名は、そのサイトの設定を継承します。サイトに SSL/TLS 証明書がない場合、バインドされたドメイン名は HTTPS 経由でアクセスできません。サイトで SSL/TLS を有効にする方法の詳細については、「SSL/TLS」をご参照ください。

ご利用サイトの接続タイプに対応する手順に従います:
NS 設定を使用して接続されたサイト
ご利用のサイトが NS レコードを使用して接続されている場合は、DNS レコードが有効になるまで待ちます。このプロセスには約 1 分かかります。その後、新しくバインドされたカスタムドメイン名 (例:
pages.example.com) にブラウザでアクセスして結果を表示します。
CNAME 設定を使用して接続されたサイト
ご利用のサイトが CNAME レコードを使用して接続されている場合は、バインディングを有効にするために、DNS プロバイダーで CNAME レコードを設定する必要があります。
新しく追加したカスタムドメイン名の右側にある DNS レコードの表示 をクリックします。

ESA が新しい DNS レコード用に生成した CNAME 値をコピーします。

DNS プロバイダーに移動し、ドメイン名の DNS 設定に CNAME レコードを追加します:
ホストレコード:カスタムドメイン名のプレフィックスを入力します。この例では、
pagesと入力します。レコードタイプ:
CNAMEを選択します。レコード値:前のステップでコピーした CNAME 値を貼り付けます。

ESA コンソールに戻ります。CNAME のステータス が 設定済み に変わるまで待ちます。
その後、新しくバインドされたカスタムドメイン名 (例: pages.example.com) にブラウザでアクセスして結果を表示します。
ルーティング設定の使用
ルーティングを使用して、特定の URL パスへのリクエストを Functions and Pages サービスに転送できます。このメソッドは、詳細なトラフィックシェーピングを提供します。リクエストが設定された URL パターンに一致する場合、Functions and Pages サービスがそれを処理します。それ以外の場合、リクエストは ESA の高速化された back-to-origin プロセスを続行します。たとえば、example.com サイトにルーティングルール example.com/a* を設定した場合、/a、/a1、/a2 などの一致するパスへのすべてのリクエストは、Functions and Pages サービスによって処理されます。/b、/c、/d などの一致しないパスへのリクエストは、標準の back-to-origin またはキャッシュプロセスに従います。
ESA コンソールにログインします。左側のナビゲーションウィンドウで、 を選択します。設定する Functions and Pages サービスをクリックします。
[ドメイン] タブをクリックします。ルート セクションで、ルートを追加 をクリックします。

[ルーティング名] を入力します。[サイトの選択] リストで、ターゲットサイト (例:
example.com) を選択します。選択する[ルーティングパターン]:
[基本モード]:このパターンは、ホスト名とパスを含む URL のみに基づいてリクエストを照合します。たとえば、URL プレフィックスが
pages.example.comのすべてのリクエストを Functions and Pages サービスにルーティングするように設定できます:
カスタムパターン: このパターンは、リクエストヘッダー、Cookie、リクエストメソッドなど、複数の条件に基づく複雑な論理マッチングを必要とするシナリオに適しています。複数のマッチング条件を追加し、それらの間の論理関係を「すべての条件を満たす」または「いずれかの条件を満たす」として指定することができます。たとえば、
hostnameがwww.example.comと等しく、かつUser-AgentリクエストヘッダーにMobileが含まれる場合にのみ、リクエストを 関数とページ サービスに転送するルールを設定できます:
ブラウザで一致するルーティングパスにアクセスして、結果を表示します。

基本モードを使用し、
*.example.comやwww.example.comのようなプレフィックス付きのドメイン名を入力する場合、ESA コンソールの DNS レコードセクションに対応するレコードが存在する必要があります。手動でレコードを追加することもできます。そうしないと、ドメイン名へのアクセスは失敗します。複数のルーティングルールが設定されている場合、それらは上から下に順次照合されます。一致が見つかると、後続のルールはチェックされません。
マッチングルール
ルーティング設定には、ドメインのホスト名とパス URI の両方を含める必要があります。したがって、
/pathのようなパス URI のみを含むルーティングルールは設定できません。ルーティング設定の先頭または末尾にワイルドカード文字 (
*) を追加して、より多くのリクエストを照合できます。ワイルドカード文字*は、0 個以上の任意の文字に一致します。たとえば、example.com/*はexample.comへのすべてのリクエストに一致します。ルーティング設定では大文字と小文字が区別されます。たとえば、
example.com/aとexample.com/Aは 2 つの異なるルーティングルールです。ルーティング設定では、パスの途中やパラメーターにワイルドカード文字 (
*) を使用することはサポートされていません。たとえば、example.com/*/pathやexample.com/path?param=1は許可されません。リクエストが複数のルーティングルールに一致する場合、リストの最初のマッチングルールが優先されます。
バイパスモード
ルーティングルールのバイパスモードを有効にすると、リクエストがルーティングポリシーに一致したときに、リクエストはサブリクエストとして Functions and Pages サービスに送信されます。バイパスモードの全体的なプロセスは次のとおりです:
クライアントが ESA の POP (Point of Presence) にリクエストを送信します。
リクエストはルーティングポリシーに一致し、処理のために Functions and Pages サービスに転送されます。Functions and Pages サービスでは、リクエストの内容に基づいてログ記録や認証などの操作を実行できます。バイパスモードが有効な場合、リクエストボディは Functions and Pages サービスに転送されないことに注意してください。
Functions and Pages サービスからのレスポンスのステータスコードが
200の場合、リクエストは次の処理ステップに進みます。ステータスコードが 200 でない場合、ESA はリクエストを中止し、クライアントに403ステータスコードを返します。その後、リクエストは後続のポリシーと照合され、ESA のキャッシュマッチングまたは高速化された back-to-origin ロジックを経て処理されます。
キャッシュヒットまたはオリジンサーバーからのレスポンスが ESA の POP に返されます。この時点で、レスポンスは Functions and Pages サービスによって処理されなくなります。
レスポンスはクライアントに転送されます。
一般的な利用シーン
ログ記録:一部のリクエストのログを生成したい場合、リクエストをバイパスモードで Functions and Pages サービスに転送し、関数内でカスタムのログ記録ロジックを定義できます。
大容量ファイルのダウンロード認証:エッジ関数がクライアントにレスポンスを転送する際、CPU 時間を消費します。レスポンスが大きすぎると、CPU タイムスライスの上限を超え、追加コストが発生する可能性があります。バイパスモードを使用して Functions and Pages サービスで認証を行うことで、これらの問題を回避できます。