CDN:キャッシュに関するよくある質問

キャッシュエビクションメカニズムとは何ですか？

ノードにキャッシュされたリソースのアクセス頻度が低い場合 (同一ノードでのアクセスがまれな場合) 、キャッシュの有効期限が切れる前に、より人気のあるリソースによって当該リソースがエビクトされることがあります。

デフォルトのキャッシュルールとは何ですか？

ノードがオリジンサーバーからファイルリソースを受信すると、優先度の高い順に (高い順から低い順) 次のキャッシュルールを適用します：

• オリジンサーバーが pragma:no-cache ヘッダー、または値が no-cache、no-store、max-age=0 の cache-control ヘッダーを返した場合、オリジンサーバーのポリシーに従い、リソースをキャッシュしません。

• コンソールで設定したキャッシュの有効期限、またはステータスコードの有効期限。

• オリジンサーバーで設定したその他のキャッシュルールは、次の優先順で処理されます： cache-control > expires > last-modified > ETag。

• オリジンレスポンスの cache-control ヘッダーに、0 より大きい max-age または s-maxage の値が含まれている場合、cache-control ヘッダーを使用してキャッシュの有効期限を設定します。例： cache-control:max-age=3600。 max-age と s-maxage の両方が存在する場合、s-maxage が優先されます。

• オリジンレスポンスに cache-control ヘッダーが含まれていないものの、Expires ヘッダーが含まれている場合、Expires ヘッダーを使用してキャッシュの有効期限を設定します。例： expires:Tue, 25 Nov 2031 17:25:43 GMT。

• オリジンレスポンスに cache-control または Expires ヘッダーが含まれていないものの、last-modified ヘッダーが含まれている場合、キャッシュ時間は (現在時刻 – last-modified) × 0.1 として計算され、最小 10 秒、最大 3,600 秒に制限されます。

• オリジンレスポンスに cache-control、Expires、last-modified ヘッダーが含まれていないものの、ETag ヘッダーが含まれている場合、リソースは 10 秒間キャッシュされます。

• オリジンレスポンスに cache-control、expires、last-modified、ETag ヘッダーが含まれていない場合、デフォルトではリソースはキャッシュされません。

キャッシュポリシーにおける "origin server" とは何を指しますか？OSS の設定や HTML <meta> タグを意味しますか？

"Origin server" は、OSS や Elastic Compute Service (ECS) などのバックエンドストレージ、またはアプリケーションサーバーから返される HTTP レスポンスヘッダーを指し、HTML コード内の <meta> タグは指しません。

キャッシュポリシーを決定する際は、Cache-Control や Expires など、HTTP レスポンス内でオリジンサーバーから返されるヘッダーのみを読み取ります。HTML の <meta> タグにある http-equiv="Cache-Control" 属性はブラウザーにのみ影響し、CDN では解析されません。

4 つのキャッシュ設定スイッチ (オリジンの TTL を優先、レスポンスヘッダーを無視、CDN のキャッシュルール優先、および コンテンツの強制再検証) がデフォルトのオフ状態のままになっている場合、その動作は、有効期限のみが設定されていた以前の設定と同じですか？

はい。 4 つのトグルがすべて Off の場合、コンソールで設定したキャッシュの有効期限ルールに基づいてコンテンツをキャッシュし、レガシーの動作と同じになります。各トグルの詳細については、「Configure CDN Cache Expiration Time」のパラメーター説明をご参照ください。

高速化ドメイン名を作成する際に、ビジネスタイプ ([Images & Small Files] や [Large File Downloads] など) を選択すると、デフォルトのキャッシュポリシーは適用されますか？

高速化ドメイン名を作成する際に選択するビジネスタイプ ([Images & Small Files] や [Large File Downloads] など) が、デフォルトのキャッシュポリシーに与える影響はほとんどありません。特定のファイル拡張子やパスに対して固定のキャッシュ時間を事前設定することはありません。

実際のキャッシュ動作は、コンソールでの設定によって決まります。ドメイン名を作成した後、「Configure CDN Cache Expiration Time」に移動し、リソースタイプと更新頻度に基づいてキャッシュルールを設定してください。

ノード HTTP レスポンスヘッダーとオリジン HTTP レスポンスヘッダーの違いは何ですか？

キャッシングアーキテクチャでは、ノード HTTP レスポンスヘッダーとオリジン HTTP レスポンスヘッダーは、データ配信の異なる段階における HTTP ヘッダー情報を指します。

• ノード HTTP レスポンスヘッダー (アウトバウンドレスポンスヘッダー)：ノードからブラウザーなどのクライアントに送信される HTTP レスポンスヘッダーです。ノードにコンテンツがキャッシュされている場合、オリジンサーバーにリクエストせずに、コンテンツをクライアントに直接返します。

