アクセス URL のリライトとリダイレクトの設定 - CDN - Alibaba Cloud ドキュメントセンター

オリジンサーバー上のリソースのディレクトリが変更された場合、配信拠点（POP）上のリソースのディレクトリも変更されます。リソースへのリクエスト URL が変更されない場合、POP はリクエスト URL をリライトし、リクエストを宛先パスにリダイレクトする必要があります。これにより、オリジンリクエストの数が減り、クライアントのアクセスパフォーマンスが向上します。

背景情報

HTTP ステータスコード 302 は、Found メッセージとも呼ばれ、リクエストされたリソースが一時的に再配置されたことを示します。アクセス URL リライト機能を設定すると、POP は、HTTP ステータスコード 302 とともに返される応答の Location ヘッダーにリソースの新しい URL を追加します。クライアントは応答を受信した後、新しい URL にリクエストを送信します。

アクセス URL リライトルールを作成すると、リクエストされたリソースが再配置された場合、POP はデフォルトでクライアントに HTTP ステータスコード 302 を返します。 HTTP ステータスコードを 303 または 307 に設定することもできます。HTTP ステータスコードを変更するには、チケットを送信します。

HTTP ステータスコード	説明	解決策	シナリオ
302	検出済み	GET リクエストは変更されません。他のメソッドを使用するリクエストは、GET リクエストに変更される場合があります。	不明な理由により、Web ページに一時的にアクセスできません。この場合、検索エンジンは Web ページへの URL を更新しません。
303	その他を参照	GET リクエストは変更されません。他のメソッドを使用するリクエストは、GET リクエストに変更されます。メッセージ本文は削除されます。	ページのリフレッシュによって開始される頻繁なリクエストを防ぐために、PUT または POST リクエストの処理後に Web ページがリダイレクトされます。
307	一時的なリダイレクト	リクエストメソッドとメッセージ本文の両方が変更されません。	不明な理由により、Web ページに一時的にアクセスできません。この場合、検索エンジンは Web ページへの URL を更新しません。Web サイトが GET 以外のメソッドを使用するリクエストをサポートしている場合、HTTP ステータスコード 302 の代わりに HTTP ステータスコード 307 が返されます。

重要

ドメイン名につき最大 50 個のリライトルールを作成できます。複数のアクセス URL リライトルールを作成した場合、ルールはコンソールにリストされている降順で適用されます。

アクセス URL リライトとオリジン URL リライトの違い

機能

説明

結果

シナリオ

アクセス URL のリライト

クライアントがアクセスする URL が書き換えられ、オリジン URL も変更されます。

リダイレクト: クライアントは、リダイレクトされた URL を使用してリクエストを送信します。
中断: クライアントには、アクセスしたものと同じ URL が表示され、変更されません。

この機能は、一般的に、古いドメイン名の URL を新しいドメイン名にマッピングしたり、モバイルデバイスと PC に異なる URL を提供したりするために使用されます。

例: クライアントが old.example.com/hello にアクセスすると、アクセス URL は new.example.com/hello に書き換えられます。

オリジン URL のリライト

オリジン URL が書き換えられ、アクセス URL は変更されません。

クライアントには、アクセスしたものと同じ URL が表示され、変更されません。

この機能は、一般的に、オリジンサーバーに関する情報を保護するために、オリジンサーバーの実際の URL を隠すために使用されます。また、この機能を使用して URL をマッピングし、POP が異なるオリジンディレクトリからコンテンツを取得できるようにすることもできます。

例: クライアントが cdn.example.com/hello にアクセスすると、オリジン URL は origin.example.com/source/hello に書き換えられます。

アクセス URL のリライト

クライアントが POP にリクエストを開始します。リクエスト URL は old.example.com/hello です。
POP はリクエストを受信した後、HTTP ステータスコード 302 とともに返される応答の HTTP Location ヘッダーに新しい URL を追加し、アクセス URL リライトルールに基づいてリクエスト URL を new.example.com/hello に書き換えます。
クライアントは応答と HTTP ステータスコード 302 を受信した後、新しい URL にリクエストを開始します。
POP はキャッシュを確認します。書き換えられた URL に対応するコンテンツがキャッシュに存在する場合、POP はクライアントにコンテンツを返します。そうでない場合、POP はオリジンサーバーにリクエストを開始します。リクエスト URL は、書き換えられた new.example.com/hello です。
オリジンサーバーはリクエストを受信し、リクエストされたコンテンツを POP に返します。
POP はリクエストされたコンテンツをキャッシュし、リクエストされたコンテンツをクライアントに返します。

オリジン URL のリライト

クライアントが POP にリクエストを開始します。リクエスト URL は cdn.example.com/files/hello.txt です。
POP はリクエストを受信した後、キャッシュを確認します。リクエスト URL に対応するコンテンツがキャッシュに存在する場合、POP はクライアントにコンテンツを返します。そうでない場合、POP はオリジン URL リライトルールに基づいてオリジン URL を origin.example.com/secret/files/hello.txt に書き換え、オリジンサーバーにリクエストを開始します。
オリジンサーバーはリクエストを受信し、リクエストされたコンテンツを POP に返します。
POP はリクエストされたコンテンツをキャッシュし、リクエストされたコンテンツをクライアントに返します。

