このトピックでは、キャッシュについてよくある質問への回答を提供します。
キャッシュをクリアするメカニズムとは何ですか？
CDN POP にキャッシュされているリソースにアクセスされる頻度が低い（同じ CDN POP 上の同じリソースにアクセスされる頻度が低い）場合、リソースの有効期限が切れる前に、CDN POP 上の他の頻繁にアクセスされるリソースによって上書きされる可能性があります。
デフォルトのキャッシュルールとは何ですか？
CDN POP がオリジンサーバーからファイルを受信した後、POP は次のキャッシュルールに基づいてファイルを処理します。数値が小さいほど、優先順位が高くなります。
オリジンサーバーが
pragma:no-cache、cache-control:no-cache、no-store、またはmax-age=0ヘッダーで応答した場合、CDN はリソースをキャッシュしません。CDN コンソールで構成したキャッシュルール（キャッシュ TTL やステータスコードの有効期限など）。
説明CDN へのリクエストが複数のルールに一致する場合、1 つのルールのみが有効になります。優先順位は、まず重みによって決定され、次にルールが作成された時刻によって決定されます。
複数のキャッシュルールを作成する場合、ルールごとに異なる重みを設定して、実行の優先順位を制御できます。重みが大きいほど、優先順位が高くなります。
複数のキャッシュルールの重みが同じ場合、ルールタイプに関係なく、最初に作成されたルールが最も優先されます。
オリジンサーバーからのレスポンスのキャッシュ関連ヘッダー。ヘッダーの優先順位は降順にソートされます。
cache-control>expires>last-modified>ETag。オリジンサーバーのレスポンスは、
cache-controlヘッダーを使用して有効期限を設定します。ヘッダーにはmax-ageまたはs-maxageディレクティブが含まれている必要があり、max-ageまたはs-maxageの値は 0 より大きい必要があります。例：cache-control: max-age=3600。max-ageとs-maxageの両方が存在する場合、s-maxageの値が優先されます。オリジンサーバーからの
expiresレスポンスヘッダーは、有効期限を指定します。例：`expires:Tue, 25 Nov 2031 17:25:43 GMT`。オリジンサーバーからのレスポンスに
ETagまたはlast-modifiedヘッダーが含まれている場合、キャッシュ期間は次のルールに基づいて計算されます。last-modifiedヘッダーが存在する場合、キャッシュ期間は次の式を使用して計算されます。（現在時刻 -last-modified）× 0.1。結果が 10 秒から 3,600 秒の間にある場合、結果がキャッシュ期間として使用されます。結果が 10 秒未満の場合、キャッシュ期間は 10 秒に設定されます。結果が 3,600 秒を超える場合、キャッシュ期間は 3,600 秒に設定されます。ETagヘッダーのみが存在する場合、キャッシュ期間は 10 秒です。
オリジンサーバーからのレスポンスに次のキャッシュ関連ヘッダーのいずれも含まれていない場合、リソースはデフォルトではキャッシュされません。
ETag、last-modified、cache-control、またはexpires。
リソースがキャッシュされているかどうかを確認するにはどうすればよいですか？
HTTP レスポンスヘッダーを確認して、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 です。
HTTP レスポンスヘッダーを表示して、ファイルが POP にキャッシュされているかどうかを確認するには、次のいずれかの方法を使用します。
方法 1：Chrome DevTools などのブラウザ開発ツールを使用する
方法 2：curl コマンドを実行してリソースキャッシュ情報を表示する
curl "http://example.com/path/to/response.html" -v
URL の可変パラメータが原因でキャッシュヒット率が低い問題を解決するにはどうすればよいですか？
この問題を解決するには、CDN のパラメータフィルタリング機能を有効にします。詳細については、「URL の可変パラメータが原因でキャッシュヒット率が低い」をご参照ください。
POP がリソースをキャッシュせずにオリジンサーバーからリソースを取得するように構成するにはどうすればよいですか？
キャッシュしたくないリソースのディレクトリ、パス、およびファイルタイプに基づいて TTL 値を構成します。次のセクションでは、パラメータについて説明します。
タイプ: ディレクトリまたは ファイル拡張子を選択します。
アドレス: キャッシュしたくないリソースのディレクトリまたはファイル名拡張子を入力します。たとえば、
php、jsp、aspタイプの動的ファイル、またはadminディレクトリ内のすべてのファイルを指定できます。有効期限: このパラメータを 0 に設定します。これは、指定されたタイプまたはディレクトリのリソースがキャッシュされないことを指定します。
重み：ビジネス要件に基づいてルールの重みを構成します。重みが大きいほど、キャッシュヒットの決定における優先順位が高くなります。
詳細については、「キャッシュ TTL を構成する」をご参照ください。
コンソールでリソースの TTL を 0 に設定しても、取得したリソースが最新ではないのはなぜですか？
CDN コンソールで特定のリソースの有効期限パラメータを 0 に設定すると、リソースは POP にキャッシュされず、リソースへのリクエストはオリジンサーバーにリダイレクトされます。ただし、次の理由により、取得したリソースが最新でない場合があります。
ブラウザキャッシュ: ユーザーのブラウザが以前のバージョンのリソースをキャッシュしている可能性があります。ブラウザキャッシュをクリアするか、ブラウザのシークレットモードを使用することをお勧めします。
キャッシュルールが有効になるまでの遅延: 有効期限パラメータを 0 に設定した後、設定がすべての POP に適用されるまでに時間がかかる場合があります。さらに、POP がキャッシュルールの変更を検出していない場合、POP はキャッシュされたリソースの以前のバージョンを返す可能性があります。
オリジンサーバーでキャッシュが更新されない: オリジンサーバーにもキャッシュメカニズムがある場合があります。オリジンサーバーにキャッシュされているリソースが更新されない場合、POP はオリジンサーバーから古いバージョンのリソースを取得する可能性があります。
POP でのキャッシュクリアの遅延: キャッシュルールを構成する前に POP がリソースをキャッシュしていた場合、有効期限パラメータを 0 に設定しても、すべての POP からキャッシュされたリソースをクリアするまでに時間がかかる場合があります。キャッシュを手動で更新して、最新バージョンのリソースがオリジンサーバーから取得されるようにすることができます。詳細については、「リソースを手動で更新する」をご参照ください。
オリジンサーバーでリソースが変更された後、POP はキャッシュされたリソースをリアルタイムで更新しますか？
POP は、オリジンサーバー上のリソースが変更されても、キャッシュされたリソースをリアルタイムでは更新しません。ほとんどの場合、POP は、ファイルが POP にキャッシュされた後、設定されたキャッシュルールに基づいて、キャッシュされたファイルがいつ有効期限切れになるか、またはいつリフレッシュされるかを決定します。
POP は、コンソールで設定した有効期限パラメーターに基づいてリソースを更新します。 オリジンサーバー上のリソースが更新された場合、キャッシュされたリソースの有効期限が切れるまで、POP はリソースを更新しません。 詳細については、「キャッシュ TTL を設定する」をご参照ください。
キャッシュを手動でリフレッシュできます。 ファイルへの次のリクエストは、最新のコンテンツを取得するためにオリジンサーバーにリダイレクトされます。
CDN コンソールを使用してキャッシュを手動でリフレッシュする方法については、「リソースを手動でリフレッシュする」をご参照ください。
操作を呼び出すことによってキャッシュをリフレッシュする方法については、「RefreshObjectCaches」をご参照ください。
キャッシュヒット率を低下させる要因は何ですか?
次のセクションでは、キャッシュヒット率を低下させる要因について説明します。詳細については、「CDN のキャッシュヒット率を向上させる」をご参照ください。
キャッシュ更新: 手動または自動のキャッシュ更新操作により、短期間でキャッシュヒット率が低下する可能性があります。
帯域幅使用量の急増: 帯域幅使用量が急増すると、多数のリクエストがオリジンサーバーにリダイレクトされます。これにより、キャッシュヒット率が低下します。詳細については、「リソースのリフレッシュとプリフェッチ」をご参照ください。
新しいリソースのリクエスト: 新しいリソースに対する多数のリクエストが POP に送信されると、リクエストはオリジンサーバーにリダイレクトされ、キャッシュヒット率が低下します。
キャッシュルールの変更: キャッシュルールの変更は、キャッシュヒット率に影響を与える可能性があります。たとえば、TTL 値またはキャッシュルールが不適切に構成されている場合があります。
URL 内の可変パラメーター: URL に疑問符 (?) の後に可変パラメーターが含まれているリクエストは、異なるリソースへのリクエストと見なされます。これにより、キャッシュヒット率が低下します。詳細については、「パラメーターを無視する」をご参照ください。
適切な TTL 値がない: 更新頻度の異なる静的ファイルに適切な TTL 値を構成しないと、キャッシュされたリソースの有効期限が早く切れる可能性があります。これにより、キャッシュヒット率が低下します。詳細については、「キャッシュ TTL を構成する」をご参照ください。
キャッシュヒット率が低い問題をトラブルシューティングするにはどうすればよいですか？
キャッシュヒット率が低いと、コンテンツの読み込みが遅くなり、オリジンサーバーの負荷が増加する可能性があります。 キャッシュヒット率が低い問題のトラブルシューティング方法については、「キャッシュヒット率が低い問題のトラブルシューティング」をご参照ください。
すべてのディレクトリにキャッシュ設定を適用するにはどうすればよいですか？
すべてのディレクトリのリソースに TTL 値を指定できます。 キャッシュルールを作成する際に、タイプ パラメーターを ディレクトリ に設定し、オブジェクトパラメーターをスラッシュ (/) に設定することで、すべてのディレクトリを指定できます。 詳細については、「キャッシュ TTL を設定する」をご参照ください。
キャッシュルールが有効にならないのはなぜですか？
設定したキャッシュルールが有効にならない理由は次のとおりです。
ルールが有効になるまでの遅延: キャッシュルールを作成または変更した後、ルールが有効になるまでには時間がかかります。新しいルールが有効になった後に確認することをお勧めします。
キャッシュの更新メカニズム: POP にすでにキャッシュされているリソースのキャッシュルールを変更した後、キャッシュされたリソースの有効期限が切れるまで、ルールはすぐに有効になりません。
キャッシュがリフレッシュされない: キャッシュ設定を変更した後に手動でキャッシュをリフレッシュしないと、キャッシュされたリソースの有効期限が切れるまで、キャッシュされたリソースがユーザーに返され続けます。 詳細については、「リソースのリフレッシュとプリフェッチ」をご参照ください。
不適切なキャッシュ関連レスポンスヘッダー: オリジンサーバーからの
Cache-ControlおよびExpiresレスポンスヘッダーが正しく設定されているかどうかを確認します。キャッシュルールの優先順位: リクエストが複数のキャッシュルールに一致する場合、1 つのルールのみが有効になります。優先順位: 重み > ルール作成時間。
複数のキャッシュルールを作成する場合、ルールごとに異なる重みを設定して、実行の優先順位を制御できます。重みが大きいほど、優先順位が高くなります。
複数のキャッシュルールが同じ重みを持つ場合、ルールタイプに関係なく、最初に作成されたルールが最も優先されます。
設定例: 高速化ドメイン名
demo.aliyun.comに対して、次のキャッシュルールが設定されています。POP は、オリジンサーバーからリソースhttp://demo.aliyun.com/image/example.pngを取得します。次のルールが一致し、2 つのルールの重みは同じです。したがって、システムはルール作成時間に基づいて有効にするルールを選択します。先に作成されたルールの方が優先順位が高くなります。この例では、/image ディレクトリのルールが先に作成されています。したがって、このルールが有効になります。
HTTP 応答ヘッダーを使用して CORS を設定するにはどうすればよいですか?
HTTP 応答ヘッダーを設定して、異なるソースからのリクエストがリソースにアクセスできるようにすることができます。詳細については、「CORS を設定する」をご参照ください。
CORS の問題が報告され、応答ヘッダー Access-Control-Allow-Origin が設定されているにもかかわらず返されないのはなぜですか？
次のセクションでは、考えられる原因について説明します。
考えられる原因
構成の誤り: 構成が正しくないか、有効になっていません。
POP キャッシュ: 古い応答ヘッダーが POP にキャッシュされている可能性があります。
オリジンサーバーの問題: POP で CORS 応答ヘッダーを構成し、オリジンサーバーからの応答にも CORS 応答ヘッダーが含まれており、応答ヘッダーの構成が競合している場合、問題が発生する可能性があります。
ブラウザのキャッシュ: 古い応答ヘッダーがブラウザにキャッシュされている可能性があります。
解決策
構成の確認: CDN の構成、特に CORS 応答ヘッダーの構成が有効で、有効になっていることを確認します。
CDN キャッシュのクリア: CDN のリフレッシュ機能を使用して、キャッシュされたコンテンツをクリアしてから、リソースに再度アクセスできます。詳細については、「リソースのリフレッシュとプリフェッチ」をご参照ください。
オリジンサーバーの構成の確認: オリジンサーバーが、POP から返される応答ヘッダーと競合する CORS 応答ヘッダーを返さないことを確認します。オリジンサーバーから返される応答ヘッダーを POP から返される応答ヘッダーと同じに設定することをお勧めします。
ブラウザのキャッシュをクリアする: ブラウザのキャッシュをクリアするか、シークレットブラウジングモードを使用します。
テクニカルサポートへの連絡: 問題が解決しない場合は、CDN テクニカルサポートに連絡するか、チケットを送信してください。
HTTP ステータスコードのキャッシュルールとは何ですか？
次の図は、HTTP ステータスコード 204、305、400、403、404、405、414、500、501、502、503、および 504 のキャッシュルールを示しています。
レンジオリジンフェッチ 機能によってリクエストが処理される場合、次のキャッシュルールが適用されます。
200 および 206 以外の HTTP ステータスコード (204、305、400、403、404、405、414、500、501、502、503、504 など) の場合、リソースはキャッシュされません。
HTTP ステータスコード 200 および 206 の場合、リソースは Alibaba Cloud CDN/DCDN デフォルトのキャッシュルールと優先順位 に記載されているキャッシュルールに基づいてキャッシュされます。
HTTP 5xx ステータスコードを使用すると、POP はキャッシュされたファイルチャンクを削除できます。オリジンフェッチがタイムアウトした場合、ファイルチャンクは削除されません。
説明レンジオリジンフェッチ機能を有効にすると、オリジンサーバーは、ファイルが POP に返される前に、大きなファイルをチャンクに分割します。たとえば、ファイルが 10 個のチャンクに分割され、そのうち 5 個が POP にキャッシュされます。ユーザーが 6 番目のチャンクをリクエストすると、オリジンサーバーは HTTP 5xx ステータスコードを返し、POP はキャッシュされている 5 つのチャンクを削除します。
レンジオリジンフェッチ によってリクエストが処理されない場合、次のキャッシュルールが適用されます。
オリジンサーバーが
set-cookieレスポンスヘッダーを返した場合、POP は取得したリソースをキャッシュしません。オリジンサーバーが
Set-Cookieレスポンスヘッダーを返さない場合、取得したリソースは、Alibaba Cloud CDN コンソールで設定されているキャッシュルールに基づいてキャッシュされます。詳細については、「キャッシュルールの適用方法」をご参照ください。オリジンサーバーが
Set-Cookieレスポンスヘッダーを返さず、CDN コンソールでキャッシュルールが設定されていない場合、取得したリソースは、Pragma、Cache-Control、またはExpiresレスポンスヘッダーのディレクティブに基づいて処理されます。オリジンサーバーが
Set-Cookie、Pragma、Cache-Control、またはExpiresレスポンスヘッダーを返さず、CDN コンソールでキャッシュルールが設定されていない場合、取得したリソースは 1 秒間キャッシュされます。
HTTP 303、304、401、407、600、および 601 ステータスコードの場合、リソースはキャッシュされません。
送信応答ヘッダーと受信応答ヘッダーの違いは何ですか?
送信応答ヘッダーと受信応答ヘッダーは、キャッシュアーキテクチャの異なる段階における HTTP ヘッダー情報を表します。
送信応答ヘッダー: POP からクライアント ( ブラウザなど ) に送信されます。キャッシュヒットの場合、POP はこれらのヘッダーを持つオブジェクトを提供します。これらは、クライアント側のキャッシュと動作を制御します。
受信応答ヘッダー: オリジンから POP に送信されます。キャッシュミスまたはキャッシュの期限切れの場合、POP はオリジンからオブジェクトをフェッチし、これらのヘッダーを受信します。POP はこれらを使用して、オブジェクトをキャッシュする方法と送信ヘッダーを設定する方法を決定します。
つまり、受信ヘッダーは POP キャッシュを管理します。送信ヘッダーはクライアントキャッシュを管理します。これらは連携して、正確で効率的なキャッシュを実現します。詳細については、「受信応答ヘッダーを設定する」をご参照ください。
ドメイン名のキャッシュをスキップする方法
すべてのパスに対するキャッシュの有効期限を 0 に設定します。次の手順に従います。
Alibaba Cloud CDN コンソールにログインします。
左側のナビゲーションウィンドウで、ドメイン名 をクリックします。
ドメイン名 ページで、管理するドメイン名を見つけ、管理 列の 操作 をクリックします。
ドメイン名の左側のナビゲーションツリーで、キャッシュ設定 をクリックします。
キャッシュ有効期限 タブで、追加 をクリックします。
タイプ を ディレクトリ に設定します。
アドレス を
/に設定します。これはすべてのパスを表します。有効期限 を
0 secondsに設定します。その他のパラメーターについては、デフォルト設定を維持します。
OK をクリックします。
CDN へのリクエストが複数のキャッシュルールにヒットした場合、1 つのルールのみが有効になります。ルールの優先順位は、まず重み、次に作成時間で決まります。
キャッシュ有効期限 タブに複数のルールがある場合は、ドメイン名のキャッシュをスキップするルールに最も高い 重み を設定します。これにより、ルールに最高の優先順位が与えられます。