• オリジン HTTP レスポンスヘッダー (インバウンドレスポンスヘッダー)：オリジンサーバーからノードに送信される HTTP レスポンスヘッダーです。ノード上のキャッシュの有効期限が切れた場合、またはキャッシュミスが発生した場合、ノードはオリジンフェッチを実行して最新のコンテンツを取得します。このコンテンツとともにオリジンサーバーから返されるヘッダーが、オリジン HTTP レスポンスヘッダーとなります。

主な違いは適用範囲です。ノードヘッダーはクライアントと CDN 間のキャッシュ動作を制御し、オリジンヘッダーはオリジンサーバーと CDN 間のキャッシュ動作を制御します。両者を組み合わせることで、精密かつ効率的なキャッシュ制御が可能になります。インバウンドレスポンスヘッダーの詳細については、「Modify Inbound Response Headers」をご参照ください。

複数コピーキャッシュはサポートされていますか？どのように動作しますか？

CDN はデフォルトで複数コピーキャッシュをサポートしています。オリジンサーバーは、個別のキャッシュコピーを作成するためにどのリクエストヘッダー値を使用するかを CDN ノードに伝える Vary ヘッダーを含める必要があります。

たとえば、クライアントが Accept-Encoding: gzip を指定してリクエストを送信すると、オリジンサーバーは gzip 圧縮されたコンテンツを返します。別のクライアントが Accept-Encoding: br を指定すると、オリジンサーバーは Brotli 圧縮されたコンテンツを返します。これらの異なるバージョンを別々にキャッシュするには、コピーを区別するリクエストヘッダーを指定する Vary ヘッダーをオリジンサーバーが含める必要があります。この場合、オリジンサーバーは Vary: Accept-Encoding を設定します。これにより、Accept-Encoding リクエストヘッダー値に基づいて、CDN は個別のキャッシュコピーを保存および配信します。

キャッシュルールのグローバル適用方法

キャッシュの有効期限を設定することで、キャッシュルールを全体的に適用できます。すべてのディレクトリに一致させるには、タイプ を ディレクトリ に設定し、「オブジェクト」 フィールドにスラッシュ (/) を入力します。詳細については、「CDN のキャッシュ有効期限を設定する」をご参照ください。

CDN キャッシュを無効化または制限する関連シナリオを、次の 3 つのよくある質問で説明します。ユースケースに合うものを選択してください：

• Full-site no-cache：ドメイン上のすべてのリソースのキャッシュを無効化します。

• Static-only caching：静的ファイルをキャッシュし、動的リクエストはオリジンサーバーへパススルーします。

• Path-specific passthrough：特定のディレクトリ、API、または動的リソースパスのキャッシュを無効化します。

ドメイン全体のキャッシュ無効化方法

Alibaba Cloud CDN でドメイン名全体のキャッシュを無効化するには、すべてのパスのキャッシュの有効期間を 0 に設定し、このルールの重みが最も高くなるようにします。手順は次のとおりです：

• キャッシュ有効期限 タブで、追加 をクリックします。

• [タイプ]: ディレクトリ を選択します。

• アドレス：/ を入力して、すべてのパスに一致させます。

• 有効期限：0s を入力します。

• その他のパラメーターはデフォルト設定のままにします。

• OK をクリックして設定を完了します。

Alibaba Cloud CDN へのリクエストが複数のキャッシュルールに一致する場合は、優先度が最も高いルールのみが有効になります。優先度は次の順序で決まります：重み > ルールの作成時刻。

キャッシュ有効期限 ページに複数のルールがある場合は、ドメイン全体のキャッシュなしルールの 重み が最も高くなるように設定してください (これにより、最も高い優先度になります)。

静的ファイルのみをキャッシュし、動的ページはオリジンサーバーへパススルーするための設定

重み付きの「許可リスト／ブロックリスト」方式を使用します：

• 優先度の高い静的キャッシュルールを作成します：[Type] を [拡張子] に設定し、[Object] に jpg,png,css,js などの静的ファイルの拡張子を指定したルールを 1 つ以上追加します。キャッシュ期間を長め (例：1 か月) に設定し、重み を高め (例：90～99) に設定します。

• 優先度の低い動的 no-cache ルールを作成します：[Type] を [Directory] に設定し、[Object] を / (ルートディレクトリ) に設定したルールを追加します。[Expire In] を 0 秒 (キャッシュなし) に設定し、重み を低め (例：1～10) に設定します。

• 特定の動的パス向けに最適化します：/api/ や /wp-admin/ など、絶対にキャッシュしてはならない動的パスがある場合は、パスごとにディレクトリルールを追加し、キャッシュ期間を 0 秒に設定します。さらに、最初に一致するように 重み を最大 (例：99) に設定します。

動的リソース、API、または特定ディレクトリに対するパススルー (キャッシュなし) の設定

動的コンテンツのシナリオに応じてキャッシュの有効期間を 0 秒に設定すると、リクエストがオリジンサーバーへパススルーされるようにできます：

