CDN:オリジンフェッチのトラブルシューティング

CDN ノードはゲートウェイとして機能し、オリジンサーバーから有効なレスポンスを取得できない場合に 502 (Bad Gateway) エラーを返します。オリジンフェッチパスの以下のいずれかの段階で障害が発生すると、502 エラーが返されることがあります。

• オリジンサーバーが HTTPS をサポートしていない (ポート 80 でのみリッスンしている) にもかかわらず、CDN が HTTPS でのオリジンフェッチを実行するよう設定されている場合。

• オリジンポートが、オリジンサーバーが実際にリッスンしているポートと一致しない場合。

• オリジンサーバーは証明書の選択に SNI を使用するものの、CDN が SNI 値を送信しない、または誤った値を送信している場合。

• オリジンサーバーの SSL 証明書の有効期限が切れている、無効である、またはドメイン名と一致しない場合。

• オリジンサーバーが自己署名証明書または内部 CA によって発行された証明書を使用しているため、オリジンフェッチ中の TLS 検証に失敗する場合。

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

• オリジンサーバーが現在のオリジンフェッチプロトコルをサポートしているかどうかを確認します: curl -Iv https://origin-domain を実行して、オリジンサーバーを直接検証します。接続が拒否されたり、タイムアウトしたりした場合、オリジンサーバーは HTTPS をサポートしていません。オリジンプロトコルを HTTP に変更します。オリジンサーバーが HTTPS をサポートし、証明書が有効である場合、HTTPS オリジンフェッチまたはプロトコルフォローを選択できます。

• オリジンポートがオリジンサーバーのリッスンポートと一致しているかどうかの確認：デフォルトのオリジンポートは、HTTPS の場合は 443、HTTP の場合は 80 です。オリジンサーバーがカスタムポート (1〜65535) を使用している場合は、オリジンプロトコル設定で対応するポートを指定します。

• オリジン SNI 設定の確認：オリジンサーバーが同じ IP アドレスで複数の HTTPS サイトをホストしている場合、対応する SSL 証明書を選択するために TLS ハンドシェイクの SNI (Server Name Indication) フィールドに依存します。CDN のオリジンフェッチが SNI 値を送信しないか、SNI 値が正しくない場合、オリジンサーバーは正しい証明書を照合できず、TLS ハンドシェイクが失敗し、502 エラーが返されます。

  解決手順：CDN コンソールにログインし、[ドメイン名管理] を選択し、対象のドメイン名を選択して [オリジン設定] に移動し、オリジン SNI を有効にします。オリジンサーバーが実際にサービスを提供するために使用するドメイン名 (通常はオリジン証明書の共通名と同じ) を入力します。また、オリジンホストをオリジンドメイン名に設定します。

  オリジンフェッチ中、CDN は SNI 値をオリジンサーバーの証明書の共通名と照合して検証します。2 つの値が一致しない場合 (例えば、オリジンサーバーが統一されたアクセスレイヤーで証明書を使用している場合など)、証明書の共通名を 共通名ホワイトリスト に追加します。

  説明

  オリジン SNI は TLS ハンドシェイク中に証明書を選択するために使用され、オリジンホストは HTTP レイヤーでの仮想ホストルーティングに使用されます。この 2 つは異なる目的を果たしますが、通常は同じオリジンドメイン名に設定されます。

• オリジンサーバー上の SSL 証明書の有効性を確認する：証明書が期限切れまたは失効していないこと、および証明書内のドメイン名にオリジンドメイン名が含まれていることを確認します。 curl -Iv https://origin-domain 2>&1 | grep -E "expire|subject|issuer" を実行すると、証明書の有効期間、発行者、およびバインドされたドメイン名を表示できます。 証明書が期限切れであるか、ドメイン名と一致しない場合は、オリジンサーバーで証明書を更新します。 オリジンサーバーが自己署名証明書または内部 CA によって発行された証明書を使用している場合は、パブリックに信頼された CA によって発行された証明書に置き換えるか、オリジンプロトコルを HTTP に変更します。

