CDN:キャッシュのトラブルシューティング

トラブルシューティングの手順：

1. 設定が有効になったことの確認：キャッシュルールを追加または変更した後、ルールのステータスは [設定中] と表示されます。これは、設定が世界中の POP (Point of Presence) に配信中であることを示します。通常、ステータスは数分以内に [成功] に変わります。設定が有効になる前に、急いでルールを検証しないでください。

2. 新しいルールが対象リソースに適用されることの確認：新しいルールは、新しいリクエストにのみ適用されます。POP に既にキャッシュされているリソースは、有効期限が切れるまで引き続き以前のポリシーで配信されます。ルールをすぐに適用するには、まず 更新とプリフェッチ を使用して以前のキャッシュをクリアしてください。

3. ルールの一致優先度の確認：リクエストが複数のルールに一致する場合、1つのルールのみが有効になります。デフォルトでは、重みがより高いルールが優先されます。重みが等しい場合、通常は後から作成されたルールが優先されます (コンソールの実際の説明をご参照ください) 。対象パスに一致するルールに最も高い重みが設定されるようにしてください。たとえば、特定のディレクトリ (/static/) の重みは、ルートディレクトリ (/) よりも高くする必要があります。

4. オリジンレスポンスヘッダーがキャッシュを禁止していないかの確認：オリジンサーバーが Cache-Control: no-cache、no-store、max-age=0、または Pragma: no-cache を返す場合、CDN はデフォルトでオリジンの指示に従います。異なるディレクティブがオリジンフェッチの動作に与える影響については、次の表をご参照ください。キャッシュルールで [オリジンサーバーからの no-cache ヘッダーを無視する] を有効にしてコンソールのルールに基づいてキャッシュを強制するか、オリジンサーバーの設定を調整して静的リソースの no-cache ディレクティブを削除することができます。

5. URL パラメーターの処理方法の確認：URL にパラメーターが含まれ、[パラメーターを無視] が無効になっている場合、異なるパラメーターを持つ URL は異なるリソースとして扱われ、キャッシュヒット率が低下します。[パラメーターを無視] または [指定したパラメーターを保持] を有効にすることができます。

6. ルートディレクトリがキャッシュしないように誤って設定されていないかの確認：ルートディレクトリ / のルールが最も高い重みを持ち、有効期限が 0 秒の場合、すべてのリクエストがオリジンフェッチをトリガーします。

上記の手順 4 では、オリジンサーバーからの no-cache ディレクティブは、オリジンフェッチの動作に与える影響がそれぞれ大きく異なります。実際のディレクティブに基づいてオリジンサーバーの負荷を評価してください：

オリジンレスポンスヘッダー	CDN の動作	オリジンサーバーへの影響
Cache-Control: no-store	キャッシュは完全に禁止されます。すべてのリクエストはオリジンサーバーから完全なリソースをフェッチします。	オリジンサーバーがすべてのトラフィック負荷を負担します。
Cache-Control: no-cache または max-age=0	POP はキャッシュコピーを保存できますが、使用するたびにオリジンサーバーで再検証する必要があります。検証が成功すると、オリジンサーバーは 304 (レスポンスボディなし) を返し、オーバーヘッドは完全なオリジンフェッチよりもはるかに少なくなります。	オリジンフェッチの回数は減りませんが、各フェッチは小規模な条件付きリクエストであるため、帯域幅の負荷は管理可能です。
Pragma: no-cache	HTTP/1.0 との互換性のためのディレクティブです。効果は no-cache と同様です。	上記と同様です。

有効期限を 0 に設定する目的は、すべてのリクエストがオリジンサーバーから最新のコンテンツをフェッチするようにするためです。古いコンテンツが引き続き返される場合は、次の手順でトラブルシューティングを行ってください：

1. ローカルブラウザキャッシュの影響を除外：ブラウザのキャッシュをクリアするか、プライベートブラウジングモードを使用して再度テストし、ブラウザではなく POP が古いコンテンツを返していることを確認してください。