• 動的ページと API のキャッシュ無効化: PHP ページ、ASP.NET ページ、API エンドポイント、リアルタイム通信 (長時間接続)、およびバックエンドアップロード API などの動的コンテンツについては、ファイル拡張子 ルールを追加します。関連する拡張子 (例: php,aspx,jsp) を入力し、有効期限 を 0 秒に設定します。これにより、すべてのリクエストがオリジンサーバーに送信されるようになり、キャッシュされた動的コンテンツに起因する無効な CAPTCHA、予期しないログイン状態、または画像アップロードの失敗などの問題を防ぐことができます。

• 特定のディレクトリのキャッシュを無効にする：/api/ や /wp-admin/ などの特定のディレクトリで「アクセラレーションを無効にする」のと同様の効果を得るには、ディレクトリ ルールを追加します。対象のディレクトリパスを入力し、有効期限を 0 秒に設定します。CDN はディレクトリのアクセラレーションを直接無効にすることをサポートしていませんが、この設定により、リクエストはオリジンサーバーにパススルーされます。

• ルートディレクトリとサブディレクトリの優先順位: ルートディレクトリ / 配下の他のリソースをキャッシュせずに、特定のサブディレクトリ (例: /static/) のみをキャッシュするには、2 つの個別のルールを設定します。 /static/ のルールには、高い 重み (例: 99) を割り当てます。 次に、キャッシュの有効期限が 0 秒で、重みが低い (例: 1) ルートディレクトリ / のルールを作成します。 サイト全体のキャッシュが動的 API で問題を引き起こす場合は、サイト全体のキャッシュルールを削除し、代わりにファイル拡張子または特定の静的ディレクトリによるキャッシュを設定します。

• SPA と HTML ページのキャッシュ問題：シングルページアプリケーション (SPA) で 404 エラーが返る、または想定外のログインリダイレクトが発生する場合は、.html または index.html に対してキャッシュが設定されていないか確認してください。HTML ファイルのキャッシュを無効化 (有効期間を 0 秒に設定) するか、またはオリジンレスポンスから Cache-Control ヘッダーを削除したうえで、パージ を実行します。

.aspx の拡張子ルールを 0 秒に設定すると、サイト全体のキャッシュは無効化されますか？

サイト上のすべてのページが .aspx 拡張子で終わる場合、.aspx のキャッシュの有効期間を 0 に設定すると、実質的にサイト全体のキャッシュが無効化されます。

サイト全体のルールとして、範囲の広い拡張子を使用しないでください。代わりに、特定のファイルパスまたはディレクトリに対してキャッシュルールを設定してください。たとえば、/static/ ディレクトリには長いキャッシュ期間を設定し、/api.aspx などの動的 API エンドポイントには、キャッシュを無効化する (0 秒) ためのルールを別途作成してください。

robots.txt と sitemap.xml のキャッシュ期間の設定

これらのファイルは検索エンジンによるサイトのクロール方法に直接影響するため、更新頻度に基づいて個別のキャッシュ期間を設定してください。これにより、デフォルトルールによって長期間キャッシュされ、サイト更新の検知が遅れることを防止できます。

sitemap の更新頻度が高い場合は、キャッシュ期間を 1 時間以内に設定してください。robots.txt のルールが安定している場合は、より長いキャッシュ期間を設定できます。

CDN のキャッシュルール優先 トグルの有効化／無効化の判断

このトグルは、Alibaba Cloud CDN が独自のキャッシュポリシー (例：max-age=3600) をレスポンスヘッダー経由でクライアントのブラウザーに渡すかどうかを制御します：

• Off (デフォルト)：Alibaba Cloud CDN ノードは設定済みのルールに基づいて引き続きリソースをキャッシュしますが、このポリシーをブラウザーに送信するレスポンスヘッダーには含めません。この場合、ブラウザーのキャッシュ動作は、[Modify Outbound Response Header] 機能で設定したヘッダーのみによって決まります。

• On：Alibaba Cloud CDN が Cache-Control などのヘッダーをブラウザーに送信し、ブラウザーとノードで同じキャッシュポリシーが使用されるようにします。

[Modify Outbound Response Header] 機能で、クライアント向けのヘッダーをすでに想定どおり設定できている場合は、このトグルをデフォルトの Off のままにしてください。冗長なリクエストを減らすために、ブラウザー側でもポリシーを再利用させたい場合は有効化してください。

大容量ファイルのキャッシュ方法

Alibaba Cloud CDN は、大容量ファイルのダウンロードシナリオにおけるキャッシュをサポートしています。キャッシュの有効期間ルールを設定して、これらのファイルをノードに長期間保存できます。これにより、キャッシュヒット率が向上し、オリジンフェッチのコストを削減できます。

設定の推奨事項：

• キャッシュ期間：更新頻度の低い大容量ファイルの場合、キャッシュの有効期間を 1 か月以上に設定します。

