# CloudFront でのエラーレスポンスステータスコードのトラブルシューティング
CloudFront からオリジンにオブジェクトをリクエストし、オリジンから HTTP 4xx または 5xx ステータスコードが返された場合は、CloudFront とオリジンとの間に通信の問題があります。
このトピックには、Lambda@Edge または CloudFront Functions を使用する場合の、これらのステータスコードのトラブルシューティング手順も記載されています。
以降のトピックでは、このようなエラーレスポンスの背後にある潜在的な原因の詳細な説明と、根本的な問題を診断して解決する方法に関するステップバイステップのガイダンスを提供します。
**Topics**
+ [HTTP 400 ステータスコード (Bad Request)](http-400-bad-request.md)
+ [HTTP 401 ステータスコード (Unauthorized)](http-401-unauthorized.md)
+ [HTTP 403 ステータスコード (無効なメソッド)](http-403-invalid-method.md)
+ [HTTP 403 ステータスコード (Permission Denied)](http-403-permission-denied.md)
+ [HTTP 404 ステータスコード (Not Found)](http-404-not-found.md)
+ [HTTP 412 ステータスコード (Precondition Failed)](http-412-precondition-failed.md)
+ [HTTP 500 ステータスコード (Internal Server Error)](http-500-internal-server-error.md)
+ [HTTP 502 ステータスコード (Bad Gateway)](http-502-bad-gateway.md)
+ [HTTP 503 ステータスコード (Service Unavailable)](http-503-service-unavailable.md)
+ [HTTP 504 ステータスコード (Gateway Timeout)](http-504-gateway-timeout.md)
# HTTP 400 ステータスコード (Bad Request)
CloudFront は、ペイロードまたはパラメータのコンテンツが欠落していたり、適正でないなど、クライアントがリクエストで無効なデータを送信すると、400 bad request エラーを返します。これは、一般的なクライアントエラーである場合もあります。
## Amazon S3 オリジンが 400 エラーを返す場合
CloudFront ディストリビューションで Amazon S3 オリジンを使用している場合、ディストリビューションが HTTP ステータス コード 400 Bad Request と次のようなメッセージのエラー応答を送信することがあります。
*The authorization header is malformed; the region '**' is wrong; expecting '**'*
次に例を示します。
*認可ヘッダーの形式が正しくありません。リージョン 'us-east-1' が間違っています。'us-west-2' を予期しています。*
この問題は、次のシナリオで発生する可能性があります。
1. CloudFront ディストリビューションのオリジンが Amazon S3 バケットである。
1. S3 バケットを 1 つの AWS リージョンから別のリージョンに移動した。つまり、S3 バケットを削除し、後ほど同じバケット名で新しい S3 バケットを作成したが、元の S3 バケットがあった AWS リージョンとはちがうリージョンで作成したということです。
このエラーを修正するには、S3 バケットを現在の AWS リージョンで検索するように CloudFront ディストリビューションを更新します。
**CloudFront ディストリビューションを更新するには**
1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。
1. このエラーを生成するディストリビューションを選択します。
1. [**Origin and Origin Groups (オリジンおよびオリジングループ)**] を選択します。
1. 移動した S3 バケットのオリジンを見つけます。このオリジンの横にあるチェックボックスをオンにして、[**編集**] を選択します。
1. [**Yes, Edit (はい、編集します)**] を選択します。[**Yes, Edit (はい、編集します)**] を選択する前に、設定を変更する必要はありません。
これらのステップを完了すると、CloudFront によりディストリビューションが再デプロイされます。ディストリビューションのデプロイ中は、**[最終変更日]** 列にステータスが **[デプロイ中]** と表示されます。デプロイの完了後、しばらくすると、`AuthorizationHeaderMalformed` エラーレスポンスを受信しなくなるはずです。
## Application Load Balancer オリジンが 400 エラーを返す場合
CloudFront ディストリビューションで Application Load Balancer オリジンを使用している場合、400 エラーが返される原因の可能性は以下のとおりです。
+ クライアントが HTTP 仕様を満たさない誤った形式のリクエストを送信した。
+ リクエストヘッダーのサイズが、リクエスト行あたり 16 K、単一のヘッダーあたり 16 K、またはリクエストヘッダー全体で 64 K を超えている。
+ クライアントが、リクエスト本文全体を送信する前に接続を閉じた。
# HTTP 401 ステータスコード (Unauthorized)
401 Unauthorized レスポンスステータスコードは、リクエストしたリソースに対する有効な認証情報がないことが原因でクライアントのリクエストが完了していないことを意味します。このステータスコードは、ユーザーに認証情報を要求した後、クライアントがリソースを再度リクエストする方法に関する情報を含む HTTP `WWW-Authenticate` レスポンスヘッダーとともに送信されます。詳細については、「[401 Unauthorized](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401)」を参照してください。
CloudFront では、オリジンがリクエストを認証するために `Authorization` ヘッダーを想定している場合、CloudFront は 401 Unauthorized エラーを回避するために `Authorization` ヘッダーをオリジンに転送する必要があります。ビューワーリクエストをオリジンに転送する際、CloudFront はデフォルトで一部のビューワーヘッダー (`Authorization` ヘッダーを含む) を削除します。オリジンがオリジンリクエストの `Authorization` ヘッダーを常に受け取るようにするには、次のオプションがあります。
+ キャッシュポリシーを使用して、`Authorization` ヘッダーをキャッシュキーに追加します。キャッシュキー内のすべてのヘッダーは、オリジンリクエストに自動的に含まれます。詳細については、「[ポリシーを使用してキャッシュキーを制御する](controlling-the-cache-key.md)」を参照してください。
+ オリジンリクエストポリシーを使用し、すべてのビューワーヘッダーをオリジンに転送します。オリジンリクエストポリシーで `Authorization` ヘッダーを個別に転送することはできません。ただし、ビューワーヘッダーをすべて転送する場合、CloudFront は `Authorization` ヘッダーをビューワーリクエストに含めます。CloudFront は、このようなユースケースでマネージド `AllViewer` オリジンリクエストポリシーを提供します。詳細については、「[マネージドオリジンリクエストポリシーを使用する](using-managed-origin-request-policies.md)」を参照してください。
詳細については、[「認証ヘッダーをオリジンに転送するように CloudFront を設定する方法を教えてください](https://repost.aws/knowledge-center/cloudfront-authorization-header)」を参照してください。
# HTTP 403 ステータスコード (無効なメソッド)
CloudFront ディストリビューションで指定していない HTTP メソッドを使用しようとすると、CloudFront は 403 (Invalid method) エラーを返します。ディストリビューションでは、以下のオプションのいずれかを指定できます。
+ CloudFront は `GET` および `HEAD` リクエストのみを転送します。
+ CloudFront は `GET`、`HEAD`、および `OPTIONS` リクエストのみを転送します。
+ CloudFront は、`GET`、`HEAD`、`OPTIONS`、`PUT`、`PATCH`、`POST`、`DELETE` リクエストを転送します。(このオプションを選択した場合、望ましくない操作がユーザーによって実行されないように、Amazon S3 バケットまたはカスタムオリジンへのアクセスの制限が必要になる場合があります)。たとえば、オリジンからオブジェクトを削除する権限をユーザーに付与しないようにする場合などです。
# HTTP 403 ステータスコード (Permission Denied)
HTTP 403 エラーは、リクエストされたリソースに対してクライアントにアクセス権限がないことを意味します。クライアントはリクエストを把握していても、ビューワーアクセスを承認できません。CloudFront がこのステータスコードを返す一般的な原因は、以下のとおりです。
**Topics**
+ [代替 CNAME の設定が適切でない](#alternate-cname-incorrectly-configured)
+ [CloudFront ディストリビューションまたはオリジンで AWS WAF が設定されている場合](#aws-waf-configured-on-distribution-origin)
+ [カスタムオリジンが 403 エラーを返す場合](#custom-origin-returning-403)
+ [Amazon S3 オリジンが 403 エラーを返す場合](#s3-origin-403-error)
+ [地理的制限が 403 エラーを返す場合](#geolocation-403)
+ [署名付き URL または署名付き Cookie 設定が 403 エラーを返す場合](#signed-URLs-cookies-403)
+ [スタックディストリビューションが 403 エラーを引き起こす場合](#stacked-distributions-403)
## 代替 CNAME の設定が適切でない
ディストリビューションで適正な CNAME が指定されていることを確認します。デフォルトの CloudFront URL の代わりに代替 CNAME を使用するには、以下を実行します。
1. CNAME が CloudFront ディストリビューション URL をポイントするように、DNS に CNAME レコードを作成します。
1. CloudFront ディストリビューション設定に、この CNAME を追加します。
DNS レコードを作成しても、CloudFront ディストリビューション設定に CNAME を追加しないと、リクエストは 403 エラーを返します。カスタム CNAME の設定の詳細については、「[代替ドメイン名 (CNAME) を追加することによって、カスタム URL を使用する](CNAMEs.md)」を参照してください。
## CloudFront ディストリビューションまたはオリジンで AWS WAF が設定されている場合
AWS WAF がクライアントと CloudFront の間に配置されている場合、CloudFront はオリジンから返される 403 エラーコードと、リクエストがブロックされた際に AWS WAF から返される 403 エラーコードを区別できません。
403 ステータスコードのソースを検索するには、AWS WAF ウェブアクセスコントロールリスト (ACL) ルールでブロックされたリクエストを確認します。詳細については、以下の各トピックを参照してください。
+ [AWS WAF ウェブアクセスコントロールリスト (ウェブ ACL)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)
+ [AWS WAF 保護のテストと調整](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)
## カスタムオリジンが 403 エラーを返す場合
カスタムオリジンを使用していて、オリジンにカスタムファイアウォール設定があると、403 エラーが返される場合があります。トラブルシューティングを行うには、オリジンに直接リクエストを行います。CloudFront を使用せずにエラーをレプリケートできる場合、オリジンが 403 エラーの原因です。
カスタムオリジンがエラーの原因である場合は、オリジンログを調べて、エラーの原因となっている可能性がある要因を特定します。詳細については、以下のトラブルシューティングトピックを参照してください。
+ [API ゲートウェイからの HTTP 403 エラーをトラブルシューティングする方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-troubleshoot-403-forbidden/ )
+ [Application Load Balancer の HTTP 403 forbidden エラーのトラブルシューティング方法を教えてください。](https://repost.aws/knowledge-center/alb-http-403-error)
## Amazon S3 オリジンが 403 エラーを返す場合
403 エラーが発生する理由:
+ CloudFront に Amazon S3 バケットへのアクセス権限がない。これは、オリジンアクセスアイデンティティ (OAI) またはオリジンアクセスコントロール (OAC) がディストリビューションに対して有効になっておらず、バケットがプライベートである場合に発生する可能性がある。
+ リクエストされた URL で指定されたパスが正しくない。
+ リクエストされたオブジェクトが存在しない。
+ ホストヘッダーが REST API エンドポイントで転送された。詳細については、「Amazon Simple Storage Service ユーザーガイド」の「[HTTP ホストヘッダーバケットの仕様](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#VirtualHostingSpecifyBucket)」を参照してください。**
+ カスタムエラーページを設定している。詳細については、「[カスタムエラーページが設定されている場合に CloudFront がエラーを処理する方法](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages)」を参照してください。
## 地理的制限が 403 エラーを返す場合
地理的制限 (ジオブロッキングとも呼ばれる) を使用すると、CloudFront ディストリビューションを介して配信しているコンテンツに対して特定の地域のユーザーのアクセスを阻止することができます。
詳細については、「[コンテンツの地理的配分を制限する](georestrictions.md)」を参照してください。
## 署名付き URL または署名付き Cookie 設定が 403 エラーを返す場合
ディストリビューションの動作設定で **[ビューワーのアクセスを制限する]** を有効にした場合、署名付き Cookie または署名付き URL を使用しないリクエストは 403 エラーになります。詳細については、以下の各トピックを参照してください。
+ [署名付き URL と署名付き Cookie を使用したプライベートコンテンツを提供する](PrivateContent.md)
+ [CloudFront の署名付き URL または署名付き Cookie に関連する問題をトラブルシューティングする方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-troubleshoot-signed-url-cookies/)
## スタックディストリビューションが 403 エラーを引き起こす場合
オリジンエンドポイントへのリクエストチェーン内に複数のディストリビューションがある場合、CloudFront は 403 エラーを返します。あるディストリビューションを別のディストリビューションの前に配置することはお勧めしません。
# HTTP 404 ステータスコード (Not Found)
CloudFront は、クライアントが存在しないリソースにアクセスしようとすると、404 (Not Found) エラーを返します。CloudFront ディストリビューションでこのエラーが発生した場合の一般的な原因は、以下のとおりです。
+ リソースが存在しません。
+ URL が適正でありません。
+ カスタムオリジンが 404 エラーを返しています。
+ カスタムエラーページが 404 エラーを返しています。(エラーコードがすべて 404 に変換されている可能性があります)。詳細については、「[カスタムエラーページが設定されている場合に CloudFront がエラーを処理する方法](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages)」を参照してください。
+ カスタムエラーページが誤って削除されたため、リクエストが削除されたカスタムエラーページを検索して、404 エラーを発生させています。詳細については、「[カスタムエラーページが設定されていない場合に CloudFront がエラーを処理する方法](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages)」を参照してください。
+ オリジンパスが適正でありません。オリジンパスが入力されている場合、リクエストがオリジンに転送される前に、その値がブラウザからの各リクエストのパスの末尾に追加されます。詳細については、「[オリジンのパス](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath)」を参照してください。
# HTTP 412 ステータスコード (Precondition Failed)
ターゲットリソースへのアクセスが拒否されると、CloudFront は 412 (Precondition Failed) エラーコードを返します。場合によっては、特定の条件が満たされた後にのみリクエストを受け入れるようにサーバーが設定されています。指定した条件のいずれかが満たされない場合、サーバーはクライアントに指定されたリソースへのアクセスを許可しません。代わりに、サーバーは 412 エラーコードで応答します。
CloudFront での 412 エラーの一般的な原因:
+ `If-Unmodified-Since` または `If-None-Match` ヘッダーで定義された条件ば満たされない場合の `GET` または `HEAD` 以外のメソッドに対する条件的リクエストである場合。この場合、通常はリソースのアップロードまたは変更であるリクエストを実行することはできません。
+ CloudFront [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) API オペレーション内の単数または複数のリクエストフィールドの条件が false と評価される場合。
# HTTP 500 ステータスコード (Internal Server Error)
HTTP 500 ステータスコード (Internal Server Error) は、サーバーが予期しない状況に直面して、リクエストを処理できなかったことを意味します。Amazon CloudFront の 500 エラーの一般的な原因は、以下のとおりです。
**Topics**
+ [オリジンサーバーが CloudFront に 500 エラーを返す場合](#origin-server-500-error)
## オリジンサーバーが CloudFront に 500 エラーを返す場合
オリジンサーバーが、CloudFront に 500 エラーを返す場合があります。詳細については、以降のトラブルシューティングに関するトピックを参照してください。
+ **Amazon S3 が 500 エラーを返す場合**は、「[Amazon S3 の HTTP 500 または 503 エラーをトラブルシューティングする方法を教えてください。](https://repost.aws/knowledge-center/http-5xx-errors-s3)」を参照してください。
+ **API Gateway が 500 エラーを返す場合**は、「[API Gateway の 5xx エラーをトラブルシューティングする方法を教えてください。](https://repost.aws/knowledge-center/api-gateway-5xx-error)」を参照してください。
+ **Elastic Load Balancing が 500 エラーを返す場合**は、「Application Load Balancer ユーザーガイド」の「[HTTP 500: Internal server error](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-500-issues)」を参照してください。**
上記のリストで 500 エラーが解決されない場合、CloudFront の Point of Presence が内部サーバーエラーを返している可能性があります。ヘルプについては、[サポート](https://console.aws.amazon.com/support/home#/) にお問い合わせください。
# HTTP 502 ステータスコード (Bad Gateway)
CloudFront は、オリジンサーバーに接続できなかったために、リクエストされたオブジェクトを提供できなかった場合に、HTTP 502 ステータス コード (Bad Gateway) を返します。
Lambda@Edge を使用している場合、問題は Lambda 検証エラーである可能性があります。HTTP 502 エラーとして `NonS3OriginDnsError` エラーコードが返された場合、DNS 設定の問題が原因で CloudFront がオリジンに接続できない可能性があります。
**Topics**
+ [CloudFront とカスタムオリジンサーバー間の SSL/TLS ネゴシエーションエラー](#ssl-negotitation-failure)
+ [サポートされている暗号化/プロトコルではオリジンが応答しません](#origin-not-responding-with-supported-ciphers-protocols)
+ [オリジンの SSL/TLS 証明書が期限切れ、無効、自己署名になっている、または間違った順番の証明書チェーンになっている](#ssl-certificate-expired)
+ [オリジンがオリジン設定のポート指定に応答しません](#origin-not-responding-on-specified-ports)
+ [Lambda 検証エラー](#http-502-lambda-validation-error)
+ [CloudFront Functions の検証エラー](#http-502-cloudfront-function-validation-error)
+ [DNS エラー (`NonS3OriginDnsError`)](#http-502-dns-error)
+ [Application Load Balancer オリジン 502 エラー](#cloudfront-alb-502-error)
+ [API Gateway オリジン 502 エラー](#cloudfront-api-gateway-502-error)
## CloudFront とカスタムオリジンサーバー間の SSL/TLS ネゴシエーションエラー
CloudFront とオリジンの間で HTTPS を必要とするカスタムオリジンを使用すると、ドメイン名が一致しない場合にエラーが発生する可能性があります。オリジンの SSL/TLS 証明書には、CloudFront ディストリビューションに指定した **[オリジンドメイン]** またはオリジンリクエストの `Host` ヘッダーのいずれかに一致するドメイン名が含まれている必要があります。**
ドメイン名が一致しない場合、SSL/TLS ハンドシェイクは失敗し、CloudFront は HTTP 502 ステータスコード (Bad Gateway) を返し、`X-Cache` ヘッダーを `Error from cloudfront` に設定します。
証明書のドメイン名がディストリビューションまたは `Host` ヘッダーの **[オリジンドメイン]** と一致するかどうかを確認するには、オンライン SSL チェッカーまたは OpenSSL を使用できます。ドメイン名が一致しない場合、2 つのオプションがあります。
+ 該当するドメイン名を含む新しい SSL/TLS 証明書を取得します。
AWS Certificate Manager (ACM) を使用する場合は、AWS Certificate Manager ユーザーガイド**の「[パブリック証明書をリクエストする](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html)」を参照して、新しい証明書をリクエストしてください。
+ CloudFront で SSL を使用してオリジンに接続しないように、ディストリビューション設定を変更します。
### オンライン SSL チェッカー
SSL テスト ツールを見つけるには、インターネットで「online ssl checker」を検索します。通常、ドメイン名を指定すると、ツールから SSL/TLS 証明書に関するさまざまな情報が返されます。証明書の [**Common Names**] フィールドまたは [**Subject Alternative Names**] フィールドにドメイン名が含まれていることを確認します。
### OpenSSL
CloudFront からの HTTP 502 エラーをトラブルシューティングするには、OpenSSL を使用してオリジンサーバーへの SSL/TLS 接続を試行します。OpenSSL が接続できない場合、オリジンサーバーの SSL/TLS 設定に問題がある可能性があります。OpenSSL が接続を確立できる場合、証明書の共通名 (`Subject CN` フィールド) やサブジェクト代替名 (`Subject Alternative Name` フィールド) など、オリジンサーバーの証明書に関する情報を返します。
次の OpenSSL コマンドを使用して、オリジンサーバーへの接続をテストします (*[オリジンドメイン]* を example.com などのオリジンサーバーのドメイン名に置き換えます)。
`openssl s_client -connect origin domain name:443`
次のことが当てはまるとします。
+ オリジンサーバーは、複数の SSL/TLS 証明書を持つ複数のドメイン名をサポートしている
+ `Host` ヘッダーをオリジンに転送するようにディストリビューションが設定されている
この場合、次の例のように OpenSSL コマンドに `-servername` オプションを追加します (*CNAME* をディストリビューションで設定した CNAME に置き換えます)。
`openssl s_client -connect origin domain name:443 -servername CNAME`
## サポートされている暗号化/プロトコルではオリジンが応答しません
CloudFront は暗号とプロトコルを使用してオリジンサーバーに接続します。CloudFront がサポートする暗号とプロトコルのリストについては、「[CloudFront とオリジンとの間でサポートされているプロトコルと暗号](secure-connections-supported-ciphers-cloudfront-to-origin.md)」を参照してください。オリジンが SSL/TLS 交換でこれらの暗号またはプロトコルに応答しない場合、CloudFront は接続を確立できません。[SSL Labs](https://www.ssllabs.com/ssltest) などのオンラインツールを使って、オリジンが暗号とプロトコルをサポートすることを確認できます。**[Host Name]** フィールドでオリジンのドメイン名を入力し、**[Submit]** を選択します。テスト結果の [**Common names**] フィールドと [**Alternative names**] フィールドを見て、オリジンのドメイン名と一致しているかどうかを確認します。テスト完了後、テスト結果の [**Protocols**] または [**Cipher Suites**] セクションでオリジンがサポートする暗号とプロトコルを確認してください。それらを「[CloudFront とオリジンとの間でサポートされているプロトコルと暗号](secure-connections-supported-ciphers-cloudfront-to-origin.md)」のリストと比較します。
## オリジンの SSL/TLS 証明書が期限切れ、無効、自己署名になっている、または間違った順番の証明書チェーンになっている
オリジンサーバーから、CloudFront が TCP 接続を中断する、HTTP ステータスコード 502 (Bad Gateway) を返す、`X-Cache` ヘッダーを `Error from cloudfront` に設定するなどのレスポンスがある場合:
+ 証明書が期限切れです
+ 証明書が無効です
+ 証明書が自己署名です
+ 間違った順番の証明書チェーンです
**注記**
中間証明書を含む、証明書チェーンが完全でない場合も、CloudFront は TCP 接続を中断します。
カスタムオリジンサーバーで SSL/TLS 証明書をインストールする方法の詳細については、「[CloudFront とカスタムオリジンの間の通信に HTTPS を要求する](using-https-cloudfront-to-custom-origin.md)」を参照してください。
## オリジンがオリジン設定のポート指定に応答しません
CloudFront ディストリビューションでオリジンを作成するときに、HTTP および HTTPS トラフィックのために CloudFront がオリジンへの接続に使用するポートを設定できます。デフォルトでは TCP 80/443です。これらのポートは変更可能です。これらのポートで、オリジンが何らかの理由でトラフィックを拒否している場合やバックエンドサーバーが応答していない場合、CloudFront は接続に失敗します。
これらの問題におけるトラブルシューティングには、インフラストラクチャで稼動するファイアウォールを確認し、サポートする IP 範囲がブロックされていないかを確認します。詳細については、「Amazon VPC ユーザーガイド」の「[AWS IP アドレスの範囲](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html)」を参照してください。**ウェブサーバーがオリジンで稼働中であるかどうかも確認してください。
## Lambda 検証エラー
Lambda@Edge を使用している場合、HTTP 502 ステータスコードは、Lambda 関数のレスポンスの形式が正しくないか、レスポンスに無効なコンテンツが含まれていたことを示している可能性があります。Lambda@Edge エラーのトラブルシューティングの詳細については、「[Lambda@Edge 関数をテストおよびデバッグする](lambda-edge-testing-debugging.md)」を参照してください。
## CloudFront Functions の検証エラー
CloudFront Functions を使用している場合、HTTP 502 ステータスコードは、CloudFront Functions が読み取り専用ヘッダーを追加、削除、または変更しようとしていることを示している場合があります。このエラーは、テスト中は表示されませんが、関数をデプロイしてリクエストを実行した後に表示されます。このエラーを解決するには、CloudFront Functions を確認して更新します。詳細については、「[関数を更新する](update-function.md)」を参照してください。
## DNS エラー (`NonS3OriginDnsError`)
`NonS3OriginDnsError` エラーコードを含む HTTP 502 エラーは、CloudFront がオリジンに接続できないという、DNS 設定の問題があることを示しています。このエラーが CloudFront で発生した場合は、オリジンの DNS 設定が正常に機能していることを確認してください。
CloudFront は、期限切れのオブジェクトや、キャッシュに保存されていないオブジェクトをリクエストされると、オリジンにリクエストしてオブジェクトを取得しようとします。オリジンに対して正常なリクエストを行うため、CloudFront はオリジンドメインで DNS 解決を実行します。ドメインの DNS サービスで問題が発生している場合、CloudFront はドメイン名を解決して IP アドレスを取得できないため、HTTP 502 エラー (`NonS3OriginDnsError`) が発生します。この問題を解決するには、DNS プロバイダーにお問い合わせください。Amazon Route 53 を使用している場合は、「[Route 53 DNS サービスを使用している自分のウェブサイトにアクセスできないのはなぜですか?](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-dns-website-unreachable/)」を参照してください。
この問題の詳しいトラブルシューティングを行うには、オリジンのルートドメインまたは zone apex (`example.com` など) の[権威ネームサーバー](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-authoritative-name-server)が正しく機能していることを確認します。[dig](https://en.wikipedia.org/wiki/Dig_(command)) や [nslookup](https://en.wikipedia.org/wiki/Nslookup) などのツールにより、次のコマンドを使用して apex オリジンのネームサーバーを検索できます。
```
dig OriginAPEXDomainName NS +short
```
```
nslookup -query=NS OriginAPEXDomainName
```
ネームサーバーの名前がある場合、次のコマンドを使用して、それらに対してオリジンのドメイン名のクエリを実行し、各サーバーが応答して答えを返すことを確認します。
```
dig OriginDomainName @NameServer
```
```
nslookup OriginDomainName NameServer
```
**重要**
この DNS トラブルシューティングは、公共のインターネットに接続しているコンピュータを使用して実行してください。CloudFront はインターネット上のパブリック DNS を使用してオリジンドメインを解決するため、同様の状況でトラブルシューティングを行うことが重要です。
オリジンがサブドメインであり、このサブドメインの DNS 権限がルートドメインとは異なるネームサーバーに委任されている場合は、ネームサーバー (`NS`) および Start of Authority (`SOA`) レコードが、このサブドメインに対して正しく設定されていることを確認してください。これらのレコードは、前述の例と同様のコマンドを使用して確認できます。
DNS の詳細については、Amazon Route 53 ドキュメントの「[ドメインネームシステム (DNS) の概念](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-domain-name-system-dns)」を参照してください。
## Application Load Balancer オリジン 502 エラー
Application Load Balancer をオリジンとして使用して 502 エラーが発生した場合は、「[Application Load Balancerの HTTP 502 エラーのトラブルシューティング方法を教えてください](https://repost.aws/knowledge-center/elb-alb-troubleshoot-502-errors)」を参照してください。
## API Gateway オリジン 502 エラー
API Gateway を使用していて 502 エラーが発生した場合は、「[Lambda プロキシ統合を使用して API Gateway REST API からの HTTP 502 エラーを解決するにはどうすればよいですか?](https://repost.aws/knowledge-center/malformed-502-api-gateway)」を参照してください。
# HTTP 503 ステータスコード (Service Unavailable)
通常、HTTP 503 ステータスコード (Service Unavailable) は、オリジンサーバーのパフォーマンスの問題を示します。まれに、エッジロケーションでリソースが制限されているため、CloudFront が一時的にリクエストを満たせないことを示している場合もあります。
Lambda@Edge または CloudFront Functions を使用している場合、実行エラーまたは Lambda@Edge の制限超過エラーが原因である可能性があります。
**Topics**
+ [オリジンサーバーにリクエスト率をサポートする十分な容量がない](#http-503-service-unavailable-not-enough-origin-capacity)
+ [エッジロケーションのリソースが制限されているために CloudFront でエラーが発生した](#http-503-service-unavailable-limited-resources-at-edge-location)
+ [Lambda@Edge または CloudFront Functions の実行エラー](#http-503-lambda-execution-error)
+ [Lambda@Edge の制限超過](#http-503-lambda-limit-exceeded-error)
## オリジンサーバーにリクエスト率をサポートする十分な容量がない
オリジンサーバーが利用できないか、受信リクエストを処理できない場合は、HTTP 503 ステータスコード (Service Unavailable) が返されます。この場合、CloudFront はエラーをユーザーに中継します。この問題を解決するには、以下の手順をお試しください。
+ **Amazon S3 をオリジンサーバーとして使用している場合**:
+ パーティショニングされた Amazon S3 プレフィックスごとに毎秒 3,500 件の PUT/COPY/POST/DELETE リクエストまたは 5,500 件の GET/HEAD リクエストを送信できます。Amazon S3 から 503 Slow Down レスポンスが返された場合は、通常、特定の Amazon S3 プレフィックスに対するリクエストレートが過剰であることを示しています。
リクエストレートは S3 バケットのプレフィックスごとに適用されるため、オブジェクトは複数のプレフィックスに分散する必要があります。プレフィックスに対するリクエストレートが徐々に増えると、Amazon S3 はスケールアップして各プレフィックスのリクエストを個別に処理します。その結果、バケットが処理する全体的なリクエストレートは、プレフィックス数の倍数になります。
+ 詳細については、Amazon Simple Storage Service ユーザーガイド**の「[Amazon S3 のパフォーマンスの最適化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)」を参照してください。
+ **Elastic Load Balancing をオリジンサーバーとして使用している場合**:
+ バックエンドインスタンスがヘルスチェックに応答できることを確認します。
+ ロードバランサーとバックエンドインスタンスが負荷を処理できることを確認します。
詳細については、以下を参照してください。
+ [Classic Load Balancer の使用中に返される 503 エラーをトラブルシューティングするにはどうしたらよいですか?](https://repost.aws/knowledge-center/503-error-classic)
+ [Application Load Balancer からの 503 (サービス利用不可) エラーのトラブルシューティング方法を教えてください。](https://repost.aws/knowledge-center/alb-troubleshoot-503-errors)
+ **カスタムオリジンを使用している場合**:
+ アプリケーションログを調べて、オリジンのメモリ、CPU、ディスクサイズなどのリソースが十分であることを確認します。
+ Amazon EC2 をバックエンドとして使用している場合は、受信されるリクエストを満たす適切なリソースがインスタンスタイプにあることを確認します。詳細については、*Amazon EC2 ユーザーガイド*の「[インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。
+ **API Gateway を使用している場合**:
+ API Gateway API がレスポンスを受信できない場合、このエラーはバックエンド統合に関連しています。バックエンドサーバーが次の状態である可能性があります。
+ 容量を超えて過負荷状態であり、新しいクライアントリクエストを処理できません。
+ 一時的にメンテナンス中です。
+ このエラーを解決するには、API Gateway アプリケーションログを調べて、バックエンドの容量、統合、その他に問題があるかどうかを確認します。
## エッジロケーションのリソースが制限されているために CloudFront でエラーが発生した
このエラーは、CloudFront から次の最も利用可能なエッジロケーションにリクエストをルーティングできず、リクエストを満たすことができないという、まれな状況で発生します。このエラーは CloudFront ディストリビューションで負荷テストを実行するときによく発生します。これを回避するには、「[CloudFront の負荷テスト](load-testing.md)」のガイドラインに従って 503 (キャパシティー超過) エラーが発生しないようにします。
このエラーが本稼働環境で発生した場合は、[サポート](https://console.aws.amazon.com/support/home#/)までお問い合わせください。
## Lambda@Edge または CloudFront Functions の実行エラー
Lambda@Edge または CloudFront Functions を使用している場合、HTTP 503 ステータスコードは、関数が実行エラーを返したことを示している可能性があります。
Lambda@Edge エラーを特定して解決する方法の詳細については、「[Lambda@Edge 関数をテストおよびデバッグする](lambda-edge-testing-debugging.md)」を参照してください。
CloudFront Functions のテストの詳細については、「[関数をテストする](test-function.md)」を参照してください。
## Lambda@Edge の制限超過
Lambda@Edge を使用している場合、HTTP 503 ステータスコードは、Lambda がエラーを返したことを示している可能性があります。このエラーは、以下のいずれかが原因である可能性があります。
+ 関数の実行数が、AWS リージョンでの実行をスロットリングするために Lambda が設定したクォータ (同時実行数または呼び出し頻度) の 1 つを超えている。
+ 関数が Lambda 関数のタイムアウトクォータを超過している。
Lambda@Edge のクォータの詳細については、「[Lambda@Edge のクォータ](cloudfront-limits.md#limits-lambda-at-edge)」を参照してください。Lambda@Edge エラーを特定して解決する方法の詳細については、「[Lambda@Edge 関数をテストおよびデバッグする](lambda-edge-testing-debugging.md)」を参照してください。「AWS Lambda 開発者ガイド」の「[Lambda サービスクォータ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)」を参照することもできます。**
# HTTP 504 ステータスコード (Gateway Timeout)
HTTP 504 ステータスコード (Gateway Timeout) は、CloudFront がオリジンにリクエストを転送したとき (リクエストされたオブジェクトがエッジキッシュに存在しなかったため) に、以下のいずれかの状況が発生したことを示しています。
+ オリジンが HTTP 504 ステータスコードを CloudFront に返した。
+ リクエストの期限切れまでにオリジンが応答しなかった。
トラフィックがファイアウォールまたはセキュリティグループによってオリジンからブロックされているか、インターネットでオリジンにアクセスできない場合、CloudFront は HTTP 504 ステータスコードを返します。最初に、これらの問題を確認します。次に、アクセスに問題がない場合は、アプリケーションの遅延とサーバーのタイムアウトを調べると、問題の特定と修正に役立ちます。
**Topics**
+ [CloudFront トラフィックを許可するようにオリジンサーバーのファイアウォールを設定する](#http-504-gateway-timeout-configure-firewall)
+ [CloudFront トラフィックを許可するようにオリジンサーバーのセキュリティグループを設定する](#http-504-gateway-timeout-configure-security-groups)
+ [インターネットでカスタムオリジンサーバーをアクセス可能にする](#http-504-gateway-timeout-make-origin-accessible)
+ [オリジンサーバーでアプリケーションからの遅延したレスポンスを見つけて修正する](#http-504-gateway-timeout-slow-application)
## CloudFront トラフィックを許可するようにオリジンサーバーのファイアウォールを設定する
オリジンサーバーのファイアウォールが CloudFront トラフィックをブロックしている場合、CloudFront は HTTP 504 ステータスコードを返すため、これが問題でないことを確認した上で、他の問題を確認できます。
これがファイアウォールの問題であるかどうかを判断するために使用する方法は、オリジンサーバーが使用しているシステムによって異なります。
+ Linux サーバーで IPTable ファイアウォールを使用している場合は、IPTables を操作するのに役立つツールと情報を検索できます。
+ Windows サーバーで Windows ファイアウォールを使用している場合は、Microsoft ドキュメントの「[Add or Edit Firewall Rule](https://technet.microsoft.com/en-us/library/cc753558(v=ws.11).aspx)」(ファイアウォール規則を追加または編集する) を参照してください。
オリジンサーバーでファイアウォール設定を評価するときは、公開されている IP アドレス範囲に基づいて、CloudFront エッジロケーションからのトラフィックをブロックしているファイアウォールまたはセキュリティルールを探します。詳細については、「[CloudFront エッジサーバーの場所と IP アドレス範囲](LocationsOfEdgeServers.md)」を参照してください。
CloudFront の IP アドレス範囲がオリジンサーバーへの接続を許可されている場合は、サーバーのセキュリティルールを更新して変更を反映します。Amazon SNS トピックにサブスクライブして、IP アドレス範囲ファイルが更新されたときに通知を受け取ることができます。通知を受け取ったら、コードを使用してファイルを取得し、解析して、ローカル環境を調整することができます。詳細については、AWS ニュースブログの「[Subscribe to AWS Public IP Address Changes via Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/)」を参照してください。
## CloudFront トラフィックを許可するようにオリジンサーバーのセキュリティグループを設定する
オリジンで Elastic Load Balancing を使用している場合は、[ELB セキュリティグループ](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html)を確認し、セキュリティグループで CloudFront からのインバウンドトラフィックを許可していることを確認します。
また、AWS Lambda を使用してセキュリティグループを自動的に更新することで、CloudFront からのインバウンドトラフィックを許可することもできます。
## インターネットでカスタムオリジンサーバーをアクセス可能にする
カスタムオリジンサーバーがインターネットで公開されておらず、CloudFront からアクセスできない場合は、HTTP 504 エラーが返されます。
CloudFront エッジロケーションはインターネットを介してオリジンサーバーに接続します。カスタムオリジンがプライベートネットワークにある場合、CloudFront はオリジンに到達できません。このため、[内部の Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html) などのプライベートサーバーをオリジンサーバーとして CloudFront で使用することはできません。
インターネットトラフィックがオリジンサーバーに接続できることを確認するには、次のコマンドを実行します (*OriginDomainName* はサーバーのドメイン名です)。
HTTPS トラフィックの場合:
+ nc -zv *OriginDomainName* 443
+ telnet *OriginDomainName* 443
HTTP トラフィックの場合:
+ nc -zv *OriginDomainName* 80
+ telnet *OriginDomainName* 80
## オリジンサーバーでアプリケーションからの遅延したレスポンスを見つけて修正する
サーバーのタイムアウトは、多くの場合、アプリケーションの応答に非常に長い時間がかかっているか、タイムアウト値の設定が低すぎる場合に発生します。
HTTP 504 エラーを手早く修正するには、ディストリビューションの CloudFront タイムアウト値を高く設定します。ただし、アプリケーションとオリジンサーバーのパフォーマンスとレイテンシーの問題があれば、最初にその問題に対応することをお勧めします。次に、HTTP 504 エラーを回避してユーザーに良好な応答性を提供する、適切なタイムアウト値を設定できます。
パフォーマンスの問題を見つけて修正するための手順について、以下に概要を示します。
1. ウェブアプリケーションの一般的な高負荷のレイテンシー (応答性) を測定します。
1. 必要に応じて CPU やメモリなどのリソースを追加します。データベースクエリを高負荷シナリオに対応するようにチューニングするなど、問題に対応する他のステップを実行します。
1. 必要に応じて、CloudFront ディストリビューションのタイムアウト値を調整します。
各ステップの詳細を以下に示します。
### 一般的な高負荷のレイテンシーの測定
1 台以上のバックエンドウェブアプリケーションサーバーで長いレイテンシーが発生しているかどうか調べるには、各サーバーで次の Linux curl コマンドを実行します。
```
curl -w "DNS Lookup Time: %{time_namelookup} \nConnect time: %{time_connect} \nTLS Setup: %{time_appconnect} \nRedirect Time: %{time_redirect} \nTime to first byte: %{time_starttransfer} \nTotal time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject
```
**注記**
サーバーで Windows を実行する場合は、Windows 用の curl を検索およびダウンロードして、類似したコマンドを実行できます。
サーバーで実行するアプリケーションのレイテンシーを測定および評価する場合は、次の点に留意します。
+ レイテンシーの値は、各アプリケーションに対して相対的です。ただし、先頭バイトまでの時間は、秒単位またはそれ以上ではなく、ミリ秒単位が合理的です。
+ 通常の負荷でアプリケーションのレイテンシーを測定して問題がなくても、高負荷がかかった場合に、ビューワーにタイムアウトが発生する可能性があることに注意してください。需要が高い場合、サーバーでレスポンスの遅延が発生するか、まったく応答しないことがあります。高負荷に伴うレイテンシーの問題を避けるために、CPU、メモリ、ディスクの読み取りと書き込みなど、サーバーのリソースをチェックし、サーバーが高負荷に合わせてスケールできることを確認します。
次の Linux コマンドを実行して、Apache プロセスによって使用されているメモリを確認できます。
`watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"`
+ サーバーでの高い CPU 使用率により、アプリケーションのパフォーマンスが大幅に低下する場合があります。Amazon EC2 インスタンスをバックエンドサーバーとして使用している場合は、サーバーの CloudWatch メトリクスで CPU 使用率を確認します。詳細については、[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)を参照してください。または、独自のサーバーを使用している場合、CPU 使用率を確認する方法について、サーバーのヘルプドキュメントを参照してください。
+ リクエストの量が多くてデータベースクエリが遅くなるなど、高負荷に伴って発生する可能性がある他の問題を確認します。
### リソースの追加およびサーバーとデータベースのチューニング
アプリケーションとサーバーの応答性を評価したら、一般的なトラフィックと高負荷の状況に対する十分なリソースがあることを確認します。
+ 独自のサーバーがある場合は、評価に基づいて、ビューワーリクエストを処理する十分な CPU、メモリ、およびディスクスペースがあることを確認します。
+ Amazon EC2 インスタンスをバックエンドサーバーとして使用している場合は、受信されるリクエストを満たす適切なリソースがインスタンスタイプにあることを確認します。詳細については、*Amazon EC2 ユーザーガイド*の「[インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。
さらに、タイムアウトを避けるために次のチューニングステップを検討します。
+ curl コマンドによって返される先頭バイトまでの時間の値が高いと思われる場合は、アプリケーションのパフォーマンスを向上させるステップを実行します。アプリケーションの応答性の向上は、タイムアウトエラーを減らすうえで有効です。
+ データベースクエリをチューニングし、パフォーマンスを低下させることなく高いリクエストボリュームを処理できるようにします。
+ バックエンドサーバーで[キープアライブ (持続的)](https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01) 接続を設定します。このオプションは、それ以降のリクエストまたはユーザーに対して接続を再確立する必要があるときに発生するレイテンシーを回避するために有効です。
+ **Elastic Load Balancing をオリジンとして使用している場合**の 504 エラーの原因には、以下が考えられます。
+ ロードバランサーが、 (10 秒の) 接続タイムアウトが期限切れになる前にターゲットへの接続を確立できない。
+ ロードバランサーがターゲットへの接続を確立しても、アイドルタイムアウト期間が経過する前にターゲットが応答しない。
+ サブネットのネットワークアクセスコントロールリスト (ACL) で、ターゲットから一時ポート (1024～65535) のロードバランサーノードへのトラフィックが許可されていない。
+ ターゲットがエンティティ本文より大きな Content-Length ヘッダーを返した。ロードバランサーが欠落しているバイトを待機している間にタイムアウトとなった。
+ ターゲットが Lambda 関数であり、接続タイムアウトが期限切れになる前に Lambda サービスが応答しない。
レイテンシー低減の詳細については、「[ELB Classic Load Balancer での高レイテンシーをトラブルシューティングする方法を教えてください。](https://repost.aws/knowledge-center/elb-latency-troubleshooting)」を参照してください。
+ **MediaTailor をオリジンとして使用している場合**の 504 エラーの原因には、以下が考えられます。
+ 相対 URL が適切に処理されなかった場合、MediaTailor はプレイヤーから不正な形式の URL を受け取る可能性があります。
+ MediaPackage が MediaTailor のマニフェストオリジンである場合、MediaPackage 404 マニフェストエラーが原因で MediaTailor が 504 エラーを返す場合があります。
+ MediaTailor オリジンサーバーへのリクエストは、完了するまでに 2 秒以上かかります。
+ **Amazon API Gateway をオリジンとして使用している場合**の 504 エラーの原因には、以下が考えられます。
+ 統合リクエストは、API Gateway REST API の最大統合タイムアウトパラメータよりも時間がかかります。詳細については、「[API Gateway で API HTTP 504 タイムアウトエラーをトラブルシューティングする方法を教えてください。](https://repost.aws/knowledge-center/api-gateway-504-errors)」を参照してください。
### 必要に応じて、CloudFront タイムアウト値を調整する
アプリケーションの低いパフォーマンス、オリジンサーバーの容量、およびその他の問題について評価、対応したが、それでもビューワーに HTTP 504 エラーが発生する場合は、オリジン応答タイムアウトに対してディストリビューションで指定されている時間の変更を検討します。詳細については、「[応答タイムアウト](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout)」を参照してください。