2. 設定変更前のキャッシュをクリア：設定を変更する前にキャッシュされたリソースは自動的にクリアされません。更新とプリフェッチ を使用して URL 更新タスクを送信してください。

3. オリジンサーバー独自のキャッシュの有無の確認：オリジンサーバー (たとえば、Nginx キャッシュやアプリケーション層のキャッシュ) が古いコンテンツを返す可能性があり、その場合 CDN はオリジンフェッチ中に古いデータをフェッチします。

4. 設定がグローバルに有効になったことの確認：ルールステータスは [成功] である必要があります。設定がすべての POP に配信されるまでには数分かかります。

5. リクエストが意図した POP にヒットしていることの確認：ユーザーの ISP や地域によって、リクエストは異なる POP にヒットする可能性があります。複数の地域で個別にテストするか、CDN のリアルタイムログとレスポンス内の POP の IP を使用して、問題をさらに特定してください。

1. 設定が完全であることの確認：通常、カスタムキャッシュキーでは、リクエストの特性 (たとえば User-Agent) に基づいてルール条件を設定し、各ルールに異なるキャッシュキー変数を追加する必要があります。モバイルクライアントと PC クライアントのリクエスト特性が正しく識別され、2つのルールの一致条件が互いに重複していないことを確認してください。

2. 設定が有効になるまでの待機：設定を送信した後、グローバルに同期されるまで 5～10 分待ってください。

3. 以前のキャッシュの更新：設定変更前に以前のキャッシュキーでキャッシュされたリソースは自動的に期限切れになりません。更新タスクを送信してください (ディレクトリ更新の使用を推奨します) 。

4. クライアントでの検証：ブラウザのキャッシュをクリアして再試行し、レスポンスヘッダーの X-Cache が MISS であることを確認してください。

5. 実機でのテスト：ブラウザのウィンドウサイズを変更するだけでなく、さまざまなデバイスの実際の User-Agent を使用してリクエストを送信してください (ブラウザがエミュレートする User-Agent は、実機のものとは異なる場合があります) 。

原因：オリジンのレスポンスに Set-Cookie ヘッダーが含まれている場合、CDN はデフォルトでレスポンスをキャッシュしないため、キャッシュヒット率が 0 になります。

推奨される解決策 (優先度順)：

• オリジン側での修正 (推奨)：オリジンサーバーが、画像、CSS、JavaScript、フォントなどの静的リソースに対して Set-Cookie を返さないように修正します。これが根本的な解決策です。動的エンドポイントのセッション管理に影響を与えることなく、キャッシュヒット率を向上させることができます。

• CDN 側でのパスによる削除：オリジンサーバーを調整できない場合は、動的エンドポイントに影響を与えないように、/static/、*.css、*.js などの静的リソースパスに対してのみ、CDN 側でこのレスポンスヘッダーを削除します。

CDN 側でパスによってヘッダーを削除する手順：

1. CDN コンソールにログインします。[ドメイン名] ページで、対象のドメイン名を見つけて [管理] をクリックします。

2. ドメイン詳細ページのナビゲーションペインで、[オリジン設定] をクリックし、[受信レスポンスヘッダーの変更] タブに移動します。

3. [追加] をクリックし、ルール条件を静的リソースパスに制限し、レスポンスヘッダーの操作として [削除] を選択し、レスポンスヘッダー名に Set-Cookie を入力します。

4. 設定が完了したら、更新とプリフェッチ を使用して以前にキャッシュされたレスポンスをクリアし、新しいルールを有効化します。

設定後もキャッシュヒット率が改善しない場合は、キャッシュルールで [オリジンサーバーからの no-cache ヘッダーを無視する] が有効になっているか、また、異なるクエリパラメーターによって同じリソースが複数のキャッシュオブジェクトに分割されるのを防ぐために [パラメーターを無視] が有効になっているかを確認してください。CDN のデフォルトのキャッシュルールについては、「CDN キャッシュの有効期限の設定」をご参照ください。