• オリジンサーバーの no-cache ディレクティブ：オリジンサーバーが Cache-Control: no-cache、no-store、または max-age=0 などのディレクティブを返さないようにしてください。オリジンサーバーを制御できない場合は、キャッシュルールで レスポンスヘッダーを無視 オプションを選択してください。

• 大容量ファイルのプリフェッチ：大容量ファイルへの初回リクエストはレイテンシーが高くなる場合があります。配信前に prefetch タスクを送信し、事前にファイルをノードへ配信してください。

HTTP レスポンスヘッダーによるオリジン間リソース共有 (CORS) の設定

適切な HTTP レスポンスヘッダーを設定し、異なるオリジンからのリクエストがリソースへアクセスできるようにします。詳細については、「Configure Cross-Origin Resource Sharing」をご参照ください。

リソースがキャッシュされているか確認する方法

Alibaba Cloud がリソースをキャッシュしているかどうかは、次の HTTP レスポンスヘッダーで確認できます：

• X-Cache：リクエストがキャッシュヒットしたかどうかを示します。値が HIT の場合はキャッシュヒットです。値が MISS の場合、またはこのヘッダーが存在しない場合はキャッシュミスです。

• Age：ファイルがノードにキャッシュされている時間 (秒) を示します。このヘッダーは、キャッシュが消去されたオブジェクト、または初回リクエストでは存在しません。Age の値が 0 の場合、キャッシュの有効期限が切れており、再検証のためにオリジンフェッチが必要です。

• X-Swift-CacheTime：ノード上でファイルに許可される最大キャッシュ時間を示します。残りのキャッシュ時間は X-Swift-CacheTime – Age で計算できます。

• X-Swift-SaveTime：リソースがノードに最初にキャッシュされた時刻 (GMT) を示します。中国標準時 (UTC+8) に変換するには、8 時間加算します。

次のいずれかの方法で HTTP レスポンスヘッダーを確認し、コンテンツが CDN にキャッシュされているかどうかを確認できます：

方法 1：ブラウザの開発者ツール (Chrome DevTools など) を使用

[Network] パネルで [Response Headers] を確認します。CDN のキャッシュ関連ヘッダーである Age、X-Cache、X-Swift-CacheTime、X-Swift-SaveTime に注目してください。

Response Headers
Access-Control-Allow-Origin:    *
Age:    860
Ali-Swift-Global-Savetime:    1704259214
Cache-Control:    max-age=28800,s-maxage=3600
Content-Encoding:    gzip
Content-Length:    2618
Content-Md5:    /h0oxujZUUo1P8gMA893oQ==
Content-Type:    text/html
Date:    Wed, 03 Jan 2024 05:20:14 GMT
Eagleid:    db9062a517042600741495981e
Server:    Tengine
Timing-Allow-Origin:    *
Vary:    Accept-Encoding
Via:    cache49.l2cn3032[0,0,200-0,H], cache8.l2cn3032[3,0], cache8.l2cn3032[3,0], ens-cache16.cn3573[0,0,200-0,H], ens-cache17.cn3573[43,0]
X-Cache:    HIT TCP_MEM_HIT dirn:10:498457979
X-Oss-Hash-Crc64ecma:    1068125902847643907
X-Oss-Object-Type:    Normal
X-Oss-Request-Id:    6594EE8E1FC2C239355F41E1
X-Oss-Server-Time:    3
X-Oss-Storage-Class:    Standard
X-Source-Scheme:    https
X-Swift-CacheTime:    3600
X-Swift-SaveTime:    Wed, 03 Jan 2024 05:20:14 GMT

方法 2：curl コマンドを使用

次のコマンドを実行して、リソースの CDN レスポンスヘッダーを確認します：

curl -v "http://example.com/path/to/response.html"

次に、curl の出力例を示します：

F:\test>curl http://cdn.xxx.top/pic_03.jpg -v
* Host cdn.xxx.top:80 was resolved.
* IPv6: (none)
* IPv4: 1xxx
*   Trying 1xxx:80...
* Connected to cdn.xxx.top (xxx) part 80
> GET /pic_03.jpg HTTP/1.1
> Host: cdn.xxx.top
> User-Agent: curl/8.9.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: Tengine
< Content-Type: image/jpeg
< Content-Length: 8775526
< Connection: keep-alive
< Date: Mon, 26 May 2025 02:21:59 GMT
< x-oss-request-id: 68xxx9A
< x-oss-cdn-auth: success
< Accept-Ranges: bytes
< ETag: "Bxxx2"
< Last-Modified: Tue, 03 Sep 2024 06:20:19 GMT
< x-oss-object-type: Normal
< x-oss-storage-class: Standard
< x-oss-hash-crc64ecma: 12xxx58
< x-oss-server-time: 228
< Via: cache20.l2cn3032[0,0,200-0,H], cache10.cn3573[0,0,200-0,H], cache10.cn3573[1,0]
< Age: 424
< X-Cache: HIT TCP_HIT dirn:0:698837654
< X-Swift-SaveTime: Mon, 26 May 2025 02:21:59 GMT
< X-Swift-CacheTime: 2592000
< Ali-Swift-Global-Savetime: 1748226119
< Timing-Allow-Origin: *
< EagleId: 08xxx51
<
* Connection #0 to host cdn.xxx.top left intact

