オリジン URL リライト機能の設定方法 - ApsaraVideo VOD - Alibaba Cloud ドキュメントセンター

仕組み

オリジンパスリライトルールを使用すると、リクエストパスをオリジンサーバー上の実際のリソースの場所と一致するように変更できます。これにより、POP はリソースを正確に取得したり、特定のクエリ文字列をオリジンに渡したりすることができます。

フラグ がなしまたは break に設定されている場合、URL のリソースパスのみが書き換えられます。
フラグ が enhance break に設定されている場合、リソースパスとクエリ文字列の両方を書き換えることができます。

使用上の注意

1 つのドメイン名に対して、最大 50 個のオリジンフェッチパスの書き換えルールを設定できます。
ルールは上から順に適用されます。ルールの順序は、最終的なリライト結果に影響します。
[オリジン URL 書き換え] の実行ルールを設定すると、URL パラメーターの書き換えが、[ドメイン名 > パフォーマンス最適化] タブのパラメーターを無視機能と競合する可能性があります。両方の機能を設定する場合は、それらの設定が競合しないようにしてください。

手順

ApsaraVideo VOD コンソールにログインします。
左側のナビゲーションウィンドウで、[設定管理]> [CDN設定]> [ドメイン名] を選択します。
管理するドメイン名を見つけ、[操作] 列の設定をクリックします。
ドメイン名の左側のナビゲーションペインで、Back-to-Origin をクリックします。
[オリジン URL リライト] タブをクリックします。

追加をクリックし、要件に基づいてソースパス、宛先パス、実行ルールを設定します。

重要

[オリジン URL リライト] ページの書き換えルールは上から下に順次実行されるため、書き換え結果に影響する可能性があります。

パラメーター	例	説明
ソースパス	^/hello$	照合対象の URL パス。スラッシュ (/) で始まり、`http://` プレフィックスやドメイン名を含んではいけません。Perl 互換正規表現 (PCRE) がサポートされています。
宛先パス	/hello/test	書き換えに使用する URL パス。スラッシュ (/) で始まり、`http://` プレフィックスやドメイン名を含んではいけません。
実行ルール	なし	リクエスト URL がルールに一致した場合、システムは書き換えを適用して処理を続行します。書き換えられた URL は、後続のルールに対して評価されます。
	break	リクエスト URL がこのルールに一致した場合、システムはこのルールを実行し、後続のルールの処理を停止します。このオプションは、URL 内のリソースパスのみを書き換え、URL パラメーターは書き換えません。「パラメーターの無視」機能とは競合しません。
	enhance break	リクエスト URL がこのルールに一致した場合、このルールが実行され、後続のルールは処理されません。 `break` と同様ですが、このオプションは URL パラメーターを書き換えることもできます。。

OK をクリックして書き換えルールを適用します。

オリジン URL の書き換え タブのルール一覧で変更または削除をクリックして、既存の書き換えルールを管理することもできます。

設定例

例 1：実行ルールが「なし」の場合

書き換え対象のパス	^/hello$
書き換え後のパス	/index.html
フラグ	なし
結果	元のリクエスト： `http://example.com/hello` 書き換え後のオリジンフェッチリクエスト: `http://example.com/index.html` その後、リクエストはオリジンフェッチパスの書き換えリスト内の後続のルールと照合されます。

例 2：実行ルールが「break」の場合

書き換え対象のパス	^/hello.jpg$
書き換え後のパス	/image/hello.jpg
フラグ	break
結果	元のリクエスト: `http://example.com/hello.jpg` 書き換え後のオリジンフェッチリクエスト： `http://example.com/image/hello.jpg` 後続のルールは、オリジンフェッチパスの書き換えリストでは評価されません。

例 3：実行ルールが「enhance break」の場合

書き換え対象のパス	^/hello.jpg$
書き換え後のパス	/image/hello.jpg?code=321
フラグ	enhance break
結果	元のリクエスト：`http://example.com/hello.jpg?code=123` 書き換え後のオリジンフェッチリクエスト: `http://example.com/image/hello.jpg?code=321` オリジンフェッチパスの書き換えリスト内の後続のルールは評価されません。

例 4：ルートパスへのプレフィックスの追加