低いキャッシュヒット率は、ほとんどのリクエストでオリジンフェッチがトリガーされることを意味します。不安定なパブリックネットワークパスは、高速化効果を低下させ、オリジンサーバーに負荷をかける可能性があります。以下の手順でトラブルシューティングを行ってください。

1. オリジンサーバーが no-cache ディレクティブを返すかどうかの確認：これは、低いヒット率とオリジン帯域幅の飽和の最も一般的な原因です。オリジンサーバーが Cache-Control: no-cache、no-store、max-age=0、または Pragma: no-cache を返す場合、CDN はオリジンのディレクティブに従い、リソースをキャッシュしません。そのため、すべてのリクエストでオリジンフェッチがトリガーされます。キャッシュの有効期限設定で [オリジンサーバーの no-cache ヘッダーを無視] を有効にして、コンソールのルールに基づいてキャッシュを強制するか、オリジンサーバーの設定を調整できます。

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

3. URL に可変パラメータが含まれていないかの確認：URL 内の疑問符の後のパラメータを変更すると、同じコンテンツが異なるリソースとして扱われます。 [パラメータを無視] を有効にすると、そのようなリクエストが単一のキャッシュオブジェクトに統合されます。詳細については、「パラメータを無視」をご参照ください。

4. 静的リソースと動的リソースを個別に設定：画像、CSS、JavaScript、フォントなどの静的リソースには長いキャッシュ期間 (30 日など) を設定し、PHP、JSP、API エンドポイントなどの動的コンテンツには有効期限を 0 秒に設定してください。

5. 大容量ファイルに対して Range オリジンフェッチを有効化：動画やインストールパッケージなどの大容量ファイルについては、POP がリクエストごとにオリジンサーバーからファイル全体をフェッチしないように、Range オリジンフェッチが有効になっていることを確認してください。この機能を有効にする前に、オリジンサーバーが Range リクエストをサポートしていること (つまり、206 Partial Content を返すことができること) を確認してください。オリジンサーバーが Range リクエストをサポートしていない場合にこの機能を有効にすると、リクエストの失敗やコンテンツの異常を引き起こす可能性があります。

6. サービスの QPS が低すぎないかの確認：POP のディスク領域は限られており、アクセス頻度の低いリソースはアクセス頻度の高いホットリソースによって削除され、オリジンフェッチがトリガーされます。QPS が十数程度のドメイン名については、リフレッシュとプリフェッチ を使用してプリフェッチタスクを送信し、リソースを POP に常駐させることを推奨します。

症状：ページの全体的なヒット率が低いです。レスポンスヘッダーでは、メインリクエストの X-Cache は MISS ですが、ページ上の個々のファイルでは HIT となっています。

原因：URL に、タイムスタンプなど、リクエストごとに変化するパラメータが含まれています。「パラメータを無視」機能が無効の場合、CDN は異なるパラメータを持つ各 URL を独立したリソースとして扱い、キャッシュを再利用できません。たとえば、http://example.com/movie/res/ArrowScene.ccbi?_t=1699999999 の ?_t= の後の値は、リクエストごとに異なります。

解決策：CDN コンソールで [パラメータを無視] を有効にしてください。この機能を有効にすると、パラメータはキャッシュオブジェクトの計算から除外され、異なるパラメータを持つ同じリソースへのリクエストが同じキャッシュにヒットします。サービス仕様上、一部のパラメータに依存している場合は、 [指定したパラメータを保持] を選択して、無関係なものだけを無視するよう設定してください。

ヒット率の短期的な変動や継続的な低下の一般的な原因は次のとおりです。