手順

Alibaba Cloud CDN コンソールにログインします。
左側のナビゲーションウィンドウで、ドメイン名 をクリックします。
ドメイン名 ページで、管理するドメイン名を見つけて、管理列の操作をクリックします。
ドメイン名の左側のナビゲーションツリーで、キャッシュ設定 をクリックします。
アクセス URL の書き換え タブをクリックします。

追加をクリックし、ビジネス要件に基づいてパラメーターを設定します。

パラメーター	説明
書き換えのパス	パスはスラッシュ (`/`) で始まり、プロトコルとドメインを含めてはなりません。 PCRE がサポートされています。例: `^/hello$`。
変更後のパス	書き換えルールで [中断] にフラグを設定した場合、パスはスラッシュ (`/`) で始まり、プロトコルとドメイン名を含めてはなりません。書き換えルールで [リダイレクト] にフラグを設定した場合、パスにはプロトコルとドメイン名を含めることができます。PCRE がサポートされています。たとえば、`$1` と `$2` は、書き換えたいパスのかっこ内のキャプチャされた文字列を参照するために使用されます。
フラグ	デフォルトでは、[リダイレクト] と [中断] がサポートされています。 [リダイレクト]: リクエスト内の URL がルールと一致する場合、POP は HTTP ステータスコード 302 を返し、リクエストは実際の URL にリダイレクトされます。POP からクライアントに返される応答メッセージの Location ヘッダーの値は、実際の URL です。元の URL のパラメーターは変更されません。現在のルールが実行された後、リクエストは他のルールと照合されます。 [中断]: リクエスト内の URL がルールと一致する場合、リクエストされた URL は実際の URL によって上書きされます。元の URL のパラメーターは変更されません。現在のルールが実行された後、他のルールはスキップされます。空、enhance-break、および enhance_redirect もサポートされています。これらのルールを使用するには、submit a ticket。空: 複数のルールが構成されていて、リクエスト内の URL がルールと一致する場合、現在のルールが実行された後に、リクエストは他のルールと照合されます。 enhance_break: enhance_break は Break と似ていますが、パラメーターを含む URL を変更します。 enhance_redirect: enhance_redirect は Redirect と似ていますが、パラメーターを含む URL を変更します。説明ルールによって書き換え方法が異なり、書き換えられた URL が他のドメイン名と他のプロトコルをサポートするかどうかにも違いがあります。空、中断、および enhance_break はリクエスト内の URL を書き換えますが、URL 内のドメイン名またはプロトコルを変更することはできません。たとえば、ルールはプロトコルを HTTP から HTTPS に変更することはできません。リダイレクトと enhance_redirect は 302 リダイレクトを使用して URL を書き換え、URL 内のドメイン名またはプロトコルを変更できます。 Location ヘッダーを現在のドメイン名または別のドメイン名に設定できます。このようにして、元の URL は `example.com` ドメイン名を使用し、書き換えられた URL は `aliyundoc.com` ドメイン名を使用します。 302 リダイレクト応答の Location ヘッダーは、異なるプロトコルをサポートしています。このようにして、元の URL は HTTP プロトコルを使用し、書き換えられた URL は HTTPS プロトコルを使用します。
[ルール条件]	ルール条件は、リクエスト内のパラメーターを識別して、構成がリクエストに適用されるかどうかを判断できます。条件を使用しないルール条件を追加または編集する場合は、ルールエンジンを参照してください。
[NGINX 変数計算を有効にする]	デフォルトでは、チェックボックスは選択されていません。このチェックボックスを選択すると、宛先 URL で NGINX 組み込み変数を使用できます。設定例: 書き換えられるパス: `^/test.jpg$` ターゲットパス: `/test.${arg_type}` NGINX 変数計算を有効にすると、${nginx_var} の値が計算されます。${arg_type} は、元の URL の type パラメーターの値を示します。説明このパラメーターを構成するには、submit a ticket。

OK をクリックします。
書き換えルールが作成されると、ルールは [アクセス URL 書き換え] タブに表示されます。[変更] または [削除] することができます。

設定例

例 1

クライアントが文字列 /hello を含む http://example.aliyundoc.com/hello をリクエストすると、POP は新しい URL http://example.aliyundoc.com/index.html を Location ヘッダーに書き込み、Location ヘッダーを HTTP ステータスコード 302 とともにクライアントに返します。クライアントは http://example.aliyundoc.com/index.html にリクエストを開始します。

Location ヘッダーにプロトコルとドメイン名が含まれていない場合、元のリクエストのプロトコルとドメイン名が使用されます。

正则表达

例 2

クライアントが文字列 /hello を含み、正規表現 ^/hello$ に一致する http://example.aliyundoc.com/hello をリクエストすると、POP は新しい URL http://example.aliyundoc.com/index.html を Location ヘッダーに書き込み、Location ヘッダーを HTTP ステータスコード 302 とともにクライアントに返します。クライアントは http://example.aliyundoc.com/index.html にリクエストを開始します。