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

Object Storage Service:Alibaba Cloud CDN による OSS アクセスの高速化

最終更新日:Mar 14, 2026

Object Storage Service (OSS) から画像、音声、動画、ドキュメントなどの静的リソースを配信する際は、Alibaba Cloud CDN を構成することでアクセス速度を向上させ、遅延を低減し、トラフィックコストを削減できます。

仕組み

Alibaba Cloud CDN は、分散型キャッシュアーキテクチャを使用して OSS へのアクセスを高速化します。このアーキテクチャでは、OSS バケット(オリジン)から静的コンテンツを事前に取得し、世界中の Alibaba Cloud CDN のポイントオブプレゼンス(POP)にキャッシュします。これにより、ユーザーに近い場所からコンテンツを提供できます。

  1. ユーザーがリソースを初めてリクエストすると、スマート DNS がネットワーク状態の最適な最寄りの CDN POP にリクエストをルーティングします。

  2. CDN POP はローカルキャッシュを確認します。リソースが見つからない場合、POP は OSS オリジンに対して back-to-origin リクエストを送信し、コンテンツを取得します。

  3. OSS からコンテンツを受信した後、CDN POP はそのルールに従ってリソースをキャッシュし、ユーザーに提供します。

  4. その後、他のユーザーが同じリソースをリクエストした場合、CDN POP はオリジンに問い合わせることなくローカルキャッシュから直接提供します。このプロセスにより、アクセスパスが短縮され、ネットワーク遅延が低減され、オリジンの負荷が軽減され、アクセスが高速化されます。

image

CDN 高速化の構成

開始する前に、登録済みのドメイン名があることを確認するか、新しいドメイン名を登録してください。Alibaba Cloud 以外で登録されたドメイン名も使用できます。加速リージョンが中国本土の場合、加速対象のドメイン名にはICP 登録が必要です。

ステップ 1:CDN 加速ドメインの追加とオリジンサーバーの構成

  1. CDN コンソールにログインし、[ドメイン名の追加] をクリックします。

  2. [リージョン] および [ビジネスタイプ] を設定し、[加速するドメイン名] を入力します。example.cn のようなルートドメインや、oss.example.cn のようなカスタムサブドメインを使用できます。サブドメインを使用すると、管理と拡張が容易になります。

  3. 次の図に示すように、オリジンサーバー情報を追加します。オリジン URL を OSS バケットのドメイン名に設定し、[次へ] をクリックしてドメイン名を追加します。

    image

ステップ 2:CNAME レコードの構成

DNS CNAME レコードを使用して、加速ドメイン名を Alibaba Cloud CDN が割り当てた CNAME アドレスにポイントします。これにより、ドメインの DNS クエリが CDN POP にルーティングされます。

  1. [推奨機能] ページで、[構成ガイドを開く] をクリックします。または、[ドメイン名] ページに戻り、ドメイン名の右側にある [構成待ち] にカーソルを合わせ、表示されるツールチップで [構成ガイドを開く] をクリックします。

    image

  2. CNAME レコード値(例:example.cn.w.kunlunap.com)をコピーします。このアドレスは DNS 構成で使用します。

  3. Alibaba Cloud DNS コンソールに移動します。対象のドメイン名について、操作列の [設定] をクリックします。

  4. [レコードの追加] をクリックし、以下のようにレコード情報を入力します。他のパラメーターはデフォルト設定のままにしてください。CNAME レコードがすでに存在する場合は、操作列の [編集] をクリックし、値をコピーした CNAME に更新します。

    • [レコードタイプ]: [CNAME] を選択してください。

    • [ホスト名]:ルートドメイン(例:example.cn)を使用する場合は、@ を入力します。サブドメイン(例:oss.example.cn)を使用する場合は、サブドメインプレフィックス(例:oss)を入力します。

    • [レコード値]:コピーした CNAME レコード値を貼り付けます。

  5. [OK] をクリックします。

    DNS 変更の反映時間は、レコードの TTL(Time to Live)設定によって異なります。通常、変更が完全に反映されるまで数分から数時間かかります。構成後、一時的にドメインにアクセスできなくなる場合があります。変更が反映されるまで待つか、ローカル DNS キャッシュをクリアしてみてください。

ステップ 3:非公開バケットの back-to-origin 構成