• キャッシュリフレッシュの実行：手動または自動のリフレッシュによって POP 上のキャッシュがクリアされるため、短期間のヒット率低下は想定内の動作です。リソースが再度キャッシュされると、ヒット率は通常数時間以内に自動的に回復します。

• 帯域幅の急増：短期間での急激なトラフィックの増加は多くの初回リクエストを発生させ、オリジンフェッチが増加してヒット率が低下します。

• 大量の新しいコンテンツへのアクセス：POP が初めてアクセスされるリソースを頻繁にリクエストする場合、オリジンフェッチは避けられず、ヒット率は低下します。

• キャッシュルールの調整：キャッシュポリシーの変更、特に有効期限の短縮は、ヒット率に影響します。

• URL に可変パラメータが含まれている：パラメータを変更すると、同じコンテンツが複数のキャッシュオブジェクトに分割されます。

• キャッシュの有効期限が適切に設定されていない：更新頻度に応じてリソースを区別するような設定になっていない場合、キャッシュは早期に期限切れになります。

CDN で CORS のレスポンスヘッダーを設定しているにもかかわらず、クライアントで CORS エラーが引き続き報告され、レスポンスヘッダーに設定したフィールドが含まれない場合、原因と解決策は次のとおりです：

• 設定が反映されていない：設定が保存されており、ルールのステータスが [Success] であることを確認してください。

• 設定が完全に配信されていない：アウトバウンドレスポンスヘッダーの設定変更は、通常 5 分以内に反映されます。しばらく待ってから再試行してください。この設定は、クライアントが受信するレスポンスにのみ影響し、POP (Point of Presence) のキャッシュ動作には影響しないため、リフレッシュやプリフェッチは不要です (プリフェッチでは、すでにキャッシュされているリソースのレスポンスヘッダーは変更されません)。

• オリジンサーバーのレスポンスヘッダーが CDN の設定と競合している：オリジンサーバーも CORS のレスポンスヘッダーを返している場合、ヘッダーが互いに上書きされる可能性があります。オリジンサーバーと CDN で CORS 設定を統一するか、[アウトバウンドレスポンスヘッダーの変更] で [Allow Duplicate] を [No] に設定し、CDN で設定した値がオリジンサーバーから返される値を上書きするようにしてください。

• ブラウザが以前のレスポンスをキャッシュしている：ブラウザキャッシュをクリアするか、プライベートブラウジングモードでテストしてください。

• ワイルドカードドメイン名の設定がサポートされていない：CORS 検証を有効にした後に設定できるのは、単一のワイルドカードドメイン名、またはカンマで区切った複数の完全一致ドメイン名のみです。カンマで区切った複数のワイルドカードドメイン名はサポートされません。

• Access-Control-Allow-Origin の値がリクエストの Origin と一致しない：ブラウザで "The 'Access-Control-Allow-Origin' header has a value that is not equal to the supplied origin" と表示される場合、返された許可オリジンが実際のリクエスト Origin と一致していません。次の方法で解決できます：

  • [アウトバウンドレスポンスヘッダーの変更] で、Access-Control-Allow-Origin を再設定し、[重複を許可] を [いいえ] に設定して、新しい値がオリジンサーバーから返された以前の値を上書きするようにします。

  • 業務上問題がなければ、このレスポンスヘッダーをリクエスト内の Origin 値を動的に返すように設定し、許可オリジンが常にリクエストオリジンと一致するようにします。設定完了後、反映まで約 5 分待ちます。キャッシュのリフレッシュは不要です。

オリジン間リソース共有の設定方法については、「オリジン間リソース共有の設定」をご参照ください。

• リクエストが CDN の POP を経由していることを確認する：DNS 名前解決で、CDN が提供する CNAME レコードのみが残り、OSS などのオリジンへの直接の名前解決レコードが削除されていることを確認してください。トラフィックがオリジンサーバーへ直接到達している場合、CDN で設定したレスポンスヘッダーは反映されません。