解決策：オリジンサーバーの実際の設定に基づいてオリジンプロトコルを変更します。オリジンサーバーが HTTP のみをサポートしている場合は HTTP (デフォルトでポート 80) を選択します。オリジンサーバーが HTTPS をサポートし、証明書が有効な場合は HTTPS (ポート 443 またはカスタムポート) を選択します。オリジンサーバーが両方のプロトコルをサポートし、証明書が適切に管理されている場合は、プロトコル追従を選択できます。詳細な手順については、「オリジンプロトコルポリシーの設定」をご参照ください。

オリジンプロトコルがプロトコル追従に設定されている場合の 502 エラーのトラブルシューティング方法

オリジンプロトコルがプロトコル追従に設定されている場合、CDN はクライアントリクエストと同じプロトコルをオリジンフェッチに使用します。クライアントが HTTP を使用する場合、CDN は HTTP でオリジンフェッチを行います。クライアントが HTTPS を使用する場合、CDN は HTTPS でオリジンフェッチを行います。クライアントが HTTPS 経由で CDN にアクセスするものの、オリジンサーバーが HTTPS をサポートしていない場合、TLS ハンドシェイクが失敗し、オリジンフェッチリクエストは失敗します。この問題の原因は「オリジンフェッチ中に返される 502 エラーのトラブルシューティング方法」と同じであり、同じトラブルシューティング手順で診断できます。

解決策：

• 方法 1：オリジンプロトコルをプロトコル追従から HTTP に変更し、CDN が常に HTTP でオリジンフェッチを行うようにします。

• 方法 2：オリジンサーバーに SSL 証明書を設定し、HTTPS アクセスをサポートするようにします。詳細については、「オリジンプロトコルポリシーの設定」をご参照ください。

504 (Gateway Timeout) エラーは、CDN ノードがオリジンフェッチ中に指定された時間内にオリジンサーバーからレスポンスを取得できなかったことを示します。

一般的な原因は次のとおりです。

• オリジンサーバーの応答が遅い、またはサービスが利用できない。

• オリジンフェッチリクエストが中間ネットワークデバイスまたはファイアウォールによってドロップされる (SYN パケットがドロップされる場合、接続タイムアウトになります)。

• オリジンプロトコルまたはポートが誤って設定されているため接続を確立できない (通常は 502 エラーになりますが、ファイアウォールが積極的に拒否するのではなく、パケットをサイレントドロップする場合、504 エラーになることもあります)。

• オリジンリードタイムアウトが短すぎて、オリジンサーバーの実際の応答時間に対応できない。

オリジンフェッチのタイムアウトは 2 つのフェーズに分類され、それぞれトラブルシューティングの方向性が異なります。

• 接続フェーズのタイムアウト：CDN ノードがオリジンサーバーとの TCP 接続を確立するためのタイムアウトは 10 秒です。このフェーズでのタイムアウトは、通常、オリジンサーバーがオリジンポートでリッスンしていない、ファイアウォールまたはセキュリティグループが CDN オリジンフェッチ IP アドレスからの SYN パケットをドロップしている、またはネットワークパスに深刻なパケットロスが存在することが原因であることを示します。

• 読み取りフェーズのタイムアウト：接続は確立されていますが、オリジンサーバーがオリジンリードタイムアウト (デフォルトで 30 秒) 以内に完全なレスポンスを返しません。このフェーズでのタイムアウトは、通常、データベースクエリの遅延、バックエンドアプリケーションのブロック、オリジンサーバーの高負荷など、オリジンサーバーでのリクエスト処理が遅いことが原因であることを示します。

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

1. オリジンサーバーにアクセスできるかどうかを確認: curl -I http(s)://origin-domain を実行するか、ブラウザでオリジンサーバーにアクセスして、そのレスポンスタイムとステータスコードを確認します。オリジンサーバー自体の応答が遅い、またはアクセスできない場合は、まずオリジンサーバーのパフォーマンスまたは可用性の問題を修正します。

