このトピックでは、キャッシュに関するよくある質問に対する回答を示します。
キャッシュをクリアするメカニズムは何ですか?
POP上にキャッシュされたリソースがあまり頻繁にアクセスされない場合、リソースは、リソースが期限切れになる前にPOP上で頻繁にアクセスされるリソースによって上書きされ得る。
デフォルトのキャッシュルールとは何ですか?
POPがオリジンサーバーから静的ファイルを取得した後、POPは次のキャッシュルールの優先順位に基づいて静的ファイルを処理します。 より小さい数は、より高い優先度を指定する。 
レスポンスに
pragma:no-cache、cache-control:no-cache、cache-control:no-store、またはcache-control:max-age=0ディレクティブが含まれている場合、静的ファイルはキャッシュされません。Alibaba Cloud CDN は、キャッシュされたリソースのTTL、またはコンソールで設定されたHTTPステータスコードのTTLに従います。
説明リクエストが複数のキャッシュルールに一致する場合、優先順位の順序: 重み> 作成時間に基づいて1つのルールのみが有効になります。
複数のキャッシュルールを作成する場合は、各キャッシュルールに一意の重みを指定して、キャッシュルールの優先順位を定義することを推奨します。 より高い重みは、より高い優先度を指定する。
同じ重みを持つキャッシュルールは、ルールの種類に関係なく、作成時間に基づいて優先順位が付けられます。 作成時間が最も早いルールが優先されます。
Alibaba Cloud CDNは、オリジンサーバーに設定された他のキャッシュルールに従います。 配信元サーバーからの応答のヘッダーは、
キャッシュ制御>期限切れ>Last-Modified>ETagの優先順位の降順です。応答には
Cache-Controlヘッダーが含まれ、ディレクティブはmax-ageまたはs-maxageで、Cache-Control:max-age=3600などの0より大きい値に設定されます。max-ageディレクティブとs-maxageディレクティブの両方が存在する場合、s-maxageディレクティブの値が優先されます。応答は、
Expires: Tue、11月25日2031 17:25:43GMTなどのExpiresヘッダーを搬送する。レスポンスに
ETagまたはLast-modifiedヘッダーが含まれている場合、TTLは次のルールに基づいて計算されます。応答が
Last − Modifiedヘッダを搬送する場合、TTL = (Current time −Last − Modified) × 0.1である。 結果が10秒から3,600秒の場合、結果が適用されます。 結果が10秒未満の場合、TTLは10秒です。 結果が3,600秒を超える場合、TTLは3,600秒です。応答に
ETagヘッダーのみが含まれる場合、TTLは10秒です。
応答に
ETag、Last-Modified、Cache-Control、またはExpiresヘッダーが含まれていない場合、静的ファイルはPOPにキャッシュされません。
リソースがキャッシュされているかどうかを判断するにはどうすればよいですか。
HTTPレスポンスヘッダーをチェックして、Alibaba Cloud CDN がファイルをキャッシュするかどうかを確認できます。
X-Cache: リクエストがキャッシュ にヒットするかどうかを指定します。 X-Cacheヘッダーの値がHITの場合、リクエストはキャッシュにヒットします。 値がMISSの場合、またはヘッダーが存在しない場合、リクエストはキャッシュにヒットしません。Age: ファイルが存在ポイント (POP) にキャッシュされた時間を指定します。 単位は秒です。 HTTPレスポンスには、ファイルがPOPにキャッシュされている場合にのみAgeヘッダーが含まれます。 ファイルが更新またはクリアされた後にファイルがキャッシュされない場合、HTTP応答にはAgeヘッダーは含まれません。Ageヘッダーの値が0の場合、ファイルはPOPにキャッシュされますが、キャッシュの有効期限が切れており、使用できません。 したがって、リクエストはオリジンサーバーにリダイレクトされます。X-Swift-CacheTime: POPにキャッシュされるファイルのTTL値を指定します。ファイルが更新される前の 残りのTTL=X-Swift-CacheTime-Age。X-Swift-SaveTime: ファイルがPOPに最初にキャッシュされた時刻を指定します。 時間はGMTです。 時間をUTC + 8に変換できます。 たとえば、X-Swift-SaveTimeヘッダーの値が2023-04-17 14:30:49の場合、ファイルが最初にキャッシュされた時刻は、UTC + 8では2023-04-17 22:30:49です。
HTTPレスポンスヘッダーを表示し、ファイルがPOPにキャッシュされているかどうかを判断するには、次のいずれかの方法を使用し 。
方法1: Chrome DevToolsなどのブラウザ開発ツールを使用する
方法2: curlコマンドを実行してリソースキャッシュ情報を表示
カール "http://example.com/path/to/response.html" -voa
URLの変数パラメーターによるキャッシュヒット率の低下の問題を解決するにはどうすればよいですか?
Alibaba Cloud CDNのパラメータフィルタリング機能を有効にして、問題を解決します。 詳細については、「URLの変数パラメーターによるキャッシュヒット率の低下」をご参照ください。
リソースをキャッシュするのではなく、オリジンサーバーからリソースを取得するようにPOPを構成するにはどうすればよいですか?
キャッシュしないリソースのディレクトリ、パス、およびファイルタイプに基づいてTTL値を設定します。 次のセクションでは、パラメーターについて説明します。
タイプ: ディレクトリ または ファイル拡張子 を選択します。
アドレス: キャッシュしないリソースのディレクトリまたはファイル名拡張子を入力します。 たとえば、
php、jsp、aspタイプの動的ファイル、またはadminディレクトリ内のすべてのファイルを指定できます。有効期限: このパラメーターを0に設定します。これは、型のリソースまたはディレクトリ内のリソースをキャッシュしないことを指定します。
重み: ビジネス要件に基づいてルールの重みを設定します。 より高い重みは、キャッシュヒットを決定するためのより高い優先度を示す。
詳細については、「リソースのキャッシュルールの作成」をご参照ください。
コンソールでリソースのTTLを0に設定しても、取得したリソースが最新ではないのはなぜですか。
Alibaba Cloud CDN コンソールで特定のリソースのExpire Inパラメーターを0に設定した場合、リソースはPOPにキャッシュされず、リソースのリクエストはオリジンサーバーにリダイレクトされます。 ただし、次の理由により、取得されたリソースが最新ではない場合があります。
ブラウザキャッシュ: ユーザーのブラウザが以前のバージョンのリソースをキャッシュしている可能性があります。 リソースがPOPまたはオリジンサーバーにキャッシュされていない場合でも、ユーザーのブラウザーでキャッシュされたリソースが期限切れになる前に、以前のバージョンのリソースを取得できます。 ブラウザのキャッシュをクリアするか、ブラウザのシークレットモードを使用することを推奨します。
キャッシュルールが有効になるまでの遅延: Expire Inパラメーターを0に設定すると、設定がすべてのPOPに適用されるまでに時間がかかる場合があります。 に加えて、POPがキャッシュルールの変更を検出していない場合、POPは、キャッシュされたリソースの以前のバージョンを依然として返し得る。
オリジンサーバーでキャッシュが更新されない: オリジンサーバーにもキャッシュメカニズムがある場合があります。 オリジンサーバーにキャッシュされているリソースが更新されない場合、POPはオリジンサーバーから古いバージョンのリソースを取得できます。
POPのキャッシュクリアの遅延: キャッシュルールを設定する前にPOPがリソースをキャッシュしている場合、Expire inパラメーターを0に設定しても、すべてのPOPからキャッシュされたリソースをクリアするのに時間がかかる場合があります。 キャッシュを手動で更新して、リソースの最新バージョンがオリジンサーバーから取得されるようにすることができます。 詳細については、「リソースの手動更新」をご参照ください。
POPは、オリジンサーバーでリソースが変更された後、キャッシュされたリソースをリアルタイムで更新しますか?
POPは、オリジンサーバーでリソースが変更された後、キャッシュされたリソースをリアルタイムで更新しません。 ほとんどの場合、POPは、ファイルがPOPにキャッシュされた後、設定されたキャッシュルールに基づいて、キャッシュされたファイルがいつ期限切れになるか、更新されるかを決定します。
POPは、Alibaba Cloud CDN コンソールで設定したExpire Inパラメーターに基づいてリソースを更新します。 オリジンサーバー上のリソースが更新された場合、POPはキャッシュされたリソースの有効期限が切れるまでリソースを更新しません。 この場合、オリジンサーバー上のリソースはPOP上のリソースと一致しません。 詳細については、「リソースのキャッシュルールの作成」をご参照ください。
キャッシュを手動で更新できます。 これにより、POPから特定のファイルまたはディレクトリのキャッシュをすぐに削除できます。 ファイルの次の要求は、最新のコンテンツを取得するためにオリジンサーバーにリダイレクトされます。
Alibaba Cloud CDNコンソールを使用してキャッシュを手動で更新する方法については、「手動でリソースを更新」をご参照ください。
操作を呼び出してキャッシュを更新する方法については、「RefreshObjectCaches」をご参照ください。
キャッシュヒット率を低下させる要因は何ですか?
キャッシュヒット率を低下させる要因について説明します。 詳細については、「Alibaba Cloud CDNのキャッシュヒット率の向上」をご参照ください。
キャッシュリフレッシュ: 手動または自動キャッシュリフレッシュ操作は、短時間でキャッシュヒット率を低下させる可能性があります。
帯域幅使用量のスパイク: 帯域幅使用量のスパイクが発生すると、大量のリクエストがオリジンサーバーにリダイレクトされます。 これにより、キャッシュヒット率が低下する。 詳細については、「リソースの更新とプリフェッチ」をご参照ください。
新しいリソースのリクエスト: 新しいリソースのリクエストが大量にPOPに送信された場合、リクエストはオリジンサーバーにリダイレクトされ、キャッシュヒット率が低下します。
キャッシュルールの変更: キャッシュルールの変更は、キャッシュヒット率に影響を与える可能性があります。 たとえば、TTL値またはキャッシュルールが不適切に設定されています。
URLの変数パラメーター: URLに疑問符 (?) の後に変数パラメーターが含まれているリクエストは、さまざまなリソースのリクエストと見なされます。 これにより、キャッシュヒット率が低下する。 詳細については、「パラメーターの無視」をご参照ください。
適切なTTL値がない: 異なる頻度で更新される静的ファイルに適切なTTL値を設定しないと、キャッシュされたリソースの期限が切れることがあります。 これにより、キャッシュヒット率が低下する。 詳細については、「リソースのキャッシュルールの作成」をご参照ください。
キャッシュヒット率の低下の問題をトラブルシューティングするにはどうすればよいですか?
キャッシュヒット率が低いと、コンテンツの読み込みが遅くなり、オリジンサーバーの負荷が増加する可能性があります。 低キャッシュヒット率の問題のトラブルシューティング方法については、「低キャッシュヒット率のトラブルシューティング」をご参照ください。
すべてのディレクトリにキャッシュ設定を適用する方法?
すべてのディレクトリのリソースにTTL値を指定できます。 キャッシュルールを作成するときは、タイプ パラメーターを ディレクトリ に設定し、Objectパラメーターをスラッシュ (/) に設定してすべてのディレクトリを指定します。 詳細については、「リソースのキャッシュルールの作成」をご参照ください。
キャッシュルールが有効にならないのはなぜですか?
設定したキャッシュルールは、次の理由により有効にならない場合があります。
ルールが有効になるまでの遅延: キャッシュルールを作成または変更した後、ルールが有効になるまでに時間がかかります。 新しいルールが有効になった後に確認することを推奨します。
キャッシュ更新メカニズム: POPに既にキャッシュされているリソースのキャッシュルールを変更した後、ルールはすぐには有効になりません。 キャッシュされたリソースの有効期限が切れると、リソースの最新バージョンが配信元サーバーから取得され、ルールに基づいてPOPにキャッシュされます。
キャッシュの更新なし: キャッシュ設定を変更した後に手動でキャッシュを更新しない場合、キャッシュされたリソースは、キャッシュされたリソースが期限切れになるまでユーザーに返され続けます。 キャッシュルールをすぐに有効にする場合は、キャッシュルールを変更した後にキャッシュを更新します。 詳細については、「リソースの更新とプリフェッチ」をご参照ください。
不適切なキャッシュ関連のレスポンスヘッダー: オリジンサーバーの
[cache-Control]および[Expires]レスポンスヘッダーが適切に設定されているかどうかを確認します。 たとえば、Cache-Controlヘッダーの値がno-cacheまたはno-storeの場合、POPおよびブラウザーはリソースをキャッシュしません。キャッシュルールの優先度: リクエストが複数のルールに一致する場合、1つのルールのみが有効になります。 優先度: 重み> ルール作成時間。
複数のキャッシュルールを作成する場合は、各キャッシュルールに一意の重みを指定して、キャッシュルールの優先順位を定義することを推奨します。 より高い重みは、より高い優先度を指定する。
同じ重みを持つキャッシュルールは、ルールの種類に関係なく、作成時間に基づいて優先順位が付けられます。 作成時間が最も早いルールが優先されます。
設定例: 次のキャッシュルールは、高速化ドメイン名
demo.aliyun.comに設定されています。 POPは、オリジンサーバーからリソースhttp://demo.aliyun.com/image/example.pngを取得します。 次のルールが一致し、2つのルールの重みは同じです。 したがって、システムは、ルール作成時間に基づいて有効にするルールを選択します。 以前に作成されたルールの優先度は高くなります。 この例では、/imageディレクトリのルールは以前に作成されています。 したがって、このルールが有効になります。
HTTPレスポンスヘッダーを使用してCORSを設定するにはどうすればよいですか?
HTTPレスポンスヘッダーを設定して、異なるソースからのリクエストがリソースにアクセスできるようにすることができます。 詳細については、「CORS の設定」をご参照ください。
レスポンスヘッダーを設定しても、CORSの問題が報告され、Access-Control-Allow-Originレスポンスヘッダーが返されないのはなぜですか。
Alibaba Cloud CDNでAccess-Control-Allow-Originなどのレスポンスヘッダーを設定しましたが、クライアントがリソースにアクセスしているときにCORSの問題が発生し、設定したレスポンスヘッダーがレスポンスで返されません。 次のセクションでは、考えられる原因について説明します。
考えられる原因
設定が正しくない: 設定が正しくないか、有効になりません。
POPキャッシュ: 古いレスポンスヘッダーをPOPにキャッシュすることができます。 この場合、設定を変更しても古いヘッダーが返されます。
オリジンサーバーの問題: POPにCORSレスポンスヘッダーを設定すると、オリジンサーバーからのレスポンスにもCORSレスポンスヘッダーが含まれ、レスポンスヘッダーの設定が競合すると、問題が発生する可能性があります。 この場合、POPとオリジンサーバーのCORSレスポンスヘッダーに同じ構成を使用する必要があります。
ブラウザキャッシュ: 古いレスポンスヘッダーがブラウザにキャッシュされている可能性があります。 この場合、ブラウザは、更新されたレスポンスヘッダーを取得するための新しいリクエストを開始しません。
解決策
設定の確認: Alibaba Cloud CDNの設定、特にCORSレスポンスヘッダーの設定が有効で有効であることを確認します。
Alibaba Cloud CDNキャッシュの消去: Alibaba Cloud CDNの更新機能を使用して、キャッシュされたコンテンツを消去し、リソースに再アクセスできます。 詳細については、「リソースの更新とプリフェッチ」をご参照ください。
オリジンサーバーの構成を確認する: オリジンサーバーが、POPによって返されるレスポンスヘッダーと競合するCORSレスポンスヘッダーを返さないことを確認してください。 オリジンサーバーから返されるレスポンスヘッダーは、POPから返されるレスポンスヘッダーと同じになるように設定することをお勧めします。
ブラウザーキャッシュの消去: ブラウザーキャッシュを消去するか、シークレットブラウジングモードを使用して、ブラウザーが更新されたレスポンスヘッダーを取得するようにします。
テクニカルサポートに連絡: 問題が解決しない場合は、Alibaba Cloud CDNテクニカルサポートに連絡するか、チケットを起票してください。
POPとオリジンサーバーのHTTPレスポンスヘッダーの違いは何ですか?
POPおよびオリジンサーバーからのHTTP応答ヘッダーは、キャッシングシステムのさまざまなコンポーネントによって返されます。
POPからのHTTP応答ヘッダは、POPによってブラウザなどのクライアントに送信される。 POPがクライアント要求を受信すると、コンテンツがPOPにキャッシュされている場合、POPは要求されたコンテンツを対応するHTTP応答ヘッダと共にクライアントに返す。 POPは、オリジンサーバへの要求を開始する必要はない。
オリジンサーバーからのHTTPレスポンスヘッダーは、オリジンサーバーによってPOPに送信されます。 要求がPOPのキャッシュにヒットしないか、キャッシュが期限切れになった場合、POPはオリジンサーバーから最新のコンテンツを取得する要求を開始します。 配信元サーバーは、要求されたコンテンツを対応するHTTP応答ヘッダーとともに返します。 POPは、後で使用するためにHTTP応答ヘッダーを受信、処理、および保存します。
したがって、POPおよびオリジンサーバーからのHTTP応答ヘッダーは、さまざまなシナリオで使用され、さまざまなコンポーネントによって送信されます。 POPからのHTTP応答ヘッダーは、クライアントとPOPのキャッシュを制御するために使用されます。 オリジンサーバーからのHTTP応答ヘッダーは、オリジンサーバーとPOPのキャッシュを制御するために使用されます。 実際のシナリオでは、POPからのHTTP応答ヘッダーは、効率的で正確なキャッシュのために、オリジンサーバーからのHTTP応答ヘッダーと一緒に使用されます。 詳細については、「HTTPレスポンスヘッダーの設定」をご参照ください。
HTTPステータスコードのキャッシュルールは何ですか?
次の図は、HTTPステータスコード204、305、400、403、404、405、414、500、501、502、503、および504のキャッシュルールを示しています。
[range origin fetch] に記載されているレンジオリジンフェッチ機能を有効にすると、次のキャッシュルールが適用されます。
204、305、400、403、404、405、414、500、200、206、503、504など、501および502以外のHTTPステータスコードの場合、リソースはキャッシュされません。
HTTPステータスコード200および206の場合、リソースは、既定のキャッシュルールおよびキャッシュルールの優先順位に記載されているキャッシュルールに基づいてキャッシュされます。
HTTP 5xxステータスコードにより、POPはキャッシュされたファイルチャンクを削除できます。 オリジンフェッチがタイムアウトした場合、ファイルチャンクは削除されません。
説明範囲オリジンフェッチ機能を有効にすると、オリジンサーバーは大きなファイルをチャンクに分割してから、ファイルがPOPに返されます。 たとえば、ファイルは10個のチャンクに分割され、そのうち5個がPOPにキャッシュされます。 ユーザーが6番目のチャンクを要求すると、オリジンサーバーはHTTP 5xxステータスコードを返し、POPはキャッシュされている5つのチャンクを削除します。
range origin fetch機能を無効にすると、次のキャッシュルールが適用されます。
オリジンサーバーが
Set-Cookieレスポンスヘッダーを返した場合、POPは取得したリソースをキャッシュしません。オリジンサーバーが
Set-Cookieレスポンスヘッダーを返さない場合、取得されたリソースはAlibaba Cloud CDNコンソールで設定されたキャッシュルールに基づいてキャッシュされます。 詳細については、「キャッシュルールの適用方法」をご参照ください。オリジンサーバーが
Set-Cookieレスポンスヘッダーを返さず、Alibaba Cloud CDNコンソールでキャッシュルールが設定されていない場合、取得したリソースはPragma、cache-Control、またはExpiresレスポンスヘッダーのディレクティブに基づいて処理されます。オリジンサーバーが
Set-Cookie、Pragma、Cache-Control、またはExpiresレスポンスヘッダーを返さず、Alibaba Cloud CDNコンソールでキャッシュルールが設定されていない場合、取得したリソースは1秒間キャッシュされます。
HTTP 303、304、401、407、600、601のステータスコードでは、リソースはキャッシュされません。