• インバウンドではなくアウトバウンドレスポンスヘッダーを設定していることを確認する：インバウンドレスポンスヘッダーは、オリジンサーバーと CDN の POP 間の通信にのみ適用され、エンドユーザーはこれを認識できません。エンドユーザーが受信するレスポンスに影響を与えるには、[アウトバウンドレスポンスヘッダーの変更] を設定してください。

• オリジンサーバーがそのレスポンスヘッダーを返しているか確認する：CDN はデフォルトでオリジンのレスポンスヘッダーをパススルーします。オリジンサーバーがヘッダーを返さない場合、CDN も返しません。オリジンサーバーが返すかどうかに関わらずレスポンスヘッダーを必ず追加するには、[アウトバウンドレスポンスヘッダーの変更] で [Add] 操作を選択してください。

• Content-Type が反映されない場合は、オリジンサーバーのメタデータを確認する：オリジンサーバー (OSS など) がファイルのアップロード時に正しい Content-Type を指定していない場合、オリジンフェッチ時に取得されるメタデータが想定と一致しません。ファイルのアップロード時に使用した Content-Type 設定を確認してください。

• 設定が反映されるまで待機したかを確認する：アウトバウンドレスポンスヘッダーの設定変更は、通常 5 分以内に反映されます。また、この設定はクライアントが受信するレスポンスにのみ影響し、POP のキャッシュ動作には影響しないため、リフレッシュやプリフェッチは不要です (プリフェッチでは、すでにキャッシュされているリソースのレスポンスヘッダーは変更されません)。

アウトバウンドレスポンスヘッダーの設定方法とパラメータの説明については、「アウトバウンドレスポンスヘッダーの変更」をご参照ください。

原因：オリジンサーバーから返された Content-Type レスポンスヘッダーで文字エンコーディングが正しく指定されていないため、クライアントが誤ったエンコーディングでコンテンツを解析し、ページが文字化けします。

解決策 1 (推奨、ソースで修正): オリジンサーバーの設定を修正して、HTML が返されるときに Content-Type に正しい文字エンコーディング宣言が含まれるようにします。

解決策 2 (CDN 側で書き換え)：

1. CDN コンソールにログインします。[Domain Names] ページで対象のドメイン名を見つけ、[Manage] をクリックします。

2. 受信レスポンスヘッダーの変更で、一致したパスの Content-Type を text/html; charset=utf-8 に書き換えるルールを追加します。

3. 設定が完了したら、リフレッシュとプリフェッチ を使用して、そのパス配下のキャッシュ済みリソースをリフレッシュし、POP が正しいタイプで再度キャッシュするようにします。

送信レスポンスヘッダーの変更機能を使用して Content-Disposition レスポンスヘッダーを設定することで、ビデオのダウンロードまたはプレビューの動作を制御できます。attachment; filename='video.mp4' に設定すると、ユーザーがリソースにアクセスしたときにダウンロードが開始され、inline に設定すると、リソースはブラウザで直接プレビューされます。

設定が反映されない場合は、次の項目を確認してください：

1. ルールエンジンの照合条件: ルールの照合条件では、クエリ文字列のみを照合するのではなく、URI パス (例: /video-origin/20260414 を含む) を対象とするようにしてください。ルールエンジンは、ユーザーリクエスト内のパス情報を識別することによって、設定が有効になるかどうかを判断します。

2. POP が以前のレスポンスヘッダーをキャッシュしました: Content-Disposition はブラウザーの動作に直接影響します。 設定を保存してから 5 分が経過しても有効にならない場合は、まずローカルブラウザーのキャッシュの影響を排除し (プライベートブラウジングモードで再試行)、ルールのステータスが [成功] であることを確認します。

原因: オリジンサーバーが最初に JavaScript ファイルを返すときに、Content-Type レスポンスヘッダーが誤って text/html に設定されます。 CDN が間違ったタイプをキャッシュした後、ブラウザは JavaScript ファイルを text/html として解析するため、文字化けや実行エラーが発生します。 2 回目のアクセス時には、オリジンサーバーが Content-Type を修正したか、CDN がオリジンサーバーから正しいタイプを再度取得したため、ページは正常に戻ります。