このレスポンスでは、X-Cache: HIT TCP_HIT は CDN のキャッシュヒットを示します。Age: 424 は、リソースが 424 秒間キャッシュに保存されていることを示します。X-Swift-CacheTime: 2592000 は、キャッシュの有効期間が 2,592,000 秒 (30 日) であることを示します。

キャッシュルールの設定後も、テストリクエストがキャッシュミスになる、またはオリジンサーバーに到達するのはなぜですか？

次の手順でトラブルシューティングを行います：

• 設定ステータスを確認します：コンソールのキャッシュ設定ステータスが "Configured" と表示されていることを確認します。

• ルールの優先度を確認します：複数のルールがある場合は、対象パスに一致するルールの重みが最大であることを確認します。たとえば、/static/ など、特定ディレクトリのルールは、ルートディレクトリ (/) のデフォルトルールより高い重みを設定する必要があります。

• オリジンレスポンスヘッダーを確認します：オリジンサーバーが Cache-Control: no-cache/no-store/max-age=0 または Pragma: no-cache を返しており、レスポンスヘッダーを無視 オプションが有効になっていない場合、CDN はオリジンの指示に従い、リソースをキャッシュしません。このオプションを有効にするか、オリジンサーバーの設定を調整してください。

• リクエストメソッドを確認します：テストには HEAD リクエスト (例：curl -I) ではなく、GET リクエスト (例：curl -voa) を使用してください。HEAD リクエストでは、リソース本文に対する L1 ノードのキャッシュロジックが実行されない場合があり、誤って MISS となることがあります。

• URL パラメーターを確認します：URL にクエリパラメーターが含まれている場合は、[Ignore URL Parameters] 機能が有効になっているか確認します。無効の場合、パラメーターが異なる URL は別リソースとして扱われます。有効の場合、同一リソースとして扱われます。

キャッシュルールの変更後にステータスが "Configuring" と表示されます。問題ありませんか？サービスへの影響はありますか？

• 設定ステータス：キャッシュルールを追加または変更すると、ルールの ステータス が "Configuring" と表示されるのは正常です。これは、設定がネットワーク全体の CDN ノードに伝播していることを示します。通常、数分以内にステータスは "Configured" に変わります。長時間変わらない場合は、ページを更新して最新のステータスを確認してください。

• サービスへの影響：キャッシュルールの変更は、既存サービスの可用性に影響しません。新しいルールは新規リクエストにのみ適用されます。CDN ノードにすでにキャッシュされているコンテンツは、キャッシュの有効期限が切れるまで、以前のポリシーに基づいて配信され続けます。すべてのリクエストに対して新しいルールを直ちに適用する必要がある場合は、キャッシュの消去 を実行して古いキャッシュをクリアしてください。

オリジンサーバー上のファイルが変更された後、ノード上のキャッシュは自動的に更新されますか?

いいえ。オリジンサーバー上のファイルを変更しても、ノード上のキャッシュはリアルタイムで自動的に更新されません。キャッシュの更新は、設定されたキャッシュポリシーに依存します。

• CDN ノードは、設定されたキャッシュの有効期限に基づいてキャッシュを更新します。リソースのキャッシュの有効期限が切れていない場合、オリジンサーバーでの変更はキャッシュにすぐには反映されません。詳細については、「CDN キャッシュの有効期限の設定」をご参照ください。

• キャッシュを手動でパージすることで、次のリクエストを強制的にオリジンサーバーにリダイレクトし、最新のコンテンツを取得させることができます。

• コンソールで：リソースのパージとプリフェッチ

• API を呼び出す：RefreshCache

Cache-Control: no-cache を設定した後、ブラウザのキャッシュをクリアせずにユーザーは最新のファイルにアクセスできますか?

保証されません。Cache-Control: no-cache は、リクエストごとに条件付きキャッシュリクエストを送信するようクライアントに指示するだけです。ノードに有効期限が切れていないファイルのキャッシュコピーがまだ存在する場合、キャッシュされたコンテンツを直接返すか、検証のためにオリジンフェッチを実行することがあります。オリジンサーバー上のファイルが更新されてもキャッシュが更新されていない場合、ユーザーに古いファイルが表示されることがあります。

オリジンサーバー上のファイルを更新した後は、コンソールでパージまたはプリフェッチ操作を実行してください (リソースのパージとプリフェッチをご参照ください)。これにより、ノードはオリジンサーバーから最新のリソースを強制的に取得し、ユーザーが最新のファイルにアクセスできるようになります。