2. どのフェーズで時間が費やされているかの特定：次のコマンドを実行します。

   curl -o /dev/null -s -w "time_connect:%{time_connect} time_starttransfer:%{time_starttransfer} time_total:%{time_total}\n" http(s):///

   time_connect は TCP 接続を確立するまでにかかった時間、time_starttransfer は最初のバイトを受信するまでにかかった時間、time_total は合計時間です。

   • time_connect がすでに非常に大きい場合は、接続フェーズの問題としてネットワークとファイアウォールのトラブルシューティングを行ってください。

   • time_starttransfer が time_connect より大幅に大きい場合、オリジンサーバーのビジネス処理は低速です。オリジンサーバーを最適化してください。

   • time_total が time_starttransfer より大幅に大きい場合、レスポンスボディが大きすぎるか、オリジンサーバーの送信帯域幅が不足しています。

3. オリジンプロトコルとポート設定の確認：CDN で設定されたオリジンプロトコルとポートが、オリジンサーバーが実際にリッスンしている設定と一致していることを確認します。オリジンポートが正しくないか、オリジンサーバーがそのポートでリッスンしていない場合、リクエストがタイムアウトした後に CDN は 504 エラーを返します。

4. オリジンサーバーのファイアウォールまたはセキュリティグループの確認：オリジンサーバーが CDN オリジンフェッチ IP アドレス範囲をスロットリングまたはブロックしている場合、一部のリクエストがタイムアウトする可能性があります。特に、SYN パケットをサイレントドロップするポリシーは、接続フェーズのタイムアウトに直接つながります。CDN オリジンフェッチ IP アドレス範囲をオリジンサーバーのホワイトリストに追加します (「CDNオリジンフェッチノードのIPアドレスとは」をご参照ください)。

5. CDN ノードとオリジンサーバー間のネットワークパスの品質の確認：CDN ノードとオリジンサーバーの間には、ネットワークのジッター、パケットロス、またはキャリアのルーティングの問題が存在する可能性があります。MTR や traceroute などのツールを使用してパスを分析します (CDN ノード側からの診断を開始するには、Alibaba Cloud のテクニカルサポートにお問い合わせください)。

6. オリジンリードタイムアウトの増加：オリジンサーバーの応答時間がデフォルトの 30 秒に近い場合は、CDN コンソールでオリジンHTTPリクエストタイムアウトを増やすことで 504 エラーを減らすことができます。値は最大 150 秒まで設定できますが、60 秒を超えないようにすることを推奨します。これは一時的な緩和策としてのみ使用してください。根本的な解決策は、オリジンサーバーの応答パフォーマンスを最適化することです。

503 (Service Temporarily Unavailable) エラーは、オリジンサーバーが一時的にリクエストを処理できないことを示します。CDN のオリジンフェッチ中に受信した 503 エラーは、通常、オリジンサーバー側に原因があります。

• オリジンサーバー上の Web サービスプログラムが異常、未起動、または再起動中であること。

• オリジンサーバーの負荷が高すぎること (CPU、メモリ、または接続数が飽和状態)。

• オリジンサーバーに IP ごとのリクエストレート制限または同時接続制限が設定されていること。

• サーバーセキュリティソフトウェア (Yunsuo や SafeDog など)、WAF、またはオリジンサーバー上のファイアウォールなどのセキュリティポリシーが CDN オリジンフェッチ IP アドレスをブロックしていること。

• オリジンサーバーがメンテナンスモードに入っているか、デプロイ中であること。

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

1. hosts ファイルをバインドしてオリジンサーバーに直接アクセスし、問題を再現する：ローカルの hosts ファイルを変更して、高速化ドメイン名をオリジンサーバーの IP アドレスに対応付け、その後ドメイン名にアクセスします。オリジンサーバーへの直接アクセスでも 503 エラーが返される場合、問題はオリジンサーバー側にあり、CDN ノード自体は除外できます。

