最終更新日:2026-05-08 15:11:57
ユーザーが CDNetworks CDN プラットフォームを通じてウェブサイトのコンテンツにアクセスする際、コンソールで簡単なルールを構成し、リクエスト URL のプロトコル、異なるリクエストコンテンツ、リクエストヘッダー、さらにはユーザーの地理的場所などのさまざまな基準に基づいて、特定のコンテンツをユーザーに配信することができます。現在、CDNetworks は、特定のステータスコードと新しい URL を返し、クライアントに新しいリクエストの開始を促すことによる URL またはプロトコルの書き換えシナリオをサポートしています。
をクリックします。Apply to
CDNetworks では、コンソールに URL 正規表現を入力して、ユーザーのリクエストが書き換えルールに適合するかどうかを URL Pattern (Regex) を通じて決定できます。例:rewrite/*.(jpg|png|gif)。これは、rewrite ディレクトリ内の jpg|png|gif ファイルへのリクエストがこのルールに一致することを意味します。
Advanced Scope Conditions
ルールの効果範囲の基本的な一致条件として URL Pattern を構成することに加えて、Advanced Scope Conditions をクリックして Advanced Scope を通じてその他の条件を追加することもできます。以下のパラメータの1つ以上を複合構成項目として選択し、基本的な URL 正規表現と組み合わせて AND(論理積)関係を形成し、ルールの最終的な範囲を決定できます。
| Parameter | Description |
|---|---|
| UA or Exclude User-Agent | 正規表現をサポートします。スペースと TAB は \s に変換されます。複数の UA を同時に構成でき、各 UA は別の行に入力します。 |
| Country or Exclude Country | CDNetworks が提供する国/地域のリストからの直接検索および選択をサポートします。 中国本土の場合、特定の省や、East Region、Southwest Region などのより広い地理的エリアを選択できます。 |
| Request Header or Exclude Request Header | ヘッダーとその値を入力します。値は正規表現をサポートしています。例:Range bytes=[0-9]{9,}現在、単一のルールでは 1 つのリクエストヘッダーの構成のみがサポートされています。 |
| Exclude URL (Regex) | 正規表現をサポートします。 URL Pattern に rewrite/*.(jpg|png|gif) が入力され、この項目に rewrite/*exception*.jpg が入力された場合、rewrite ディレクトリ内の jpg|png|gif ファイルへのリクエストはこのルールに一致しますが、*exception*.jpg を含むリクエストはこのルールに適用されないことを意味します。 |
Exclude とマークされた Advanced Scope 項目は NOT(否定)を意味し、基本的な一致ルール範囲内の特定のケースを除外します。上記の各構成項目は 1 つのルール内に 1 回のみ表示でき、単一のルール内で UA と Exclude User-Agent は相互に排他的であり、Country(およびその除外)、Request Header(およびその除外)もそれぞれ排他的です。したがって、最大 4 つの高度な構成項目を同時に存在させることができます。
Rewrite Type
現在、CDNetworks では Protocol Rewrite または URL Rewrite のいずれかを選択できます。選択したタイプに関係なく、クライアントに返す応答ステータスコードを選択する必要があります。CDNetworks は 301;302;303;307 の応答ステータスコードの範囲をサポートしており、デフォルト値は 302 です。
Type 1: Protocol Rewrite
プロトコルの書き換え(Protocol rewriting)とは、クライアントからのリクエストを受信した際に CDN エッジノードがプロトコルを書き換えることを指します。ノードはキャッシュとオリジンプルに書き換えられたプロトコルを使用します。オリジンへのリクエスト(Back to Origin)の際にプロトコルのみを書き換える場合は、関連するルールの構成について HTTP/HTTPS Back to Origin を参照してください。
このルールでは、HTTP -> HTTPS または HTTPS -> HTTP を選択できます。
Type 2: URL Rewrite
Protocol Rewrite と同様に、URL の書き換えは CDN ノードがリクエストを受信したときに実行され、キャッシュとオリジンプルに書き換えられた URL が使用されます。オリジンへのリクエスト時にリクエスト URL のホストとポートのみを置き換える場合は、関連するルールの構成について Host Header and Port を参照してください。
URL Rewrite の場合、Original URL に書き換えるリクエスト URL を入力します。これは正規表現または完全な URL(例:(https://[^/]+)/.* または http://domain/browse/index.html?aa=1)にすることができます。Target URL には、書き換え後の URL を入力します。これは http:// または https:// で始まる必要があります。
Priority
このルールの優先順位を 1~10 の間で設定できます。数字が大きいほど、一致および適用の優先順位が高くなります。複数のルールが同一の一致条件を持つ場合、優先順位が高いルールのみが適用されます。
Add ボタンをクリックしてルールのページに入り詳細なパラメータ構成を行うほかに、Add ボタンの横にある Quick Settings をクリックして、プロトコルや URL の書き換えを簡単に構成することもできます。クイック構成では、Apply to のデフォルトはすべてのリクエストになり、応答ステータスコードは 302 になります。書き換えるプロトコル、元の URL とターゲット URL、優先順位など、残りの構成はすべてカスタマイズできます。
上記の構成を完了した後、Confirm をクリックし、Next を選択して構成を送信してください。本番環境への影響を避けるために、まず Pre-deploy を行ってテスト環境で構成を確認することをお勧めします。構成が正しいことが確認できたら、Deploy Directly をクリックして本番環境で構成を正式にアクティブにします。通常、有効になるまでに約 3~5 分かかります。事前デプロイテストの詳細については、チュートリアル Verifying Configuration Effectiveness Through Pre-deployment を参照してください。
Example 1: URL 正規表現、および UA、Country フィールドに一致するリクエストのプロトコル書き換え
このルールに関連付けられたドメインについて、図に示す URL 正規表現にリクエストが一致し、UA ヘッダーが Mozilla/4.0 でユーザーの国が Japan; South-Korea の場合、CDN サーバーは書き換えられたプロトコル下の URL をキャッシュしてクライアントに返します。たとえば、http://domain/rewrite/example.jpg へのリクエストは https://domain/rewrite/example.jpg を返し、ステータスコード 303 を伴って、クライアントに新しいプロトコルの URL への新しいリクエストを開始するように促します。

Example 2: URL 正規表現、および UA、Country フィールド、特定の URL に一致するリクエストの URL 書き換え
このルールに関連付けられたドメインについて、図に示す URL 正規表現にリクエストが一致し、UA ヘッダーが Mozilla/4.0 でユーザーの国が Japan; South-Korea であり、指定された Original URL と一致する場合、CDN サーバーはキャッシュし、書き換えられた URL をクライアントに返します。たとえば、https://domain/rewrite/urltype1.jpg へのリクエストは https://domain/target/urltype1.jpg を返し、ステータスコード 302 を伴って、クライアントに返された URL への新しいリクエストを開始するように促します。

ノードはキャッシュとオリジンリクエストに書き換えられた URL を使用するため、書き換え後のドメインは CDNetworks CDN プラットフォームでアクセラレーションされているドメインである必要があります。
Protocol Rewrite タイプの場合、1 つのドメインにつき許可されるルールは 1 つだけです。これは主に、リクエストが HTTP -> HTTPS と HTTPS -> HTTP の両方に同時にヒットした場合に発生する可能性のあるループの問題を防ぐためです。複数の Protocol Rewrite ルールを構成するには、テクニカルサポートにお問い合わせください。