分単位またはほぼリアルタイムのキャッシュ更新を実現するにはどうすればよいですか?

分単位の更新を実現するには、次の手順に従ってください。

• コンソールで、対象ファイルに短いキャッシュの有効期限 (例：60 秒) を設定します。

• [コンテンツの強制再検証] トグルを有効にします。

• [オリジンの TTL を優先] トグルを無効にします。

以前に長いキャッシュ期間を設定していた場合は、リソースのパージとプリフェッチ機能を使用して古いキャッシュをパージする必要があります。これにより、新しい設定がすぐに有効になります。

ミリ秒単位のリアルタイム更新が必要な場合は、キャッシュポリシーを調整する代わりに、オリジンサーバー上でバージョン管理されたファイル名 (style-a1b2c3d.css など) を使用してください。詳細については、「CDN キャッシュの有効期限の設定」をご参照ください。

キャッシュが更新されないとき、有効期限を変更する必要がありますか?

有効期限を変更する必要はありません。1 回限りの更新をすぐに有効にするには、次の 2 つの手順に従ってください。

• [コンテンツの強制再検証] トグルを有効にし、[オリジンの TTL を優先] トグルを無効にします。

• リソースのパージとプリフェッチページで、対応するファイルのパージタスクを送信します。

この操作は、古いキャッシュコンテンツをクリアするだけです。次のリクエストはオリジンフェッチを実行して最新のリソースを取得し、その後のリクエストは通常どおりキャッシュにヒットします。

コンソールでキャッシュ有効期限を 0 に設定しましたが、コンテンツが古いままなのはなぜですか？

コンソールでキャッシュ有効期限を 0 に設定する目的は、すべてのリクエストがオリジンサーバーから最新のコンテンツをフェッチするようにするためです。それでも古いコンテンツを受信する場合、原因として以下のいずれかが考えられます：

• ブラウザキャッシュ：ブラウザが古いコンテンツをキャッシュしている可能性があります。ブラウザのキャッシュをクリアするか、シークレットモードでテストしてください。

• 設定の伝播遅延：キャッシュ期間を 0 に設定した後、新しい設定がすべてのノードに伝播するまでに時間がかかる場合があります。ノードがまだ変更を受信していない場合、古いキャッシュコンテンツを返す可能性があります。

• オリジンサーバーのキャッシュ：オリジンサーバーに独自のキャッシュメカニズムがある場合があります。オリジンサーバーのキャッシュが速やかに更新されない場合、ノードはオリジンフェッチ中に古いコンテンツをフェッチする可能性があります。

• ノードキャッシュのクリア遅延：設定を変更する前にキャッシュされたリソースは、クリアされるまでに時間がかかる場合があります。手動でキャッシュをパージすることで、すぐに最新のコンテンツを取得できます。詳細については、「リソースのパージとプリフェッチ」をご参照ください。

キャッシュルールが有効にならないのはなぜですか？

キャッシュルールを設定したにもかかわらず有効にならない場合、原因として以下のいずれかが考えられます：

• 伝播遅延：キャッシュルールの変更がネットワーク全体に伝播するまでには、時間がかかる場合があります。ルールが完全に有効になるまで待ってから、ご確認ください。

• キャッシュ更新の仕組み：新しいルールは、すでにキャッシュされているコンテンツにはすぐには適用されません。既存のキャッシュコンテンツの有効期限が切れた後にのみ適用されます。

• キャッシュパージが未実行：キャッシュ設定の変更後、手動でキャッシュをパージしないと、ユーザーは有効期限が切れるまで古いキャッシュコンテンツを受信し続けます。詳細については、「リソースのパージとプリフェッチ」をご参照ください。

• 不適切なキャッシュレスポンスヘッダー：オリジンサーバーからの HTTP レスポンスヘッダーを確認し、Cache-Control および Expires ヘッダーが正しく設定されていることを確認してください。

• キャッシュルールの優先度：リクエストが複数のルールに一致する場合、優先度は「重み > ルールの作成時間」の順で決定されます。

• 複数のキャッシュルールが存在する場合、各ルールに異なる重みを割り当てることで実行優先度を制御します。重みが大きいほど優先度が高くなります。

• 同じ重みを持つルールの場合、ルールの種類に関係なく、先に作成されたルールが優先されます。

設定例：高速化ドメイン名 demo.aliyun.com に次のキャッシュルールが設定されているとします。ノードがオリジンサーバーからリソース http://demo.aliyun.com/image/example.png をフェッチすると、次の両方のルールに一致します。両方のルールの重みが同じであるため、先に作成されたルールが優先されます。この例では、/image ディレクトリのルールが先に作成されたため、システムはディレクトリタイプのルールを適用します。キャッシュルールの設定リストには、次の2つのルールが表示されます：

• コンテンツ： jpg,png、タイプ： [ファイル拡張子]、有効期限：1か月、重み：10、ステータス： 設定完了。

