CDN:[オリジンフェッチパスの書き換え]

仕組み

使用上の注意

• 1 つのドメイン名に対して、最大 50 個のオリジンフェッチパスの書き換えルールを設定できます。

• ルールは上から順に適用されます。ルールの順序は、最終的なリライト結果に影響します。

• オリジンフェッチパスの書き換え ルールを設定すると、ドメイン名 > パフォーマンスの最適化 タブの [パラメーターを無視] 機能と競合する可能性があります。設定の競合を避けてください。

• オリジンフェッチパスの書き換え と オリジンフェッチパスの書き換え の両方のルールを設定した場合、[オリジンパスの書き換え] ルールによってオリジンフェッチ URL パスが変更される可能性があります。 これにより、オリジンサーバーが受信するリクエストパスが想定されたパスと異なり、404 エラーが発生する場合があります。 トラブルシューティングを行うには、一時的に オリジンフェッチパスの書き換え ルールを無効にして、リクエストが期待どおりに機能するかどうかを確認します。 両方の機能を使用する必要がある場合は、ルールの優先度と条件を調整して、意図しないパスの書き換えを防ぎます。

[アクセス URL の書き換え]と[オリジンフェッチパスの書き換え]の比較

[アクセス URL の書き換え]の図

1. クライアントは、URL old.example.com/hello へのリクエストを CDN に送信します。

2. CDN がリクエストを受信します。アクセス URL リライトルールに基づき、POP はクライアントに 302 レスポンスを返し、新しい URL new.example.com/hello を HTTP Location ヘッダーに設定します。

3. 302 レスポンスを受信した後、クライアントは新しい URL に再度リクエストを送信します。

4. POP はキャッシュを確認します。書き換えられたコンテンツがキャッシュされている場合、POP はそれを直接クライアントに返します。それ以外の場合、POP は書き換えられた URL new.example.com/hello へのオリジンフェッチリクエストをオリジンサーバーに送信します。

5. オリジンサーバーはリクエストを受信し、レスポンスを POP に返します。

6. POP はレスポンスをキャッシュし、クライアントに返します。

[オリジンフェッチパスの書き換え]の図

1. クライアントは、URL cdn.example.com/files/hello.txt へのリクエストを CDN に送信します。

2. POP はリクエストを受信し、キャッシュを確認します。リクエストされたコンテンツがキャッシュされている場合、POP はそれを直接クライアントに返します。それ以外の場合、オリジンパスリライトルールに基づき、POP はオリジンフェッチ URL を origin.example.com/secret/files/hello.txt に書き換え、リクエストをオリジンサーバーに送信します。

3. オリジンサーバーはリクエストを受信し、レスポンスを POP に返します。

4. POP はレスポンスをキャッシュし、クライアントに返します。

オリジンパスリライトの設定

1. Alibaba Cloud CDN コンソールにログインします。

2. 左側のナビゲーションペインで [ドメイン名 ] をクリックします。

3. [ドメイン名] ページで、管理対象のドメイン名を見つけ、[アクション] 列の [管理] をクリックします。

   

4. ドメイン名の左側のナビゲーションペインで、Back-to-Origin 設定 をクリックします。

5. オリジンフェッチパスの書き換え タブをクリックします。

6. 追加 をクリックします。書き換えのパス、変更後のパス、および フラグ を設定します。

   パラメータ	例	説明
   [書き換えのパス]	^/hello$	スラッシュ (/) で始まり、http:// やドメイン名を含まない URL パスです。PCRE (Perl 互換正規表現) パターンを使用する必要があります。
   [変更後のパス]	/hello/test	スラッシュ (/) で始まり、http:// やドメイン名を含まない URL パスです。PCRE がサポートされています。
   [フラグ]	なし	複数のルールを設定した場合、このルールが一致して実行された後、後続の一致するルールも順次実行されます。
   	break	複数のルールを設定し、リクエスト URL がこのルールに一致した場合、後続のルールは評価されません。 変更されるのは URL のリソースパスのみであり、URL パラメーターは変更されません。このため、オリジンフェッチパスの書き換え 機能による URL パラメーターの書き換えには影響しません。
   	enhance break	複数のルールを設定し、リクエスト URL がこのルールに一致した場合、後続のルールは評価されません。 break と同様ですが、このフラグはクエリ文字列も書き換えます。これは、オリジンフェッチパラメータの書き換え 機能と競合する可能性があります。両方の機能を使用する場合は、設定が競合しないようにしてください。

7. OK をクリックしてルールを適用します。

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

設定例

• 例 1: フラグを None に設定

  書き換え対象のパス	^/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: フラグによるブレークの強化

  書き換え対象のパス	^/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: None フラグを使用したルールの連鎖

  有効な 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 に書き換え、フラグ は なし に設定されています。リクエストがルール 1 に一致すると、フラグ が break に設定されているため、処理が停止し、後続のルールは評価されません。

  結果：

  • 元のリクエスト： http://example.com/image_01.png

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

    説明

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