すべてのプロダクト
Search
ドキュメントセンター

CDN:ステータスコードの有効期限を設定する

最終更新日:Nov 18, 2025

Alibaba Cloud Content Delivery Network (CDN) の POP (Point of Presence) がオリジンサーバーからリソースをフェッチすると、オリジンサーバーは応答ステータスコードを返します。CDN では、これらのステータスコードのキャッシュ期間を設定できます。クライアントが同じリソースを再度リクエストすると、CDN POP はオリジンフェッチを実行せずにステータスコードを直接返します。これにより、オリジンサーバーの負荷が軽減されます。ステータスコードのキャッシュ期間が終了すると、新しいオリジンフェッチがトリガーされます。

シナリオ

ステータスコードの有効期限を設定して、オリジンサーバーが異常なステータスコードを返したときに POP が実行するキャッシュアクションを指定できます。

通常、POP がリクエストされたリソースをオリジンサーバーから取得し、オリジンサーバーが 2xx ステータスコードを返すと、リソースは Alibaba Cloud CDN および DCDN のデフォルトのキャッシュルールと優先順位 に基づいてキャッシュされます。オリジンサーバーが 2xx 以外のコードなどの異常なステータスコードを返し、オリジンサーバーに同一のリクエストをすべて処理させたくない場合は、ステータスコードのキャッシュ期間を指定できます。これにより、POP はステータスコードをキャッシュしてクライアントに直接返すことができ、オリジンサーバーの負荷が軽減されます。

ユースケース

クライアントが、オリジンサーバーから削除されたファイル A に継続的にアクセスしようとします。POP にはファイル A のキャッシュコピーがありません。ファイル A へのすべてのリクエストはオリジンサーバーに転送され、オリジンサーバーは 4xx ステータスコードを返します。これにより、オリジンサーバーの負荷が大幅に増加します。POP が 4xx ステータスコードをキャッシュするように設定すると、POP は最初のオリジンフェッチ後に 4xx ステータスコードをキャッシュします。プリセットされたキャッシュ期間内にクライアントがファイル A を再度リクエストすると、POP はオリジンフェッチを実行せずに 4xx ステータスコードを直接返します。

異常なステータスコードのキャッシュルール

  • ステータスコード 204、305、404、405、414、424、429、500、501、502、503、および 504 の場合、キャッシュルールは次のとおりです。

    1. オリジンサーバーが set-cookie 応答ヘッダーを返す場合、CDN は応答をキャッシュしません。

    2. オリジンサーバーが Set-Cookie 応答ヘッダーを返さない場合、応答は CDN コンソールで設定したステータスコードの有効期限に基づいてキャッシュされます。複数のルールがどのように有効になるかについての詳細は、複数ルールの優先順位セクションをご参照ください。

    3. オリジンサーバーが Set-Cookie 応答ヘッダーを返さず、CDN コンソールでステータスコードの有効期限を設定していない場合、応答はオリジンサーバーからの Pragma、Cache-Control、または Expires 応答ヘッダーに基づいてキャッシュされます。

    4. オリジンサーバーが Set-Cookie、Pragma、Cache-Control、または Expires 応答ヘッダーを返さず、CDN コンソールでステータスコードの有効期限を設定していない場合、応答はデフォルトで 1 秒間キャッシュされます。

  • ステータスコード 302、307、および 403 の場合、キャッシュルールは次のとおりです。

    1. オリジンサーバーが set-cookie 応答ヘッダーを返す場合、CDN は応答をキャッシュしません。

    2. オリジンサーバーが Set-Cookie 応答ヘッダーを返さない場合、応答は CDN コンソールで設定したステータスコードの有効期限に基づいてキャッシュされます。複数のルールがどのように有効になるかについての詳細は、複数ルールの優先順位セクションをご参照ください。

    3. オリジンサーバーが Set-Cookie 応答ヘッダーを返さず、CDN コンソールでステータスコードの有効期限を設定していない場合、応答はオリジンサーバーからの Pragma、Cache-Control、または Expires 応答ヘッダーに基づいてキャッシュされます。

    4. オリジンサーバーが Set-Cookie、Pragma、Cache-Control、または Expires 応答ヘッダーを返さず、CDN コンソールでステータスコードの有効期限を設定していない場合、応答はキャッシュされません。

  • 304 ステータスコードの場合、CDN は応答をキャッシュしません。このステータスコードのキャッシュ期間は設定できません。

  • 400 などの他の異常なステータスコードの場合、キャッシュルールは次のとおりです。

    1. オリジンサーバーが set-cookie 応答ヘッダーを返す場合、CDN は応答をキャッシュしません。

    2. オリジンサーバーが Set-Cookie 応答ヘッダーを返さない場合、応答は CDN コンソールで設定したステータスコードの有効期限に基づいてキャッシュされます。複数のルールがどのように有効になるかについての詳細は、複数ルールの優先順位セクションをご参照ください。

    3. 他のシナリオでは、応答はキャッシュされません。

  • Range-Origin-Fetch を使用するリクエストの場合、CDN POP がオリジンサーバーから 206 以外のステータスコードを受信すると、CDN POP はキャッシュされたファイルシャードを削除します。オリジンフェッチのタイムアウトによって、キャッシュされたファイルシャードが削除されることはありません。

    Range-Origin-Fetch シナリオでは、オリジンサーバーは大きなファイルを複数の小さなファイルシャードに分割し、それらを CDN POP に返します。たとえば、ファイルが 10 個のシャードに分割されているとします。CDN POP はすでに 5 つのシャードをキャッシュしています。POP が 6 番目のシャードをリクエストすると、オリジンサーバーは 5xx ステータスコードを返します。この場合、以前にキャッシュされた 5 つのシャードは削除されます。