2. オリジンサーバーの Web サービスが正常かどうかの確認：NGINX、Apache、IIS などの Web サービスプロセスが実行され、対応するポート (80/443 またはカスタムポート) でリッスンしていることを確認します。サービスプロセスが異常または未起動の場合は、サービスを再起動し、サービスログを確認して原因を特定します。

3. オリジンサーバーの負荷とレート制限設定の確認：オリジンサーバーの CPU、メモリ、または接続負荷が高いことや、IP ごとのリクエスト制限 (NGINX の limit_req や limit_conn モジュールなど) が原因で、CDN からのオリジン取得リクエストに対して 503 エラーが返されることがあります。 トラフィック量に基づいて、リソースをスケールアウトするか、レート制限のしきい値を調整する必要があるかどうかを検討してください。

   説明

   CDN オリジンフェッチリクエストは、限られたオリジンフェッチノード IP アドレスのセットから集中的に送信されるため、オリジンサーバーが IP でスロットリングを行うと、単一 IP からの高頻度アクセスと誤認されやすいです。CDN オリジンフェッチ IP アドレス範囲に対しては、より高いレート制限のしきい値を設定するか、直接免除することを推奨します。

4. セキュリティポリシーが CDN オリジンフェッチ IP アドレスをブロックしているかどうかの確認：セキュリティグループ、ファイアウォール、WAF、またはオリジンサーバー上のサーバーセキュリティソフトウェアなどのセキュリティポリシーが、CDN オリジンフェッチ IP アドレスを異常なトラフィックとして識別し、ブロックする可能性があります。ブロックログで CDN ノード IP アドレスからのレコードを探し、CDN オリジンフェッチ IP アドレス範囲をホワイトリストに追加します (取得方法については、「CDNオリジンフェッチノードのIPアドレスとは」をご参照ください)。

5. CDN キャッシュの更新：オリジンサーバーが復旧した後も 503 エラーが返される場合は、URL を更新します。 500、502、503、504 などのステータスコードの場合、CDN のキャッシュの優先順位は次のとおりです。オリジンサーバーが Set-Cookie を返す場合はキャッシュしない → コンソールでステータスコードの有効期限が設定されている場合は、その設定に従ってキャッシュする → それ以外の場合は、オリジンサーバーの Pragma、Cache-Control、および Expires レスポンスヘッダーに従ってキャッシュする → 上記のいずれの条件も適用されない場合は、デフォルトで 1 秒間キャッシュする。 したがって、デフォルトでは 503 エラーが永続的な影響を及ぼすことはありません。 ただし、コンソールで 5xx ステータスコードに対して長い有効期限が設定されている場合、異常なレスポンスは期限切れになるまでキャッシュされ続けます。 このような場合は、手動で更新するか、5xx ステータスコードのキャッシュ時間を 0 に設定します。 詳細については、「HTTP ステータスコードの有効期限を設定する」をご参照ください。

現象

オリジンサーバーは通常、Host リクエストヘッダーによって仮想サイトを区別します。CDN で設定されたオリジンホストがオリジンサーバーで想定しているドメイン名と一致しない場合、オリジンサーバーは 404、403、500 などのエラーを返すことがあります。

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

1. オリジンホストがオリジンサーバーの仮想ホスト設定と一致しているかどうかの確認

   • NGINX: server_name にオリジンホストとして設定されているドメイン名が含まれているかどうかを確認します。

   • Apache: <VirtualHost> で ServerName / ServerAlias を確認します。

   • IIS：IIS マネージャーで、対象の Web サイト > [バインド] を選択し、[ホスト名] フィールドがオリジンホストと一致しているかどうかを確認します。

2. CDN キャッシュのリフレッシュ

オリジンホスト設定を変更した後、キャッシュされたエラーレスポンスをクリアするために URL リフレッシュを実行します。

現象： Web サイトで "Too many redirects" または "ERR_TOO_MANY_REDIRECTS" というエラーが返されたり、画像、CSS ファイル、JavaScript ファイルなどのリソースの読み込みに失敗したりします。