たとえば、/xxx のような URL パスを /image/xxx に書き換えることができます。ここで、xxx は可変のファイル名 (例：/hello.jpg や /hello.html) です。これにより、ルートディレクトリ内の任意のファイルへのパスに /image プレフィックスが挿入されます。

書き換え対象のパス	^(.)$ 説明 `^` は文字列の先頭に一致します。`(.)` はキャプチャグループです。`.` は改行文字を除く任意の 1 文字に一致し、`` は直前の文字またはグループの 0 回以上の繰り返しに一致します。ターゲットパスで $1 を使用して、このグループによってキャプチャされたコンテンツを参照できます。`$` は文字列の末尾に一致します。したがって、`^(.)$` は、文字列全体に先頭から末尾まで一致し、改行文字を除くすべての文字をグループにキャプチャします。たとえば、文字列 `"hello world"` の場合、`^(.*)$` は文字列全体に一致し、`"hello world"` を最初のグループにキャプチャします。
書き換え後のパス	/image$1 説明 `/image` は、文字列 `"/image"` に一致します。`$1` は 1 番目のキャプチャグループの内容を参照し、`$2` は 2 番目のキャプチャグループの内容を参照します。以降も同様です。したがって、`/image$1` は、文字列 `"/image"` の直後に 1 番目のキャプチャグループの内容が続くことを意味します。たとえば、1 番目のキャプチャグループの内容が `"abc"` の場合、`/image$1` は文字列 `"/imageabc"` に一致します。なお、`$1` はキャプチャグループの内容を参照するものであり、リテラル文字列 `"$1"` ではありません。リテラル文字列 `"$1"` に一致させるには、`"\$1"` などのエスケープ文字を使用する必要があります。
フラグ	break
結果	元のリクエスト： `http://example.com/hello.jpg` 書き換え後のオリジンフェッチリクエスト: `http://example.com/image/hello.jpg` 元のリクエスト： `http://example.com/hello.html` 書き換え後のオリジンフェッチリクエスト: `http://example.com/image/hello.html` [オリジンパス書き換え] リスト内の後続のルールは評価されません。

例 5：指定したパスへのプレフィックスの追加

たとえば、/live/xxx を含む URL を /image/live/xxx に書き換えることができます。ここで、xxx は任意のファイル名 (例：hello.jpg や hello.html) を表します。これにより、/live ディレクトリ下の任意のファイルへのパスに /image プレフィックスが挿入されます。

書き換え対象のパス	^/live/(.*)$
書き換え後のパス	/image/live/$1
フラグ	break
結果	元のリクエスト：`http://example.com/live/hello.jpg` 書き換え後のオリジンへのフェッチリクエスト： `http://example.com/image/live/hello.jpg` 元のリクエスト: `http://example.com/live/hello.html` 書き換え後のオリジンフェッチリクエスト： `http://example.com/image/live/hello.html` [オリジンパス書き換え] リスト内の後続のルールは評価されません。

例 6：「なし」ルールを使用した複数ルールへのマッチング

有効なルールが 2 つあるとします。ルール 1：ソースパスは ^/image_01.png$、宛先パスは /image_02.png、実行ルールは なし。ルール 2：ソースパスは ^(.*)$、宛先パスは /image$1、実行ルールは なし。

結果：

元のリクエスト：http://example.com/image_01.png
書き換え後のオリジンフェッチリクエスト: http://example.com/image/image_02.png

説明
リクエストは最初にルール 1 に一致し、http://example.com/image_02.png に書き換えられます。[フラグ] が [なし] に設定されているため、書き換えられたパスは次にルール 2 で評価され、これも一致します。パスは 2 回目に書き換えられ、最終的なパスは http://example.com/image/image_02.png になります。

例 7：「break」ルールを使用した複数ルールへのマッチング

有効なルールが 2 つあるとします。ルール 1：ソースパスは ^/image_01.png$、宛先パスは /image_02.png、実行ルールは break。ルール 2：ソースパスは ^(.*)$、宛先パスは /image$1、実行ルールは なし。

結果：

元のリクエスト： http://example.com/image_01.png
書き換え後のオリジンフェッチリクエスト： http://example.com/image_02.png

説明
リクエストは最初にルール 1 に一致し、http://example.com/image_02.png に書き換えられます。ルール 1 の[フラグ]が [break] に設定されているため、処理は停止し、後続のルールは評価されません。

ApsaraVideo VOD:オリジン URL リライト

仕組み