デフォルトでは、新規作成されたバケットは非公開です。Alibaba Cloud CDN が非公開バケットにアクセスできるようにするには、非公開バケットアクセスを有効にして権限付与する必要があります。バケットが公開読み取りの場合は、この手順は不要です。

  1. CDN コンソールに移動し、対象のドメイン名をクリックして、左側のナビゲーションウィンドウで [back-to-origin] をクリックします。

  2. 次の図に示すように、[Alibaba Cloud OSS 非公開バケットアクセス] を有効にします。

    image

重要

非公開バケットアクセスを有効にすると、CDN は非公開バケットへのアクセスが許可され、back-to-origin リクエストに自動的に署名を追加します。そのため、クライアントは署名パラメーターを含まない URL(例:http://example.cn/dest.jpg)を使用する必要があります。URL に ExpiresSignature などの署名パラメーターが含まれていると、二重署名の競合が発生し、OSS から 403 Forbidden エラーが返されます。

ステップ 4:高速化効果の検証

構成が完了したら、比較テストを実行して、加速ドメイン名のパフォーマンス向上を検証します。

  1. バケットへのファイルのアップロード

    [バケット] ページで、ご利用のバケット名をクリックします。[オブジェクト] ページで、[オブジェクトのアップロード] をクリックします。アップロードする静的リソース(例:dest.jpg)を選択し、画面の指示に従ってアップロードを完了します。

  2. ファイルアクセス URL の取得

    • デフォルトの OSS アクセス URL[オブジェクト] ページで、オブジェクトの操作列にある [詳細の表示] をクリックします。詳細ページで、[オブジェクト URL のコピー] をクリックします。

      image

    • CDN 加速アクセス URL:CDN 加速ドメイン名とファイル名を使用して、署名を含まないアクセス URL を構築します。例:http://example.cn/dest.jpgexample.cn は CDN 加速ドメイン名)。

  3. 高速化効果の検証

    CloudMonitor 合成テストなどの専門的なスピードテストプラットフォームまたはツールを使用して、デフォルトの OSS アクセス URL と CDN 加速アクセス URL を使用した場合の同一ファイルの読み込み時間を比較します。

    説明

    テストデータは参考情報です。アクセス速度の向上効果は、ネットワーク環境や地理的位置などの要因により異なる場合があります。初回テストでは、CDN POP がまだリソースをキャッシュしておらず back-to-origin を実行する必要があるため、高速化効果が不明瞭な場合があります。初回テスト後、CDN がリソースをキャッシュするのを待ってから再度テストし、高速化効果を確認してください。

    image

  4. キャッシュヒットステータスの確認

    ブラウザの開発者ツール(F12)を使用して、レスポンスヘッダー内の X-Cache フィールドの値を確認します。この値は、リクエストが CDN キャッシュにヒットしたかどうかを示します。

    • 値が HIT で始まる場合、リクエストは CDN キャッシュに正常にヒットしており、高速化が有効です。

    • 値が MISS で始まる場合、リクエストは CDN キャッシュにヒットせず、OSS に対して back-to-origin が実行されました。

複数バケットへの back-to-origin 構成

アーキテクチャで異なるタイプまたはカテゴリのリソースを格納するために複数の OSS バケットを使用している場合は、以下のいずれかのマルチオリジン構成を使用します。

方法 1:独立サブドメインアーキテクチャ

機能やリソースタイプごとに独立した意味のあるサブドメインをバケットに割り当て、各サブドメインに対して個別に CDN 高速化を構成します。たとえば、画像リソースには img.example.cn、音声・動画リソースには video.example.cn を使用します。意味のあるサブドメインにより、リソースの識別と保守が容易になり、DNS トラフィック分散により単一ドメインの接続制限を回避できます。

このアーキテクチャでは、リソースタイプごとに完全に分離されるため、各バケットに対して個別にキャッシュポリシー、セキュリティ構成、モニタリングを設定および最適化できます。

  • 画像リソースには長期キャッシュポリシーを構成してアクセス速度を向上させます。

  • 動画リソースには Range オリジンフェッチを有効にして再開可能なダウンロードをサポートします。

  • 機密文書には URL 署名を有効にしてセキュリティを確保します。

独立したモニタリングシステムにより、パフォーマンスボトルネックや異常トラフィックを正確に特定でき、詳細な運用管理が可能になり、異なるサービス間の干渉リスクを低減します。

方法 2:パスベースのルーティングによる統一ドメイン

異なるサービスまたはアプリケーション向けに複数のバケットを使用しているが、単一の統一アクセスポイントを提供したい場合は、単一の CDN 加速ドメイン名を構成します。ルールエンジンを使用して、異なるアクセスパスを持つリクエストを特定のバケットにルーティングします。このアプローチにより、ブランドイメージが統一され、ドメイン名および SSL 証明書のメンテナンスが簡素化され、運用管理の複雑さが軽減されます。以下の例では、2 つのバケット cdn-bucket1 および cdn-bucket2 を使用して構成を説明します。

  1. パスルールの追加

    CDN コンソールで、対象の加速ドメイン名をクリックします。次に、[ルールエンジン] > [ルールの追加] をクリックします。次の図に示すように、http://example.cn/bucket1/* および http://example.cn/bucket2/* をそれぞれマッチングする 2 つの URL パスルールを追加します。この例では、example.cn は加速ドメイン名です。bucket1 および bucket2 は、それぞれ cdn-bucket1 および cdn-bucket2 を指す仮想パスです。* は、バケット内のオブジェクトの実際のパスを表します。

    image

  2. 条件付きオリジンの構成

    加速ドメイン名の [基本情報] セクションで、2 つの条件付きオリジンを構成します。作成したパスルールをそれぞれの対象バケットオリジンアドレスにアタッチします。これにより、リクエストがマッチングパスルールに基づいて自動的に正しいオリジンにルーティングされます。

    image

  3. back-to-origin ホストの指定

    条件付きオリジンルーティングを設定した後は、CDN ドメイン名のオリジンフェッチ 構成で、各オリジンサーバーの back-to-origin ホストも指定する必要があります。これにより、オリジンリクエストが正しいターゲットバケットにルーティングされるようになります。

    image

  4. オリジン URL の書き換え

    オリジンがリソースを正しく特定できるようにするには、CDN ドメイン名の [バックトゥオリジン] 構成でオリジン URL を書き換える必要があります。この書き換えにより、ルーティングに使用される仮想パス(例: /bucket1)がバックトゥオリジン時に自動的に削除され、オリジンリクエストパスがバケット内のオブジェクトの実際のストレージパスと一致するようになります。

    image

  5. 効果の検証

    構成が完了したら、単一の CDN 加速ドメイン名を使用して、異なるパスに基づいて異なる OSS バケット内のリソースにアクセスできます。これにより、マルチオリジンアクセスの統一エントリーポイントが提供されます。

    image

本番環境に適用

ベストプラクティス

  • 安全な転送:HTTPS の有効化

    加速ドメイン名にHTTPS 証明書を構成し、強制 HTTPS リダイレクトを有効にして、クライアントと CDN POP 間で転送されるデータを暗号化します。HTTPS により、転送中のデータの盗難や改ざんを防止し、ブラウザのアドレスバーに「Not Secure」警告が表示されなくなり、ユーザーの信頼性、ブランドイメージ、最新の Web セキュリティ基準へのコンプライアンスが向上します。

  • パフォーマンス最適化:包括的なキャッシュポリシーの構成

    キャッシュポリシーは CDN パフォーマンスの中核を成します。適切に設計されたキャッシュポリシーは、キャッシュ期間とパラメーター処理の両方に配慮し、最適なパフォーマンスと機能互換性を実現する必要があります。

    • TTL の設定適切なキャッシュ期間を設定することで、キャッシュヒット率を最大化し、back-to-origin リクエストの頻度と帯域幅コストを大幅に削減できます。

      • 頻繁に更新されない静的ファイル:画像、音声、動画、アプリケーションインストールパッケージなどのファイルについては、不要なオリジンリクエストを削減するために、1 ヶ月以上などの長いキャッシュ期間を設定します。

      • 更新頻度が低い静的ファイル:JS や CSS などのファイルについては、ビジネスの更新頻度に基づいて数時間~数日のキャッシュ期間を設定します。リリース管理にはバージョン管理(例:style.v1.1.css)を使用します。

      • 動的ファイルまたは API:PHP や JSP などのファイルについては、すべてのリクエストで最新のコンテンツを取得できるように、キャッシュ時間を 0 秒(キャッシュなし)に設定します。

    • 画像処理を有効にするためのパラメーター処理の構成:OSS は、スケーリング、トリミング、ウォーターマークなどの画像処理機能を提供します。デフォルトでは、CDN はキャッシュヒット率を最大化するためにすべてのパラメーターをフィルター処理します。これにより、?x-oss-process などの画像処理命令が機能しなくなります。これらの機能を使用するには、CDN コンソールに移動し、[ドメイン名] > [加速ドメイン名] > [最適化] に進み、[パラメーターの無視] 構成を変更します。

  • 可用性の確保:リソースプリフェッチと自動キャッシュ更新の使用

    キャッシュが有効になっている場合、オリジンファイルの変更はすぐに CDN POP に反映されません。ユーザーが最新のリソースに迅速にアクセスできることを保証し、バージョンリリースなどの重要な時期にサービスの安定性を維持するために、以下の戦略を推奨します。

    • リソースプリフェッチ:バージョンリリースや運用アクティビティの前に、Alibaba Cloud CDN のリソースの消去とプリフェッチ機能を使用して、ホットスポットリソースを事前にグローバルノードに配信します。これにより、コンテンツ公開時にオリジンサーバーへの急増する back-to-origin リクエストの影響を防ぎ、ユーザーの初回アクセス時にスムーズな体験を提供できます。

    • 自動 CDN キャッシュ更新:OSS コンソールの [バケット設定] > [ドメイン名] ページで、ドメイン名の自動 CDN キャッシュ更新を有効にします。API を介して OSS ファイルを更新すると、OSS が自動的に CDN リフレッシュタスクをトリガーし、ユーザーが最新のコンテンツに迅速にアクセスできるようにします。

      説明

      この機能は絶対的なリアルタイム更新を保証するものではありません。適時性スコアが極めて高いユースケースでは、ファイル更新後に積極的に CDN リフレッシュ機能を使用してください。

  • クロスオリジンアクセス:CORS ポリシーの構成

    OSS オリジンでのみ CORS ルールを構成しても、クロスオリジンリクエストに対して信頼性がありません。CDN が CORS ヘッダーを含まないレスポンスをキャッシュして提供する可能性があり、ブラウザがリクエストをブロックする原因となります。推奨される解決策は、CDN 上で直接 Access-Control-Allow-Origin およびその他の必要な CORS ヘッダーを構成することです。これにより、キャッシュステータスに関係なく、すべての関連レスポンスにこれらのヘッダーが含まれるようになります。

    1. CDN コンソールで、加速ドメイン名をクリックするか、操作列の [管理] をクリックします。

    2. 次の図に示すように、[キャッシュ] > [送信リクエストヘッダーの変更] ページで、レスポンスヘッダーのパラメーターと値を設定します。

      説明

      パラメーター設定は参考情報です。必要に応じて調整してください。

      image

      構成が完了すると、CDN POP を介して OSS リソースにアクセスする際に、レスポンスに常に指定された CORS ヘッダーが含まれるようになります。これにより、クロスオリジンリクエストがブラウザの検証を通過できるようになります。

      image

  • パフォーマンス最適化:大容量ファイルおよびデータ転送の効率向上

    • Range オリジンフェッチの有効化:オンデマンド動画/音声ストリーミングや大容量ファイル配信などのユースケースでは、Range オリジンフェッチを有効化することが重要です。これにより、CDN POP が大容量ファイルの一部をオンデマンドでリクエストできます。動画再生中のシークなどの高度な機能を有効にするだけでなく、不要な back-to-origin トラフィックと初期ロード時間を大幅に削減します。

    • データ転送の最適化:CDN コンソールでGzip 圧縮またはページの最適化を有効にして、JS、CSS、HTML などのテキストファイルの転送サイズを削減し、転送効率を向上させます。Gzip 圧縮は、リソースを返す前に圧縮します。一方、ページの最適化は、HTML ページおよび埋め込まれた JavaScript と CSS からコメントや繰り返しの空白文字などの不要なコンテンツを自動的に削除します。

      説明
      • ページの最適化または Gzip 圧縮を有効にすると、ファイルの Content-Length および Content-MD5 値が変更されます。ビジネスロジックでこれらの値を検証に使用している場合は、これらの機能を慎重に有効にしてください。

      • ページの最適化と Gzip 圧縮の両方を有効にした場合、ページの最適化機能は無効になります。CDN はファイルに対して Gzip 圧縮のみを実行します。

  • シームレスな移行:ゼロダウンタイムドメイン切り替えの実装

    OSS バケットドメインから加速ドメインへの既存サービスを移行する際は、サービス継続性と安定性を確保するために段階的なアプローチを採用します。

    1. 準備フェーズ:CDN 加速ドメイン名のすべての構成を完了し、テスト環境でその機能とパフォーマンスを十分に検証します。

    2. 段階的リリースフェーズ(オフピーク時間帯の実施を推奨):段階的リリースアプローチを使用して、サービストラフィックの一部を CDN 加速ドメイン名に切り替えます。徐々にトラフィックを増やして、切り替えリスクを軽減します。

    3. 検証フェーズ:サービスアクセスログおよびエラーレートを厳密に監視します。応答時間や成功率などの主要メトリックを分析して、段階的リリース中のサービスが正常であり、ビジネスが円滑に稼働していることを確認します。

    4. 完全リリースフェーズ:十分な検証後、すべてのサービストラフィックを CDN 加速ドメイン名に切り替えて、ドメイン名の移行を完了します。

    5. ロールバック計画:問題が発生した場合は、すぐにトラフィックを元のバケットドメインにロールバックする計画を用意します。再デプロイ前に、問題の根本原因を詳細に分析します。

リスク防止

  • ホットリンクおよび不正アクセスからの保護:リファラーに基づくホットリンク保護と URL 署名の構成

    • ホットリンク保護リファラーブラックリストまたはホワイトリストを構成してホットリンク保護を有効にします。この方法では、HTTP リクエストヘッダーの Referer フィールドを検証してホットリンクを防止し、指定されたドメインからのみアクセスを許可します。

    • URL 署名:OSS バケットの非公開 back-to-origin を有効にすると、CDN POP が直接アクセスできるようになり、OSS のネイティブ署名検証がバイパスされます。つまり、非公開リソースが CDN ドメインを通じて公開アクセス可能になります。これらのリソースを保護するために、CDN 上でURL 署名を有効にしてください。この機能により、リクエストに一意の署名とタイムスタンプを含めることが必須となり、不正なダウンロードおよび配布を防止します。

  • オリジン接続のセキュリティ確保:オリジン SNI および back-to-origin ホストの構成

    Alibaba Cloud CDN と OSS 間の安定的かつ安全な通信を確保することは、サービス可用性の重要な保証です。

    • オリジン SNI の構成:CDN 設定でオリジンサーバ名表示(SNI)を構成し、back-to-origin ホスト(通常は加速ドメイン名)と一致させる必要があります。これは、OSS への安全な接続にとって重要です。

      正しい SNI を構成しない場合:

      • OSS は TLS ハンドシェイク中にご利用のドメインを識別できず、デフォルト証明書を提供するため、証明書不一致エラーが発生し、接続が失敗します。

      • OSS はご利用のリクエストを未識別トラフィックとして扱い、より厳しい速度制限を適用する可能性があり、パフォーマンスに影響します。

    • オリジン情報の非表示

      デフォルトでは、CDN はバケットドメイン名を使用して back-to-origin を実行します。back-to-origin エラー(例:ファイルが存在しない)が発生すると、エラーメッセージに OSS バケットドメイン名が公開される可能性があり、セキュリティリスクとなります。

      image

      オリジン情報を非表示にしてセキュリティを強化するには、次の手順に従って back-to-origin ホストを CDN 加速ドメイン名に変更します。

      1. [バケット] ページで、対象のバケット名をクリックします。次に、[バケット設定] > [ドメイン名] に進み、加速ドメイン名をバケットにマッピングします。

        image

      2. CDN コンソールで、対象の高速化ドメイン名をクリックします。 次に、[オリジンフェッチ] > [デフォルトオリジンホスト]に移動し、[変更]をクリックして[ドメインタイプ][CDN ドメイン]に変更します。

  • 監査およびトラブルシューティング:アクセスログの有効化セキュリティ監査、パフォーマンス分析、および本番環境でのトラブルシューティングを行うには、包括的なログ記録を有効にする必要があります。リアルタイムログ配信の設定を CDN コンソールで行い、アクセスログを Simple Log Service (SLS) に送信します。SLS を使用すると、アクセス動作およびトラフィックのディストリビューション、人気のあるリソースおよびコンテンツ、エラー率およびリクエスト失敗など、主要なメトリックについて詳細な分析を実行し、アラートを設定できます。このデータは、パフォーマンスの最適化およびセキュリティの強化に不可欠です。

課金

  • CDN 料金:OSS アクセスの高速化のために CDN を構成すると、CDN トラフィック料金が発生します。詳細については、「CDN 課金概要」をご参照ください。

  • OSS 料金:CDN キャッシュミスが発生すると、CDN POP が OSS からリソースを取得するため、CDN back-to-origin アウトバウンドトラフィック料金が発生します。詳細については、「OSS トラフィック料金」をご参照ください。

よくある質問

5xx エラーが CDN back-to-origin 中に発生するのはなぜですか?

5xx エラーは、CDN が OSS オリジンからリソースを取得できなかったことを示します。以下の点を確認して問題をトラブルシューティングしてください。

  • オリジン構成CDN コンソールで構成された OSS オリジンアドレスが正しいかどうかを確認します。

  • back-to-origin プロトコル:CDN が HTTPS back-to-origin またはback-to-origin プロトコルに構成されている場合、オリジンが HTTPS アクセスをサポートしており、SSL 証明書が正しく構成されていることを確認します。

  • ネットワークリンク:CDN POP またはローカルマシンから OSS オリジンへのネットワーク接続をテストします。CDN POP はインターネット上にあるため、CDN に構成されたオリジンはインターネット経由でアクセス可能である必要があります。オリジン IP アドレスがインターネットから到達不可能、ポートが閉じられている、またはオリジンドメイン名が解決されない場合、オリジンサーバーへの CDN back-to-origin リクエストは失敗します。

  • オリジンサーバーの負荷CDN リアルタイムモニタリング ページで、帯域幅およびトラフィックが急増していないかを確認します。多数の back-to-origin リクエストによりオリジンサーバーの負荷が過剰になり、back-to-origin 応答がタイムアウトする可能性があります。ホットスポットリソースについては、リソース公開時にリソースプリフェッチおよび適切なキャッシュ期間の設定を行う必要があります。

CDN で高速化された静的ページにアクセスした際に 403 Forbidden エラーまたは You are forbidden to list buckets エラーが発生するのはなぜですか?

原因分析:この問題は通常、静的 Web サイトホスティングが構成された非公開バケットに対して CDN 高速化を有効にした後に発生します。根本原因は、次の 2 つのアクセスメカニズムの競合です。

  • CDN 非公開 back-to-origin:CDN が OSS に対して back-to-origin を実行する際、本人確認のために署名情報を付与します。

  • OSS 静的 Web サイトホスティング:デフォルトページ機能(例:/ にアクセスした際に自動的に index.html を返す)では、アクセスリクエストが匿名である必要があります。

ユーザーが加速ドメイン名のルートディレクトリにアクセスすると、CDN は署名付きリクエストをバケットのルートディレクトリに送信します。OSS がこの署名付きリクエストを受信すると、リクエストが匿名ではないため静的 Web サイトホスティングロジックがトリガーされません。代わりに、ListObjects(ファイル一覧表示)操作を実行しようとします。通常、アクセスポリシーではこの種の操作が禁止されているため、403 Forbidden エラーが返されます。

ソリューション:OSS の静的 Web サイトホスティング機能をバイパスし、CDN 上でURL 書き換えルールを構成して同様の結果を得ます。

  • 書き換え対象パス^/$(ルートディレクトリアクセスにマッチ)

  • [ターゲットパス]/index.html(またはインデックスページの実際のファイル名)

  • [フラグ][リダイレクト] に設定します。

CDN ドメイン名経由で OSS にファイルをアップロードできますか?

セキュリティ上の理由から、CDN ドメイン名経由で OSS にファイルをアップロードしないでください。CDN で書き込みメソッド(PUT や POST など)を許可している場合、誰でも本人確認や権限付与なしに CDN 経由で OSS にファイルをアップロードできます。これにより、サービスが悪意のあるアップロードやデータ改ざん攻撃に対して脆弱になります。OSS ドメイン名を使用して、最小権限の原則に従ってファイルをアップロードしてください。

CDN 高速化を使用した後、OSS アウトバウンドトラフィックは減少しますか?

はい、大幅に減少します。リクエストが OSS バケットではなく CDN キャッシュから提供されることで、OSS アウトバウンドトラフィックが削減されます。これは、人気のある画像、ダウンロード、Web サイトアセットなど、頻繁にアクセスされるコンテンツで最も効果的です。

キャッシュヒット率が高いほど、オリジントラフィックが直接低下し、コスト削減効果が大きくなります。

ファイルの実際のアクセス回数をカウントするにはどうすればよいですか?

CDN 高速化を有効にした後、OSS アクセスログには CDN キャッシュから直接提供されたエンドユーザーのアクセスリクエストが記録されません。ファイルアクセスの実際の回数をカウントするには、以下の方法を使用します。