DCDN ノードがオリジンサーバーからリソースをフェッチすると、オリジンサーバーはレスポンスステータスコードを返します。Alibaba Cloud DCDN では、ステータスコードのキャッシュ期間を設定できます。クライアントが同じリソースを再度リクエストすると、 DCDN はオリジンフェッチをトリガーすることなくステータスコードを直接返すため、オリジンサーバーの負荷が軽減されます。設定したキャッシュ期間が終了すると、再度オリジンフェッチがトリガーされます。
注：この機能がルールエンジンのルール条件を使用する場合、実行順序はこの機能自体の優先度ではなく、ルールエンジンの優先度に従います。
利用シーン
この機能を使用して、オリジンサーバーが 2xx 以外のステータスコードを返したときに DCDN ノードが応答をキャッシュする方法を制御します。
デフォルトでは、DCDN はAlibaba Cloud CDN および DCDN のデフォルトのキャッシュルールと優先度に基づいて 2xx 応答を処理します。オリジンサーバーが 2xx 以外のステータスコードを頻繁に返す場合は、これらのコードに TTL を設定することで、DCDN ノードがキャッシュされた応答を直接返し、オリジンサーバーの負荷を軽減できます。
例
オリジンサーバーからファイルが削除された後も、クライアントがそのファイルをリクエストし続けるとします。各リクエストはオリジンフェッチをトリガーし、4xx コードが返されるため、オリジンサーバーの負荷が増加します。4xx ステータスコードをキャッシュするように設定すると、DCDN ノードは最初のフェッチ後に 4xx 応答をキャッシュします。キャッシュ期間内の後続のリクエストには、キャッシュされた 4xx 応答が直接返されます。
異常なステータスコードのキャッシュルール
204、301、305、404、405、414、424、429、500、501、502、503、504 のステータスコードの場合、キャッシュルールは次のとおりです：
オリジンサーバーが
set-cookieレスポンスヘッダーを返す場合、 DCDN は応答をキャッシュしません。オリジンサーバーが Set-Cookie レスポンスヘッダーを返さない場合、応答は DCDN コンソールで設定されたステータスコードの TTL に基づいてキャッシュされます。複数のルールが設定されている場合、有効なルールの決定方法については、「複数ルールの優先度」をご参照ください。
オリジンサーバーが Set-Cookie レスポンスヘッダーを返さず、 DCDN コンソールでステータスコードの TTL が設定されていない場合、応答はオリジンサーバーによって設定された Pragma、Cache-Control、または Expires レスポンスヘッダーに基づいてキャッシュされます。
オリジンサーバーが Set-Cookie、Pragma、Cache-Control、または Expires レスポンスヘッダーを返さず、 DCDN コンソールでステータスコードの TTL が設定されていない場合、応答はデフォルトで 1 秒間キャッシュされます。
302、307、403 のステータスコードの場合、キャッシュルールは次のとおりです：
オリジンサーバーが
set-cookieレスポンスヘッダーを返す場合、 DCDN は応答をキャッシュしません。オリジンサーバーが Set-Cookie レスポンスヘッダーを返さない場合、応答は DCDN コンソールで設定されたステータスコードの TTL に基づいてキャッシュされます。複数のルールが設定されている場合、有効なルールの決定方法については、「複数ルールの優先度」をご参照ください。
オリジンサーバーが Set-Cookie レスポンスヘッダーを返さず、 DCDN コンソールでステータスコードの TTL が設定されていない場合、応答はオリジンサーバーによって設定された Pragma、Cache-Control、または Expires レスポンスヘッダーに基づいてキャッシュされます。
オリジンサーバーが Set-Cookie、Pragma、Cache-Control、または Expires レスポンスヘッダーを返さず、 DCDN コンソールでステータスコードの TTL が設定されていない場合、応答はキャッシュされません。
304 ステータスコードの場合、 DCDN は応答をキャッシュせず、キャッシュ期間はいかなる方法でも設定できません。
400 ステータスコードなど、その他の異常なステータスコードの場合、キャッシュルールは次のとおりです：
オリジンサーバーが
set-cookieレスポンスヘッダーを返す場合、 DCDN は応答をキャッシュしません。オリジンサーバーが Set-Cookie レスポンスヘッダーを返さない場合、応答は DCDN コンソールで設定されたステータスコードの TTL に基づいてキャッシュされます。複数のルールが設定されている場合、有効なルールの決定方法については、「複数ルールの優先度」をご参照ください。
その他のシナリオでは、応答はキャッシュされません。
Range オリジンフェッチを使用するリクエストの場合、 DCDN ノードがオリジンサーバーから 206 以外のステータスコードを受信すると、 DCDN ノードはキャッシュされたスライスを削除します (オリジンフェッチのタイムアウトでは、キャッシュされたファイルは削除されません)。
Range オリジンフェッチでは、オリジンサーバーは大きなファイルを複数の小さなスライスに分割し、それらを DCDN ノードに返します。たとえば、ファイルが 10 個のスライスに分割され、 DCDN ノードが 5 つのスライスをキャッシュしているとします。ノードが 6 番目のスライスをリクエストしたときに、オリジンサーバーが 5xx ステータスコードを返した場合、以前にキャッシュされた 5 つのスライスはすべて削除されます。
ルールの優先度
リクエストが複数のキャッシュルールに一致する場合、1 つのルールのみが有効になります：
評価順序：
ルールはまずタイプ (ファイル拡張子 > ディレクトリ) で評価され、次に作成時間 (古いルール > 新しいルール) で評価されます。
異なるタイプのルールの優先度：ファイル拡張子 > ディレクトリ。
たとえば、ユーザーリクエストが ファイル拡張子と ディレクトリの 2 つのルール (両方とも 404 ステータスコード用に設定) に一致する場合、404 ステータスコードの有効期限は ファイル拡張子ルールによって決定されます。詳細な例については、「設定例」をご参照ください。
同じタイプのルールの優先度：古いルール > 新しいルール (ルールリストの上から下へ)。
たとえば、ユーザーリクエストが同じタイプ (両方とも ファイル拡張子または両方とも ディレクトリ) の 2 つのルール (両方とも 404 ステータスコード用に設定) に一致する場合、404 ステータスコードの有効期限は最初に作成されたルールによって決定されます。詳細な例については、「設定例」をご参照ください。
操作手順
-
DCDN コンソールにログインします。
-
左側のナビゲーションウィンドウで、ドメイン名 をクリックします。
-
ドメイン名 ページで、管理するドメイン名を見つけ、アクション 列の 設定 をクリックします。
-
ドメイン名の左側のナビゲーションツリーで、キャッシング をクリックします。
ステータスコードと有効期限 タブをクリックします。
追加 をクリックして、ステータスコードのキャッシュルールを作成します。
タイプ
注
タイプ
タイプを選択します：ディレクトリ または ファイル拡張子。
説明異なるタイプのルールの優先度：ファイル拡張子 > ディレクトリ。詳細については、「ルールの優先度」をご参照ください。
オブジェクト
ディレクトリ を選択した場合：
一度に追加できるディレクトリは 1 つだけです。
/で始まる完全なディレクトリパスを入力します。例：/directory/aaa。
ファイル拡張子 を選択した場合：
ファイル拡張子をカンマで区切って入力します。例：
jpg,txt。説明ファイル拡張子では大文字と小文字が区別されます。同じ拡張子に対して大文字と小文字の異なるルールを作成した場合 (例：
jpg,txtとJPG,TXT)、後のルールがjpg,txtルールを上書きします。これを避けるには、txtとjpgに対して個別のルールを作成してください。アスタリスク (
*) を使用してすべてのファイルタイプに一致させることはできません。
HTTP ステータスコードと有効期限
キャッシュするステータスコードとその TTL を秒単位で指定します (最大値：3 年)：
複数のステータスコードはカンマ (
,) で区切ります。2xx および 3xx コード：個別のコードのみ。たとえば、201=10 は有効ですが、2xx=12 は無効です。
4xx および 5xx コード：個別のコードとワイルドカードの両方がサポートされています。たとえば、401=10 と 4xx=12 は両方とも有効です。
オリジン TTL を優先
有効にすると、設定された TTL よりもオリジンサーバーのキャッシュヘッダー (
Cache-Control、Pragma) が優先されます。オリジンの No-Cache ヘッダーを無視
有効にすると、DCDN ノードは以下のオリジンの No-Cache ヘッダーを無視します：
Cache-Control: no-storeCache-Control: no-cacheCache-Control: max-age=0Pragma: no-cache
POP TTL に従う
有効にすると、DCDN ノードは最終的に有効なキャッシュポリシーをクライアントに送信します。
強制的に再検証
キャッシュ TTL が 0 に設定されている場合にのみ有効になります：
無効 (デフォルト)：DCDN の TTL が 0 の場合、ファイルは DCDN ノードにキャッシュされません。すべてのリクエストがオリジンフェッチをトリガーします。
有効：DCDN の TTL が 0 の場合、ファイルは DCDN ノードにキャッシュされますが、すべてのリクエストが再検証のためにオリジンフェッチをトリガーします。
OK をクリックします。
新しいルールが ステータスコードと有効期限 リストに表示され、そこで 変更 または 削除 できます。
設定例
例 1：ディレクトリタイプのルール
以下のようにディレクトリタイプのルールを作成します：
/directory/aaaディレクトリでは、すべての 4xx コードが 10 秒間、201 コードが 15 秒間キャッシュされます。TTL 内では、DCDN は直接応答します。有効期限が切れると、リクエストはオリジンに転送されます。例 2：ファイル拡張子タイプのルール
以下のようにファイル拡張子タイプのルールを作成します：
.jpgおよび.txtファイルでは、403 コードが 10 秒間、404 コードが 15 秒間キャッシュされます。TTL 内では、DCDN は直接応答します。有効期限が切れると、リクエストはオリジンに転送されます。例 3：異なるタイプのルールの優先度
以下のように、異なる TTL 値を持つ
ディレクトリルールとファイル拡張子ルールが作成されます：
クライアントが
http://example.com/directory/aaa/test.jpgをリクエストします。DCDN ノードはオリジンからリソースをフェッチし、オリジンは 404 を返します。このリクエストはディレクトリルールとファイル拡張子ルールの両方に一致します。ファイル拡張子 > ディレクトリ のため、ファイル拡張子ルールが適用され、404 は 20 秒間キャッシュされます。例 4：同じタイプの複数ルールの優先度
最初に
/directoryに対してディレクトリ ルール 1が作成され、次に/directory/aaaに対してディレクトリ ルール 2が、以下のように異なる TTL 値で作成されます：
クライアントが
http://example.com/directory/aaa/test.jpgをリクエストします。オリジンは 404 を返し、これは両方のディレクトリ ルールに一致します。古いルール > 新しいルール のため、ディレクトリ ルール 1が適用され、404 は 15 秒間キャッシュされます。