• コンテンツ： /image、タイプ： [ディレクトリ]、有効期限：1日、重み：10、ステータス： [設定済み]。 両方のルールで、オリジンの TTL を優先、レスポンスヘッダーを無視、CDN のキャッシュルール優先、コンテンツの強制再検証 は無効になっています。各ルールは [変更] および [削除] 操作に対応しています。

Access-Control-Allow-Origin レスポンスヘッダーを設定しましたが、依然として CORS の問題が発生します。なぜですか？

Alibaba Cloud CDN で Access-Control-Allow-Origin などオリジンからのレスポンスヘッダーを設定したにもかかわらず、クライアントで依然としてクロスオリジンの問題が発生し、設定したヘッダーがレスポンスに含まれていない場合、原因として以下のいずれかが考えられます：

考えられる原因

• 不正確または無効な設定：設定が不正確であるか、完全に伝播していない可能性があります。

• CDNキャッシュ：CDN ノードが、古いヘッダーを含むレスポンスを返している可能性があります。

• オリジンサーバーの問題：オリジンサーバーからのクロスオリジン関連のレスポンスヘッダーが CDN の設定と競合しています。

• ブラウザキャッシュ：ブラウザが古いレスポンスをキャッシュしています。

解決策

• 設定の確認：CDN の設定が正しく、有効になっていることを確認してください。

• CDNキャッシュのパージ：パージとプリフェッチ 機能を使用してキャッシュをクリアし、再度リソースにアクセスしてください。詳細については、「リソースのパージとプリフェッチ」をご参照ください。

• オリジンサーバー設定の確認：オリジンサーバーが CDN の設定と競合するクロスオリジン関連のレスポンスヘッダーを返さないようにしてください。オリジンサーバーと CDN の両方で、CORS ヘッダーの設定を統一してください。

• ブラウザキャッシュのクリア：ブラウザのキャッシュをクリアするか、シークレットモードでテストしてください。

動画再生中の ERR_CONTENT_LENGTH_MISMATCH エラーのトラブルシューティング方法

• 原因：このエラーは通常、CDN ノードにキャッシュされたファイルの長さがオリジンサーバー上の実際のコンテンツと異なる場合や、オリジンサーバーが異常な Content-Length レスポンスヘッダーを返す場合に発生します。これは、動画ファイルがオリジンサーバーで更新されたにもかかわらず、CDN が古いキャッシュバージョンを配信している場合によく見られます。

• 解決策：

• CDN コンソールの [パージとプリフェッチ] ページで、動画 URL のパージリクエストを送信し、CDN ノードから古いキャッシュをクリアしてください。

• オリジンサーバーが OSS の場合は、CDN キャッシュの自動更新を有効にできます。この機能は、オリジンサーバー上のファイルが更新された後、自動的に CDN のキャッシュパージをトリガーします。

• オリジンサーバーの安定性とレスポンスの一貫性を確認し、断続的に異常な Content-Length を返さないことを確認してください。

• ステータスコード 206 について：動画プレーヤーは通常、Range リクエストを使用して動画コンテンツをセグメント単位でロードします。リクエストが CDN キャッシュにヒットした場合でも、CDN が 206 Partial Content ステータスコードを返すのは正常な動作です。

静的ファイルはキャッシュヒットしますが、ホームページの読み込みが遅いのはなぜですか？

静的リソース (画像、CSS、JS など) はキャッシュヒットし、期待どおりに高速化されていますが、ホームページ (ルートパス /) の読み込みにはまだ数秒かかります。これは通常、ホームページへのリクエストにキャッシュルールが設定されておらず、アクセスごとにオリジンサーバーからデータをフェッチする必要があるためです。その結果、読み込み速度はオリジンサーバーの処理時間に依存します。

解決策：高速化ドメイン名のルートディレクトリにキャッシュ有効期限ルールを追加します。これにより、ノードがホームページコンテンツをキャッシュし、オリジンフェッチの数を減らすことができます。

• キャッシュ有効期限 タブで、追加 をクリックします。

• タイプ で ディレクトリ を選択します。

• アドレス に / を入力します。

• 有効期限 で、ホームページの更新頻度に基づいて30秒から数分などの期間を設定します。

• 重み で、他のキャッシュルールが存在する場合は、このルールに低い重み (1 など) を設定し、静的リソースのキャッシュルールを上書きしないようにします。

• OK をクリックして設定を完了します。

設定が有効になると、ホームページのコンテンツはノードによってキャッシュされます。その後のアクセスはノードから直接配信されるため、アクセスごとにオリジンフェッチを行う必要がなくなり、ホームページの読み込み速度が大幅に向上します。キャッシュ有効期限の設定に関する詳細については、「CDN キャッシュの有効期限を設定する」をご参照ください。

URL の可変パラメータによるキャッシュヒット率低下の修正方法