複数ルールの優先順位

複数のステータスコードのキャッシュルールを設定できます。リクエストが複数のルールに一致する場合、1 つのルールのみが有効になります。有効なルールは次のように決定されます。

  • 評価順序:

    ルールはまずタイプ (ファイル拡張子 > ディレクトリ) で評価され、次に作成時間 (古い > 新しい) で評価されます。

  • 異なるタイプのルールの優先順位: ファイル拡張子 > ディレクトリ。

    たとえば、ユーザーリクエストが 404 ステータスコード用に設定された 2 つのルールに一致するとします。ルールタイプは ファイル拡張子ディレクトリ です。404 ステータスコードの有効期限は、ファイル拡張子 タイプのルールによって決定されます。詳細については、「設定例」をご参照ください。

  • 同じタイプのルールの優先順位: 古い > 新しい (ルールリストの上から下へ)。

    たとえば、ユーザーリクエストが 404 ステータスコード用に設定された 2 つのルールに一致するとします。ルールは同じタイプで、ファイル拡張子 または ディレクトリ のいずれかです。404 ステータスコードの有効期限は、最初に作成されたルールによって決定されます。詳細については、「設定例」をご参照ください。

手順

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

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

  3. ドメイン名 ページで、ターゲットドメイン名を見つけ、操作 列の 管理 をクリックします。

  4. ドメインのナビゲーションウィンドウで、キャッシュ設定 をクリックします。

  5. HTTP ステータスコード有効期限 タブをクリックします。

  6. 追加 をクリックして、ステータスコードの有効期限を設定します。

    image

    タイプ

    タイプ

    このパラメーターは ディレクトリ または ファイル拡張子 に設定できます。必要に応じてタイプを選択します。

    説明

    異なるタイプのルールの優先順位: ファイル拡張子 > ディレクトリ。詳細については、「異常なステータスコードのキャッシュルール」をご参照ください。

    アドレス

    • タイプとして ディレクトリ を選択した場合、手順は次のとおりです。

      • 一度に追加できるディレクトリは 1 つだけです。

      • ディレクトリの完全なパスを入力します。パスはスラッシュ (/) で始まる必要があります。例: /directory/aaa

    • タイプとして ファイル拡張子 を選択した場合、パラメーターは次のように説明されます。

      • 1 つ以上のファイル拡張子を入力します。複数のファイル拡張子はコンマ (,) で区切ります。例: jpg,txt

        説明

        大文字と小文字が異なるだけで同一のファイル拡張子のルールを作成した場合、後から作成したルールが先に作成したルールを上書きします。たとえば、jpg,txt のルールを作成した後に、JPG,TXT の別のルールを作成します。JPG,TXT ルールは jpg,txt ルールを上書きします。小文字のファイル拡張子のルールを作成する場合は、txt と jpg のルールを個別に作成します。ルールでは大文字と小文字が区別されます。

      • アスタリスク (*) を使用してすべてのファイルタイプに一致させることはできません。

    設定

    キャッシュするステータスコードとそのキャッシュ期間を指定します。最大キャッシュ期間は 3 年です。単位は秒です。次のルールに従ってください:

    • 複数のステータスコードはコンマ (,) で区切ります。

    • 2xx および 3xx ステータスコードの場合、個々のステータスコードのみを指定できます。あいまい一致は使用できません。たとえば、201=10 はサポートされていますが、2xx=12 はサポートされていません。

    • 4xx および 5xx ステータスコードの場合、個々のステータスコードを指定するか、あいまい一致を使用できます。たとえば、401=10 と 4xx=12 の両方がサポートされています。

    オリジンの TTL を優先

    この機能を有効にし、オリジンサーバーが Cache-Control や Pragma などのキャッシュポリシーヘッダーを返す場合、オリジンサーバーのキャッシュポリシーが優先されます。

    オリジンの No-Cache ヘッダーを無視

    この機能を有効にすると、CDN POP は、オリジンサーバーからの次のキャッシュポリシーヘッダーを無視します。これらのヘッダーは、応答をキャッシュすべきではないことを示します。

    • Cache-Control: no-store

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

    • Pragma: no-cache

    POP キャッシュポリシーに従う

    この機能を有効にすると、CDN POP は最終的に有効なキャッシュポリシーをクライアントに返します。

    強制再検証

    このパラメーターは、キャッシュ期間が 0 の場合にのみ有効になります。効果は次のとおりです。

    • シャットダウン (デフォルト): CDN の TTL (Time-to-Live) が 0 に設定されている場合、CDN ノードはファイルをキャッシュしません。各リクエストは、コンテンツを取得するためにオリジンフェッチを実行する必要があります。

    • 有効: CDN/ の TTL が 0 に設定されている場合、ファイルは CDN/ ノードにキャッシュできますが、各リクエストはキャッシュされたコンテンツを認証するためにオリジンフェッチを必要とします。

  7. OK をクリックします。

    ステータスコードの有効期限を設定した後、有効期限 タブのリストでルールを見つけることができます。ルールを 変更 または 削除 できます。