原因： オリジンサーバーが強制的な HTTP から HTTPS へのリダイレクト (aaPanel、WAF、NGINX などのサービスにおける一般的なルール) を返す一方で、CDN のオリジンプロトコルは HTTP に設定されています。その結果、リクエストパスでループが形成されます：

クライアント → CDN → CDN が HTTP (ポート 80) 経由でオリジンフェッチを実行 → オリジンサーバーが HTTPS への 301 リダイレクトを返す → オリジンの 301/302 リダイレクトフォローが設定されていない場合、CDN は 301 をクライアントに返す → ブラウザが HTTPS へのリダイレクトに追従する → CDN 経由の HTTP でのオリジンフェッチが再度発生する → オリジンサーバーが別の 301 を返す → ...ブラウザは繰り返しリダイレクトし、最終的に ERR_TOO_MANY_REDIRECTS を報告します。オリジンの 301/302 リダイレクトフォローが有効になっている場合、CDN ノードはオリジンフェッチパスで繰り返しリダイレクトに追従し、追従回数の上限に達した後に 301 をユーザーに返します。これもループの原因となります。リダイレクトフォロー機能の詳細については、「301/302 リダイレクトの設定」をご参照ください。

解決策 (いずれかを選択)：

• 解決策 A：CDN が HTTPS を使用してオリジンフェッチを行うようにする。 前提条件：オリジンサーバーに有効な SSL 証明書があり、ポート 443 で正常にリッスンしていること。オリジンポートを 443 に変更し、オリジンプロトコルを HTTPS に設定します。オリジンサーバーが複数のドメイン名をリッスンしている場合は、オリジン SNI とオリジンホストも高速化ドメイン名またはオリジンドメイン名に設定します。

• 解決策 B：オリジンサーバーの強制リダイレクトを無効にし、HTTP 通信を維持する。 オリジンサーバーにログインし、HTTP を HTTPS に強制的にリダイレクトするルールを無効にします。CDN のオリジンプロトコルは HTTP、オリジンポートは 80 のままにします。CDN とオリジンサーバーのプロトコルが一致している限り、クライアントと CDN 間の接続は引き続き HTTPS を使用できます。

追加操作 (どちらの解決策を選択した場合でも推奨)： URL リフレッシュタスクを実行して、キャッシュされたリダイレクトレスポンスをクリアし、新しい設定をすぐに有効にします。設定を変更した後、その設定がネットワーク上のすべてのノードに反映されるまでには、通常数分かかります。この期間中、一部のノードは古いリダイレクトレスポンスを返し続ける可能性があります。さまざまなステータスコードに対する CDN のデフォルトのキャッシュポリシーについては、「HTTP ステータスコードの有効期限の設定」をご参照ください。

この項目は、オリジンホストまたはオリジン SNI の設定後にのみ リダイレクトループが発生するシナリオにのみ適用されます。設定前にリダイレクトループが発生していた場合は、前の項目「オリジンサーバーで HTTP から HTTPS へのリダイレクトを設定した後、CDN のオリジンフェッチ中にリダイレクトループ (ERR_TOO_MANY_REDIRECTS) が発生した場合の対処方法」をご参照ください。根本的な原因は依然として、オリジンサーバーで HTTP から HTTPS への強制リダイレクトが有効になっている一方で、CDN が HTTP 経由でオリジンフェッチを実行している点にあります。オリジンホストまたはオリジン SNI を変更すると、オリジンサーバーがリクエストを意図したサイトとして認識し、強制リダイレクトルールが適用されるようになるため、ループが発生します。次のようにトラブルシューティングを行います：

• オリジンサーバーで強制 HTTPS リダイレクトを無効にする： オリジンサーバーの管理コンソール (例えば、aaPanel) にログインし、HTTPS 設定に移動して、「Force HTTPS」または「HTTP to HTTPS redirect」オプションを無効にします。

• オリジンホストとオリジン SNI が一貫しており、正しいことを確認する： オリジン設定ページで、オリジンホストとオリジン SNI を正しいドメイン名 (通常はオリジンドメイン名) に設定し、2 つの値を一致させることで、オリジンフェッチリクエストがオリジンサーバーで正しく処理されるようにします。