解決策：

1. CDN コンソールの 受信レスポンスヘッダーの変更 で、JavaScript ファイルパス (*.js など) に一致するルールを追加し、Content-Type を application/javascript に強制的に置換します。

2. 設定が完了したら、リフレッシュとプリフェッチ を使用して JavaScript ファイルのキャッシュをリフレッシュし、新しいルールを即時に反映させます。

原因: POP にキャッシュされたファイルの長さがオリジンサーバー上の実際のコンテンツと一致しない、またはオリジンサーバーが異常な Content-Length レスポンスヘッダーを返したことが原因です。この問題は、オリジンサーバーがビデオファイルを更新したにもかかわらず、CDN が以前にキャッシュされたバージョンを返す場合に最も多く発生します。

解決策：

• 更新とプリフェッチ ページで、動画 URL の更新タスクを送信し、POP (Point of Presence) 上の古いキャッシュをクリアしてください。

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

• オリジンサーバーが断続的に異常な Content-Length 値を返していないか、その安定性を確認します。オリジンサーバーに対して直接 curl -I を複数回実行して比較、検証できます。

はい。動画プレイヤーやダウンロードツールは、通常、範囲リクエストを使用してリソースを分割して読み込みます。各リクエストではコンテンツの一部のみが取得され、サーバーは 206 Partial Content を返します。リクエストが CDN キャッシュにヒットした場合でも、返されるステータスコードは 206 であり、これはエラーではありません。

課金に関する注記：クライアントが CDN にリクエストを送信してデータを受信した場合、リクエストがキャッシュにヒットしたかどうかにかかわらず、そのトラフィックは CDN アウトバウンドトラフィックとしてカウントされます。

最適化の提案: レンジオリジンフェッチを有効にしてください。これにより、POP はオリジンサーバーからオンデマンドでセグメントを取得してキャッシュできるようになり、後続のセグメントリクエストのヒット率が向上します。さらに、オリジンサーバーで適切な Cache-Control ヘッダー (例: max-age=86400) を設定することで、ローカルのブラウザキャッシュを利用して重複したリクエストを削減できます。

原因： 画像、CSS ファイル、JavaScript ファイルなどの静的リソースはキャッシュヒットし、通常通り高速化されますが、ホームページ (ルートパス /) には通常キャッシュルールがありません。リクエストごとにホームページをオリジンサーバーから取得するため、読み込み速度は完全にオリジンサーバーの処理時間に依存します。

解決策： 高速化ドメイン名のルートディレクトリにキャッシュの有効期限ルールを追加し、ホームページのコンテンツも POP (Point of Presence) にキャッシュされるようにします：

1. [キャッシュの有効期限] タブでルールを追加し、タイプを [ディレクトリ] に、アドレスを / に設定します。

2. ホームページコンテンツの更新頻度に基づいて、有効期限を 30 秒から数分程度に設定します。

3. 静的リソースのキャッシュルールが上書きされないように、ルートディレクトリのルールの重みが (/static/ などの) 特定のパスのルールよりも低くなるように調整します。

設定が有効になると、POP はリクエストごとにオリジンサーバーから取得するのではなく、ホームページのコンテンツを直接返します。設定手順の詳細については、「CDN キャッシュの有効期限の設定」をご参照ください。

原因： POP でキャッシュミスが発生すると、クライアントのリクエストを転送し、Via や X-Forwarded-For などの特定のパラメーターをリクエストヘッダーに追加します。一部のオリジンサーバーは、これらのパラメーターに基づいて異なるレスポンスを返します。たとえば、オリジンサーバーが、リクエストに Via ヘッダーが含まれているかどうかをチェックしてプロキシリクエストを識別し、異なる処理を行う場合があります。