この問題は、CDN サービスで [URL パラメータの無視] 機能が有効になっていない場合に発生することがあります。詳細については、URL の可変パラメータによる CDN キャッシュヒット率の低下をご参照ください。

キャッシュヒット率が低下する主な要因

Alibaba Cloud CDN のキャッシュヒット率が低下する主な要因は次のとおりです。

• キャッシュパージ： 手動または自動のキャッシュパージ操作により、キャッシュヒット率が一時的に低下することがあります。

• 帯域幅の急増： 帯域幅が急増すると、リクエストがより多くの CDN ノードに分散されます。これらのノードの多くはコンテンツをキャッシュしていない場合があるため、オリジンフェッチが増加し、キャッシュヒット率が低下します。

• 新しいコンテンツへの初回リクエスト： CDN ノードが新しいコンテンツへの初回リクエストを頻繁に受信する場合、オリジンフェッチの回数が増加し、キャッシュヒット率が低下します。

• キャッシュルールの調整： 不適切なキャッシュの有効期限の設定やキャッシュルールの誤設定など、CDN キャッシュポリシーの変更により、キャッシュヒット率が低下することがあります。

• URL の可変パラメータ： URL に疑問符 (?) の後にパラメータが含まれている場合、これらのパラメータが変化すると、CDN は一意の URL をそれぞれ異なるリソースとして扱うため、同じコンテンツを指すリクエストであってもキャッシュヒット率が低下します。

• 不適切なキャッシュの有効期限の設定： 静的ファイルの更新頻度に基づいて適切なキャッシュの有効期限を設定しない場合、キャッシュされたリソースが早期に期限切れになり、キャッシュヒット率が低下します。

キャッシュヒット率に影響を与える要因の詳細については、CDN キャッシュヒット率の向上をご参照ください。具体的な設定については、リソースのパージとプリフェッチ、URL パラメータの無視、CDN キャッシュの有効期限の設定をご参照ください。

低いキャッシュヒット率、高いオリジンフェッチ率、オリジン帯域幅の逼迫のトラブルシューティング

• オリジンキャッシュのレスポンスヘッダーの確認： オリジンサーバーが Cache-Control: no-cache、Cache-Control: no-store、Cache-Control: max-age=0、または Pragma: no-cache を返す場合、CDN はデフォルトでオリジンのディレクティブに従い、リソースをキャッシュしません。これにより、すべてのリクエストに対してオリジンフェッチが強制され、低いキャッシュヒット率とオリジンサーバー帯域幅の逼迫の最も一般的な原因となります。

• 有効化 [レスポンスヘッダーを無視]: CDN コンソールのキャッシュの有効期限設定で、このオプションを選択します。有効にすると、CDN はオリジンサーバーからの Cache-Control: no-cache、no-store、max-age=0 などの no-cache ディレクティブ、および Pragma: no-cache ヘッダーを無視します。代わりに、コンソールで設定されたルールに基づいてコンテンツをキャッシュします。

• キャッシュルール設定の確認：ルートディレクトリ (/) のキャッシュの有効期限を誤って 0 秒に設定していないか確認します。ルートディレクトリのルールの優先度が最も高く、キャッシュの有効期限が 0 秒の場合、すべてのリクエストでオリジンフェッチがトリガーされます。

• 大容量ファイルの最適化： 動画などの大容量ファイルの場合、Range オリジンフェッチ機能が有効になっていることを確認してください。これにより、CDN がすべてのリクエストに対してオリジンサーバーからファイル全体を取得することを防ぎます。

• 動的リソースと静的リソースの区別： 画像、CSS、JS ファイルなどの静的リソースには、長いキャッシュ期間 (例：1 か月) を設定します。PHP や JSP ページなどの動的コンテンツには、キャッシュの有効期限を 0 秒に設定してキャッシュを無効にします。

動画再生や大容量ファイルのダウンロードログに、多数の 206 ステータスコードや複数のオリジンフェッチが表示される理由

これは正常な動作です。

• ステータスコード 206： 動画プレーヤーやダウンロードツールは通常、Range リクエストを使用してリソースをセグメント単位でロードします。分割された各リクエストに対して、サーバーは 206 Partial Content ステータスコードを返します。CDN もキャッシュからセグメントを提供する際に 206 ステータスコードを返します。

• トラフィック料金： リクエストがキャッシュにヒットしたかどうかにかかわらず、CDN からクライアントに転送されたすべてのデータはアウトバウンドトラフィックとして課金されます。

• 最適化の推奨事項： Range オリジンフェッチ機能が有効になっていることを確認してください。これにより、CDN ノードはオンデマンドでオリジンサーバーからセグメントをプルしてキャッシュできるため、後続のセグメントリクエストのキャッシュヒット率が向上します。また、クライアントまたはオリジンサーバーで適切な Cache-Control ヘッダーを設定して、ブラウザキャッシュを活用し、冗長なリクエストを減らしてください。