• CDN キャッシュをリフレッシュする： 設定を調整した後、CDN キャッシュをリフレッシュして、キャッシュされたリダイレクトレスポンスをクリアします。

This error indicates that the access permission of the OSS bucket is private, and requests without a signature cannot read objects in the bucket. A private bucket provides access authentication and prevents unauthorized requests from consuming traffic. Therefore, we do not recommend changing the bucket to public read just to get rid of this error.

Solution: Enable the Configure origin fetch from a private OSS bucket feature for the accelerated domain name. After the feature is enabled, CDN automatically uses the service role AliyunCDNAccessingPrivateOSSRole to carry a signature when accessing the private bucket, and end users do not need additional signatures when accessing resources through CDN. Operation path: CDN console > Domain Management > target domain name > Origin Settings > Origin fetch from private OSS buckets.

If your OSS bucket is encrypted with Key Management Service (KMS), you must grant the CDN origin fetch role additional permissions to use the KMS key. Otherwise, CDN cannot decrypt and access these files, and the error This request is forbidden by kms. is returned.

Solution:

1. Log on to the RAM console. In the left-side navigation pane, choose Identities > Roles.

2. In the role list, find the AliyunCDNAccessingPrivateOSSRole role and click Grant Permission.

   説明

   If you cannot find the role, the origin fetch from private OSS buckets feature has never been enabled. First enable the feature as described in Configure origin fetch from a private OSS bucket. The role is created automatically. Then return to perform this step.

3. In the permission policy list, select System Policy, search for and add AliyunKMSCryptoUserAccess, and then click Grant permissions.

4. Use the Refresh and Prefetch feature. After the refresh task is complete, access the resource again.