設定例

  • 例 1: ディレクトリールール

    次の図は、ディレクトリールールの作成方法を示しています。示例一

    /directory/aaa ディレクトリでは、すべての 4xx ステータスコードは 10 秒間キャッシュされ、201 ステータスコードは 15 秒間キャッシュされます。これらの時間範囲内では、POP はアクセスリクエストに直接応答します。キャッシュ期間が終了すると、リクエストはオリジンサーバーにリダイレクトされます。

  • 例 2: ファイル拡張子ルール

    次の図は、ファイル拡張子ルールの作成方法を示しています。示例二

    .jpg または .txt 拡張子を持つファイルの場合、403 ステータスコードは 10 秒間キャッシュされ、404 ステータスコードは 15 秒間キャッシュされます。これらの時間範囲内では、POP はアクセスリクエストに直接応答します。キャッシュ期間が終了すると、リクエストはオリジンサーバーにリダイレクトされます。

  • 例 3: 異なるタイプのルールの優先順位

    次の図に示すように、ディレクトリールールとファイル拡張子ルールが、ステータスコードに対して異なる有効期限で作成されます。示例三

    ユーザーが http://example.com/directory/aaa/test.jpg をリクエストします。リソースは POP にキャッシュされていません。POP はオリジンサーバーにリソースをリクエストし、オリジンサーバーは 404 ステータスコードを返します。リクエストはディレクトリールールとファイル拡張子ルールの両方に一致します。ルールの優先順位は、異なるタイプのルールの場合 ファイル拡張子 > ディレクトリ であるため、ファイル拡張子ルールが有効になります。404 ステータスコードの実際のキャッシュ期間は 20 秒です。

  • 例 4: 同じタイプの複数ルールの優先順位

    まず、/directory パスに対してディレクトリルール 1 が作成されます。次に、/directory/aaa パスに対してディレクトリルール 2 が作成されます。ルールには、次の図に示すように、ステータスコードに対して異なる有効期限があります。示例四

    ユーザーが http://example.com/directory/aaa/test.jpg をリクエストします。リソースは POP にキャッシュされていません。POP はオリジンサーバーにリソースをリクエストし、オリジンサーバーは 404 ステータスコードを返します。リクエストは両方のディレクトリールールに一致します。ルールの優先順位は、同じタイプのルールの場合 古い > 新しい であるため、最初に作成されたディレクトリルール 1 が有効になります。404 ステータスコードの実際のキャッシュ期間は 15 秒です。

関連 API

BatchSetCdnDomainConfig