トラブルシューティングの手順：

1. 差異の原因となるヘッダーの特定： まずオリジンサーバーに直接アクセスしてレスポンスを記録します。次に、curl を使用して CDN が追加するヘッダーを付けてオリジンサーバーにアクセスし、結果の不整合が再現されるまで 1 つずつテストします。

2. オリジンサーバーの設定の調整： オリジン側の Web サーバーがヘッダーをどのように処理するかを確認し、ビジネス要件に基づいてロジックを変更します。

3. または、CDN 側でヘッダーを削除： ヘッダーがビジネス上不要な場合は、CDN コンソールで削除できます。

原因： オリジンサーバーがファイルの同名更新を行いました (ファイル名は変更されませんでしたが、ファイルの内容は変更されました)。キャッシュの有効期限が切れる前に、CDN の POP は引き続き以前のキャッシュを直接返すため、ダウンロードされたファイルはオリジンサーバー上のファイルと一致しません。

解決策：

1. 解決策 1：キャッシュを手動で更新する。オリジンサーバーが同名更新を行った後、更新とプリフェッチ ページで URL リフレッシュ (単一のリソースに適しており、迅速に有効になります) またはディレクトリリフレッシュ (ディレクトリ全体に適しており、範囲は広いですが、一時的にオリジンサーバーのオリジンフェッチの負荷が増加します) を送信します。

2. 解決策 2: 強制更新で 304 をバイパスする。 オリジンサーバー上のファイルコンテンツが変更されても、Last-Modified タイムスタンプが更新されなかった場合、CDN POP は条件付きリクエスト (If-Modified-Since) の検証後に 304 Not Modified を受信し、ファイルが変更されていないと判断して、キャッシュを更新しません。 この場合、通常の URL 更新が有効にならないことがあります。 オリジンサーバーから完全なファイルを強制的に取得するには、RefreshObjectCaches API を呼び出し、Force パラメーターを true に設定する必要があります。

3. 解決策 3: ファイル名のバージョニング (長期的な解決策として推奨)。 オリジンサーバーで同名ファイルを更新するのを避け、代わりに style.v2.css や app.abc123.js のようにファイル名にバージョン番号やハッシュを追加するか、?v=20260828 のように URL パラメーターにバージョン識別子を含めることをお勧めします。

4. 解決策 4：OSS オリジンのキャッシュ自動更新を有効にする。オリジンサーバーが OSS の場合、OSS コンソールで CDN キャッシュの自動更新 を有効にできます。OSS オリジンにあるオブジェクトが同名で更新されると、対応する CDN の URL が自動的に更新されます。

Web サーバーが HTTP 404 ステータスコードを返すと、自動的に 404 ページにリダイレクトされます。これは、要求されたリソースがオリジンサーバーに存在しないことを示します。一般的な原因には、URL 生成ルールが変更された、ファイル名が変更されたか移動された、リンクにタイプミスが含まれている、要求されたポートで Web サイトにアクセスできない、Web サービス拡張のロックダウンポリシーまたは MIME マッピングポリシーによってリクエストがブロックされた、などがあります。

アクセスするページに複数のリソースが含まれており、その一部のみにアクセスできない場合、ページ全体が 404 ページにリダイレクトされることはありません。カスタムエラーページの設定方法については、「カスタムエラーページの設定」をご参照ください。

403 ステータスコードのカスタムエラーページを設定する際に、エラーページ設定でリダイレクトリンクを直接設定すると、ドメインリダイレクトやリダイレクトループが発生する恐れがあります。代わりに、次の方法を使用してください：

1. カスタムエラーページでリダイレクトリンクを設定するのではなく、アクセス URL リライト機能を使用してリダイレクトを設定します。

2. 書き換えパスを / に設定し、ターゲットパスを正しい静的な 403 ページ (たとえば /error/403.html) に指定します。