This issue occurs when all of the following three conditions are met: the OSS bucket permission is private, OSS static website hosting is enabled, and Configure origin fetch from a private OSS bucket is enabled in CDN. When you access the root path of the accelerated domain name (for example, https://example.com/), a 403 Forbidden error is returned, and the response header contains x-tengine-error: You are forbidden to list buckets.

Cause: The origin fetch from private OSS buckets feature of CDN conflicts with the default homepage configuration of OSS static website hosting.

Solutions:

• Solution 1: If you do not need OSS static website hosting, disable the static website hosting configuration for the bucket. For instructions, see Static website hosting.

• Solution 2: If you need to keep static website hosting, configure a URI rewrite rule in CDN to prevent origin fetch requests that target the root directory: set [書き換えのパス] to ^/$, set [変更後のパス] to /index.html, and set [フラグ] to [Redirect]. After the rule is configured, when a client requests the root path, the CDN node returns a 302 redirect instructing the client to request /index.html. For detailed steps, see Rewrite access URLs.

症状： オリジンサーバーは、クライアントのデバイスタイプに基づいて対応するインターフェースを提供するために 302 リダイレクトを使用します。CDN を有効にすると、最初のユーザーがリソースにアクセスした際に 302 レスポンスがキャッシュされます。その後、他のデバイスタイプのユーザーが同じ URL にアクセスすると、最初のユーザー向けにキャッシュされた 302 ページが返されるため、デバイス適応機能が機能しなくなります。

解決策 A (推奨)：302 レスポンスをキャッシュしない。 最初にリクエストされた URL をキャッシュせず、302 リダイレクト後のページをキャッシュするように CDN を設定します。オリジンサーバーで初期ページをキャッシュしないように設定できます (オリジンサーバーのキャッシュなしポリシーは、CDN より優先されます)。そのページのレスポンスに次のいずれかのレスポンスヘッダーが含まれている場合、ページはキャッシュされません。

• Cache-control: no-cache、no-store

• Cache-control: max-age=0

• pragma: no-cache

• Cache-control: private

解決策 B：初期 URL をキャッシュしないように CDN を設定する。 オリジンサーバーのレスポンスヘッダーを変更できない場合は、ディレクトリとファイル名拡張子の CDN キャッシュ設定とその優先順位を組み合わせて、初期リダイレクト URL のキャッシュ時間を 0 に設定し、他の URL は通常どおりキャッシュされるようにします。

解決策 C：カスタムキャッシュキーを使用してデバイスタイプを区別する。 毎回オリジンフェッチするのではなく、キャッシュ機能を維持したい場合は、デバイスタイプをディメンションとして含むカスタムキャッシュキーを設定して、PC とモバイルデバイスがそれぞれ独立したキャッシュコピーを持つようにします。設定方法については、カスタムキャッシュキーをご参照ください。

考えられる原因は、オリジンサーバーのロジックが URL パラメーターや特定の Host ヘッダーに依存しているのに対し、CDN のデフォルト動作によってパラメーターが失われたり、Host ヘッダーが一致しなくなったりすることです。次のようにトラブルシューティングします。

1. キャッシュルールの URL パラメーター設定を確認する：オリジンサーバーがリダイレクトやロジックで URL パラメーターに依存している場合は、CDN の「パラメーターを無視」機能に注意してください。「パラメーターを無視」はキャッシュキーにのみ影響します。オリジンフェッチリクエストは、依然として完全な URL パラメーターを送信します。したがって、問題は「パラメーターが失われたためオリジンサーバーがリクエストを処理できない」のではなく、「異なるパラメーターを持つリクエストが同じキャッシュにヒットし、現在のパラメーターに対応しないコンテンツを受信する」ことです。「パラメーターを無視」を無効にするか、ビジネスロジックに影響を与えるパラメーターを保持して、異なるパラメーターを持つリクエストが独立してキャッシュされるようにすることを推奨します (パラメーターを無視をご参照ください)。

2. オリジンホストをオリジンサーバーが期待するドメイン名に設定する：これにより、オリジンサーバーがリクエストの Host ヘッダーを正しく識別し、リダイレクトロジックを処理できるようになります。

3. ディレクトリ更新または URL 更新タスクを実行する：設定を変更した後、ディレクトリ更新または URL 更新タスクを実行して、新しい設定を適用します。

症状： 大容量ファイルのダウンロードが中断される、レジュームダウンロードが失敗する、またはシーク再生でエラーが発生するか、最初から再生が始まります。

原因： Range オリジンフェッチを有効にすると、CDN ノードは Range ヘッダーを含むスライスリクエストをオリジンサーバーに送信します。オリジンサーバーが Range リクエストをサポートしていない場合 (Range ヘッダーを無視して 200 OK と完全なコンテンツを返す)、または返された Content-Range がリクエストされた範囲と一致しない場合、キャッシュの例外やクライアントリクエストの失敗が発生する可能性があります。

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

1. オリジンサーバーが Range リクエストをサポートしているかどうかを確認する：curl -I -H "Range: bytes=0-1023" http(s)://origin-domain/resource-path を実行します。正しい Content-Range ヘッダーとともに 206 Partial Content が返された場合、オリジンサーバーは Range をサポートしています。完全なファイルとともに 200 OK が返された場合、オリジンサーバーは Range リクエストを無視しています。

2. オリジンサーバーの機能に基づいて Range オリジンフェッチ設定を調整する：オリジンサーバーが Range をサポートしていない場合は、まずオリジンサーバーを変更して 206 Partial Content で正しく応答するようにするか、CDN の Range オリジンフェッチ機能を無効にし、CDN がオリジンサーバーで処理できないスライスリクエストを送信しないようにします。設定パス：CDN コンソール > [ドメイン管理] > 対象ドメイン名 > [ビデオ設定] > [Range オリジンフェッチ]。このスイッチはデフォルトで無効になっています。詳細については、「Range オリジンフェッチの設定」をご参照ください。

3. オリジンサーバーのレスポンスヘッダーが安定しているかどうかを確認する：Range オリジンフェッチでは、オリジンサーバーが同じリソースに対して安定した Content-Length、ETag、および Last-Modified を返す必要があります。これにより、CDN はスライスが同じバージョンのファイルに属していることを確認できます。オリジンサーバーがコンテンツを動的に生成し、これらのレスポンスヘッダーを提供できない場合、Range オリジンフェッチは信頼できません。

4. キャッシュされたスライスがクリアされているかどうかを確認する：Range オリジンフェッチを使用している場合、CDN ノードがオリジンサーバーから 206 以外のステータスコードを受信すると、キャッシュされたスライスファイルを削除します (オリジンフェッチタイムアウトでは削除されません)。したがって、オリジンサーバーが断続的に 5xx レスポンスを返す場合、キャッシュされたスライスが繰り返しクリアされます。これにより、ダウンロードが繰り返し中断されたり、オリジンフェッチトラフィックが異常に高くなったりします。詳細については、「HTTPステータスコードの有効期限の設定」をご参照ください。

症状

CDN 経由でアクセスすると、ページが文字化けしたり、ブラウザがデコードの失敗を報告したりします (ERR_CONTENT_DECODING_FAILED)。

原因

• オリジンサーバーが Content-Encoding レスポンスヘッダーを設定せずに圧縮済みのコンテンツ (gzip/br) を返します。CDN は、すでに圧縮済みのコンテンツを再度圧縮してから返すため、クライアントでデコード例外が発生します。

• オリジンサーバーが申告した Content-Encoding が実際のエンコーディングと一致していません。

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

1. オリジンサーバーと CDN のレスポンスヘッダーを比較する

# オリジンサーバーへの直接アクセス
curl -I -H "Accept-Encoding: gzip" https://<origin-domain>/<resource-path>

# CDN経由でのアクセス
curl -I -H "Accept-Encoding: gzip" https://<accelerated-domain>/<resource-path>

Content-Encoding、Content-Length、および Content-Type が両者で一致しているかを確認します。

2. CDN のインテリジェント圧縮設定を確認する

オリジンサーバーがすでに圧縮済みのコンテンツを返している場合 (レスポンスヘッダーに Content-Encoding: gzip が含まれている)、CDN は再度圧縮すべきではありません。二重圧縮が発生した場合は、CDN コンソールで「インテリジェント圧縮」が有効になっているかどうかを確認するか、CDN 側で圧縮を無効にして、オリジンサーバーに圧縮を完全に処理させます。

3. オリジンサーバーのレスポンスヘッダーを修正する

オリジンサーバーが圧縮済みのコンテンツを返す際は、常に正しい Content-Encoding ヘッダーも設定するようにしてください。そうしないと、CDN はコンテンツがすでに圧縮済みであることを識別できません。

症状

異なるユーザーが同じページにアクセスすると、あるユーザーが別のユーザーのセッション情報を受信する (ログイン状態が混在するなど)、またはログイン後すぐにログイン状態が期限切れになります。

原因

オリジンサーバーが動的ページのレスポンスで Set-Cookie ヘッダーを返します。このレスポンスが CDN によってキャッシュされると、キャッシュにヒットした他のユーザーが、自分のものではない Cookie を受信するため、セッション情報が混在します。

解決策

1. Set-Cookie を含むレスポンスをキャッシュしないようにオリジンサーバーを設定する

オリジンサーバーの動的ページに Cache-Control: no-store または Cache-Control: private を追加し、CDN がユーザー固有の情報を含むレスポンスをキャッシュしないようにします。

2. CDN 側でキャッシュルールを設定する

CDN コンソールで、動的ページ (.php、.jsp、または /api/ パスなど) に対して「キャッシュしない」ルールを設定し、これらのリクエストが常にオリジンサーバーに到達するようにします。

3. CDN の「インバウンドレスポンスヘッダーの変更」機能を使用してレスポンスヘッダーを削除する

Set-Cookie が CDN のキャッシュシナリオにおいて無意味であることを確認した場合 (トラッキング Cookie など)、CDN 側で「インバウンドレスポンスヘッダーの変更」機能を設定して、キャッシュする前に Set-Cookie レスポンスヘッダーを削除できます。この操作がビジネスロジックに影響しないことを確認してください。