翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Classic Load Balancer のトラブルシューティングを行う 次の表は、Classic Load Balancer を利用する際に役立つトラブルシューティングのリソースの一覧です。 **API エラー** | エラー | | --- | | [CertificateNotFound: 未定義](ts-elb-error-api-response.md#ts-elb-error-message-certificate) | | [OutofService: 一時的なエラーの発生](ts-elb-error-api-response.md#ts-elb-error-message-service) | **HTTP エラー** | エラー | | --- | | [HTTP 400: BAD\$1REQUEST](ts-elb-error-message.md#ts-elb-errorcodes-http400) | | [HTTP 405: METHOD\$1NOT\$1ALLOWED](ts-elb-error-message.md#ts-elb-errorcodes-http405) | | [HTTP 408: Request timeout](ts-elb-error-message.md#ts-elb-errorcodes-http408) | | [HTTP 502: Bad gateway](ts-elb-error-message.md#ts-elb-errorcodes-http502) | | [HTTP 503: Service Unavailable](ts-elb-error-message.md#ts-elb-errorcodes-http503) | | [HTTP 504: Gateway Timeout](ts-elb-error-message.md#ts-elb-errorcodes-http504) | **レスポンスコードのメトリクス** | レスポンスコードのメトリクス | | --- | | [HTTPCode\$1ELB\$14XX](ts-elb-http-errors.md#ts-elb-error-metrics-ELB_4XX) | | [HTTPCode\$1ELB\$15XX](ts-elb-http-errors.md#ts-elb-error-metrics-ELB_5XX) | | [HTTPCode\$1Backend\$12XX](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_2XX) | | [HTTPCode\$1Backend\$13XX](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_3XX) | | [HTTPCode\$1Backend\$14XX](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_4XX) | | [HTTPCode\$1Backend\$15XX](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_5XX) | **ヘルスチェックの問題** | 問題 | | --- | | [ヘルスチェックのターゲットページのエラー](ts-elb-healthcheck.md#ts-elb-healthcheck-targetpage) | | [インスタンスへの接続がタイムアウトした](ts-elb-healthcheck.md#ts-elb-healthcheck-failed) | | [パブリックキー認証が失敗する](ts-elb-healthcheck.md#ts-elb-healthcheck-publickey) | | [インスタンスがロードバランサーからのトラフィックを受信しない](ts-elb-healthcheck.md#ts-elb-healthcheck-securitygroup) | | [インスタンスのポートが開いていない](ts-elb-healthcheck.md#ts-elb-healthcheck-ports) | | [Auto Scaling グループのインスタンスが ELB ヘルスチェックに失敗する](ts-elb-healthcheck.md#ts-elb-healthcheck-autoscaling) | **接続の問題** | 問題 | | --- | | [クライアントがインターネット向けロードバランサーに接続できない](ts-elb-connection-failed.md#client-cannot-connect) | | [ロードバランサーがカスタムドメインに送信されたリクエストを受信しません](ts-elb-connection-failed.md#custom-domain-request) | | [ロードバランサーに送信された HTTPS リクエストは「NET::ERR\$1CERT\$1COMMON\$1NAME\$1INVALID」を返します](ts-elb-connection-failed.md#https-cert-invalid) | **インスタンス登録の問題** | 問題 | | --- | | [EC2 インスタンスの登録に時間がかかりすぎる](ts-elb-register-instance.md#ts-elb-register-too-long) | | [有料 AMI から起動したインスタンスを登録できない](ts-elb-register-instance.md#ts-elb-paid-ami-instance) | # Classic Load Balancer のトラブルシューティング: API エラー 次は、Elastic Load Balancing API によって返されるエラーメッセージ、考えられる原因、および問題の解決のために取るべき手順を示しています。 **Topics** + [CertificateNotFound: 未定義](#ts-elb-error-message-certificate) + [OutofService: 一時的なエラーの発生](#ts-elb-error-message-service) ## CertificateNotFound: 未定義 **原因 1**: AWS マネジメントコンソールを使用して作成した証明書は、すべてのリージョンに伝達されるまでに遅延があります。この遅延が発生すると、ロードバランサーの作成プロセスの最終ステップでエラーメッセージが表示されます。 **解決方法 1**: 15 分ほど待ってから、再度試してください。問題が解決しない場合は、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にアクセスしてサポートをお求めください。 **原因 2**: AWS CLI または API を直接使用している場合、存在しない証明書に Amazon リソースネーム (ARN) を指定すると、このエラーが表示されることがあります。 **解決策 2**: AWS Identity and Access Management (IAM) アクション [GetServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServerCertificate.html) を使用して証明書 ARN を取得し、ARN に正しい値を指定したことを確認します。 ## OutofService: 一時的なエラーの発生 **原因**: Elastic Load Balancing サービスまたはその基盤ネットワーク内に一時的な問題が発生しています。この一時的な問題は、ロードバランサーとその登録済みインスタンスの状態を Elastic Load Balancing がクエリした際にも、発生する場合があります。 ** 解決方法**: API 呼び出しを再試行してください。問題が解決しない場合は、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にアクセスしてサポートをお求めください。 # Classic Load Balancer のトラブルシューティング: HTTP エラー HTTP メソッド (*HTTP 動詞*ともいう) は、HTTP リクエストを受信するリソースに対して実行するアクションを指定します。HTTP リクエストの標準メソッドは、RFC 2616 の「[Method Definitions](http://tools.ietf.org/html/rfc2616#section-9)」で定義されています。標準メソッドには GET、POST、PUT、HEAD、および OPTIONS があります。ウェブアプリケーションによっては、HTTP/1.1 メソッドの拡張であるメソッドが必要とされます (導入されている場合もあります)。一般的な HTTP 拡張メソッドには PATCH、REPORT、MKCOL、PROPFIND、MOVE、LOCK などがあります。Elastic Load Balancing では、標準 HTTP メソッドも標準外の HTTP メソッドもすべて受け付けます。 リクエストと HTTP レスポンスは、ヘッダーフィールドを使用して HTTP メッセージに関する情報を送信します。ヘッダーフィールドはコロンで区切られた名前と値のペアであり、キャリッジリターン (CR) とラインフィード (LF) で区切ります。HTTP ヘッダーフィールドの標準セットが RFC 2616 の「[Message Headers](http://tools.ietf.org/html/rfc2616#section-4.2)」で定義されています。詳細については、「[HTTP ヘッダーと Classic Load Balancer](x-forwarded-headers.md)」を参照してください。 ロードバランサーは、HTTP リクエストを受信すると、誤った形式のリクエストがないかどうかをチェックすると共に、メソッドの長さをチェックします。ロードバランサーへの HTTP リクエスト内のメソッドの長さの合計は、127 文字以下にする必要があります。これら 2 つのチェックを渡す HTTP リクエストは、ロードバランサーにより EC2 インスタンスに送信されます。リクエストのメソッドフィールドの形式が正しくなければ、[HTTP 400: BAD\$1REQUEST](#ts-elb-errorcodes-http400) エラーが返されます。リクエストのメソッドフィールドの長さが 127 文字を超えていれば、[HTTP 405: METHOD\$1NOT\$1ALLOWED](#ts-elb-errorcodes-http405) エラーが返されます。 EC2 インスタンスは、リクエストに含まれるメソッドを実装し、応答をクライアントに返信することによって、有効なリクエストを処理します。サポートされているメソッドもサポートされていないメソッドも処理するように、インスタンスを設定しておく必要があります。 以下はロードバランサーによって返されるエラーメッセージ、考えられる原因、問題の解決のためのステップです。 **Topics** + [HTTP 400: BAD\$1REQUEST](#ts-elb-errorcodes-http400) + [HTTP 405: METHOD\$1NOT\$1ALLOWED](#ts-elb-errorcodes-http405) + [HTTP 408: Request timeout](#ts-elb-errorcodes-http408) + [HTTP 502: Bad gateway](#ts-elb-errorcodes-http502) + [HTTP 503: Service Unavailable](#ts-elb-errorcodes-http503) + [HTTP 504: Gateway Timeout](#ts-elb-errorcodes-http504) ## HTTP 400: BAD\$1REQUEST **説明**: クライアントが無効なリクエストを送信したことを示します。 **原因 1**: クライアントが HTTP 仕様を満たさない誤った形式のリクエストを送信しました。たとえば、リクエストの URL にスペースを含めることはできません。 **原因 2**: クライアントが HTTP CONNECT メソッドを使用しました。このメソッドは Elastic Load Balancing ではサポートされていません。 ** 解決方法**: 直接インスタンスに接続し、クライアントリクエストの詳細をキャプチャします。ヘッダーと URL で誤った形式のリクエストを確認します。リクエストが HTTP 仕様を満たすことを確認します。HTTP CONNECT が使用されていないことを確認します。 ## HTTP 405: METHOD\$1NOT\$1ALLOWED **説明**: メソッドの長さが無効であることを示しています。 ** 原因**: リクエストヘッダー内のメソッドの長さが 127 文字を超えています。 ** 解決方法**: メソッドの長さを確認します。 ## HTTP 408: Request timeout **説明**: クライアントがリクエストをキャンセルしたか、リクエスト全体の送信に失敗したことを示します。 **原因 1**: ネットワークの中断またはリクエストの構造の問題 (ヘッダーの形式が完全ではない、指定されたコンテンツのサイズが実際に送信されたコンテンツのサイズと一致しないなど)。 ** 解決方法 1**: リクエストを生成しているコードを調べ、そのコードを実際のリクエストをより詳細に調べることのできる登録済みインスタンス (または開発/テスト環境) に直接送信します。 **原因 2**: クライアントとの接続が閉じています (ロードバランサーは応答を送信できません)。 **解決方法 2**: リクエストを送信するマシンでパケットスニッファーを使用して、応答が送信される前にクライアントが接続を閉じないことを確認してください。 ## HTTP 502: Bad gateway **説明**: 登録されたインスタンスから送信された応答をロードバランサーが解析できなかったことを示します。 ** 原因**: インスタンスからの応答の形式が適切でないか、ロードバランサーに問題があります。 ** 解決方法**: インスタンスから送信された応答が HTTP 仕様に準拠していることを確認します。[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にアクセスしてサポートをお求めください。 ## HTTP 503: Service Unavailable ** 説明**: ロードバランサーまたは登録されたインスタンスが原因でエラーが発生していることを示します。 **原因 1**: ロードバランサーにリクエストを処理する能力が不足しています。 **解決方法**: これは一時的な問題であり、数分以上は継続しません。問題が解決しない場合は、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にアクセスしてサポートをお求めください。 **原因 2**: 登録されたインスタンスがありません。 **解決方法 2**: ロードバランサーによる応答が設定された利用可能ゾーンごとに 1 つ以上のインスタンスを登録します。これを確認するには、CloudWatch の `HealthyHostCount` メトリクスを確認します。各アベイラビリティーゾーンにインスタンスが登録されているかどうかが不明な場合は、クロスゾーン負荷分散を有効にすることをお勧めします。詳細については、「[Classic Load Balancer のクロスゾーン負荷分散の設定](enable-disable-crosszone-lb.md)」を参照してください。 **原因 3**: 正常なインスタンスがありません。 **解決方法 3**: ロードバランサーの応答を設定しているすべての利用可能ゾーンに正常なインスタンスがあることを確認します。これを確認するには、`HealthyHostCount` メトリクスを確認します。 **原因 4**: サージキューがいっぱいです。 **解決方法 4**: インスタンスに、リクエスト率に対応するための十分な容量があることを確認します。これを確認するには、`SpilloverCount` メトリクスを確認します。 ## HTTP 504: Gateway Timeout **説明**: リクエストがアイドルタイムアウト期間内に完了しなかったためロードバランサーが接続を閉じたことを示します。 **原因 1**: アプリケーションの応答が、設定されているアイドルタイムアウトよりも長くかかっています。 **解決方法 1**: `HTTPCode_ELB_5XX` および `Latency` メトリクスをモニタリングします。これらのメトリクスに増加があった場合は、アイドルタイムアウト期間内に応答しないアプリケーションが原因である可能性があります。タイムアウトしているリクエストの詳細については、ロードバランサーのアクセスログを有効にし、Elastic Load Balancing によって生成されたログ内の 504 レスポンスコードを確認します。必要に応じて、キャパシティーを増やしたり、設定されているアイドルタイムアウトを長くしたりして、時間のかかるオペレーション (大容量ファイルのアップロードなど) が完了できるようにします。詳細については、[Classic Load Balancer でのアイドル接続のタイムアウト設定](config-idle-timeout.md) および「[Elastic Load Balancing のレイテンシーが高い場合のトラブルシューティング方法を教えてください。](https://repost.aws/knowledge-center/elb-latency-troubleshooting)」を参照してください。 **原因 2**: 登録されたインスタンスが Elastic Load Balancing への接続を終了中です。 **解決方法 2**: EC2 インスタンスのキープアライブ設定を有効にし、キープアライブタイムアウトが、ロードバランサーのアイドルタイムアウト設定より大きい値に設定されていることを確認します。 # Classic Load Balancer のトラブルシューティング: レスポンスコードのメトリクス ロードバランサーは、クライアントに送信された HTTP 応答コードのメトリクスを Amazon CloudWatch に送信することで、エラーの原因がロードバランサーなのか、登録済みインスタンスなのかを特定します。ロードバランサーに CloudWatch から返されるメトリクスを、問題のトラブルシューティングに使用できます。詳細については、「[Classic Load Balancer の CloudWatch メトリクス](elb-cloudwatch-metrics.md)」を参照してください。 次は、CloudWatch からロードバランサーに返される応答コードのメトリクス、考えられる原因、および問題の解決のために取るべきステップを示しています。 **Topics** + [HTTPCode\$1ELB\$14XX](#ts-elb-error-metrics-ELB_4XX) + [HTTPCode\$1ELB\$15XX](#ts-elb-error-metrics-ELB_5XX) + [HTTPCode\$1Backend\$12XX](#ts-elb-error-metrics-Backend_2XX) + [HTTPCode\$1Backend\$13XX](#ts-elb-error-metrics-Backend_3XX) + [HTTPCode\$1Backend\$14XX](#ts-elb-error-metrics-Backend_4XX) + [HTTPCode\$1Backend\$15XX](#ts-elb-error-metrics-Backend_5XX) ## HTTPCode\$1ELB\$14XX **原因**: クライアントからのリクエストが誤った形式であるか、キャンセルされました。 **ソリューション** + 「[HTTP 400: BAD\$1REQUEST](ts-elb-error-message.md#ts-elb-errorcodes-http400)」を参照してください + 「[HTTP 405: METHOD\$1NOT\$1ALLOWED](ts-elb-error-message.md#ts-elb-errorcodes-http405)」を参照してください + 「」を参照してください[HTTP 408: Request timeout](ts-elb-error-message.md#ts-elb-errorcodes-http408) ## HTTPCode\$1ELB\$15XX **原因**: ロードバランサーまたは登録されたインスタンスがエラーの原因であるか、またはロードバランサーが応答を解析できませんでした。 **ソリューション** + 「[HTTP 502: Bad gateway](ts-elb-error-message.md#ts-elb-errorcodes-http502)」を参照してください + 「[HTTP 503: Service Unavailable](ts-elb-error-message.md#ts-elb-errorcodes-http503)」を参照してください + 「」を参照してください[HTTP 504: Gateway Timeout](ts-elb-error-message.md#ts-elb-errorcodes-http504) ## HTTPCode\$1Backend\$12XX **原因**: 登録済みインスタンスから正常な応答が返されました。 **解決方法**: ありません。 ## HTTPCode\$1Backend\$13XX **原因**: 登録済みインスタンスからリダイレクト応答が送信されました。 **解決方法**: インスタンスのアクセスログまたはエラーログを確認して、原因を特定します。リクエストをインスタンスに直接送信 (ロードバランサーをバイパス) して応答を表示します。 ## HTTPCode\$1Backend\$14XX **原因**: 登録済みインスタンスからクライアントエラー応答が送信されました。 **解決方法**: インスタンスのアクセスログまたはエラーログを表示して、問題の原因を判断します。リクエストをインスタンスに直接送信 (ロードバランサーをバイパス) して応答を表示します。 **注記** クライアントが `Transfer-Encoding: chunked` ヘッダーで開始された HTTP リクエストをキャンセルする場合は、クライアントがリクエストをキャンセルしても、ロードバランサーはそのリクエストをインスタンスに転送するという既知の問題があります。これにより、バックエンド エラーが発生する場合があります。 ## HTTPCode\$1Backend\$15XX **原因**: 登録済みインスタンスからサーバーエラー応答が送信されました。 **解決方法**: インスタンスのアクセスログまたはエラーログを確認して、原因を特定します。リクエストをインスタンスに直接送信 (ロードバランサーをバイパス) して応答を表示します。 **注記** クライアントが `Transfer-Encoding: chunked` ヘッダーで開始された HTTP リクエストをキャンセルする場合は、クライアントがリクエストをキャンセルしても、ロードバランサーはそのリクエストをインスタンスに転送するという既知の問題があります。これにより、バックエンド エラーが発生する場合があります。 # Classic Load Balancer のトラブルシューティング: ヘルスチェック ロードバランサーは Elastic Load Balancing によって提供されたデフォルトのヘルスチェック設定、またはユーザーが指定するヘルスチェック設定を使用して、登録されたインスタンスの状態をチェックします。ヘルスチェック設定には、プロトコル、ping ポート、ping パス、応答タイムアウト、ヘルスチェック間隔などの情報が含まれます。インスタンスは、ヘルスチェックの間隔内に 200 応答コードを返せば、正常と見なされます。詳細については、「[Classic Load Balancer のインスタンスのヘルスチェック](elb-healthchecks.md)」を参照してください。 一部またはすべてのインスタンスの現在の状態が `OutOfService` で、説明フィールドに `Instance has failed at least the Unhealthy Threshold number of health checks consecutively` というメッセージが表示された場合は、インスタンスはロードバランサーのヘルスチェックに失敗しています。以下は確認する必要がある問題、考えられる原因、問題の解決のためのステップです。 **Topics** + [ヘルスチェックのターゲットページのエラー](#ts-elb-healthcheck-targetpage) + [インスタンスへの接続がタイムアウトした](#ts-elb-healthcheck-failed) + [パブリックキー認証が失敗する](#ts-elb-healthcheck-publickey) + [インスタンスがロードバランサーからのトラフィックを受信しない](#ts-elb-healthcheck-securitygroup) + [インスタンスのポートが開いていない](#ts-elb-healthcheck-ports) + [Auto Scaling グループのインスタンスが ELB ヘルスチェックに失敗する](#ts-elb-healthcheck-autoscaling) ## ヘルスチェックのターゲットページのエラー **問題**: 指定された ping ポートと ping パス (例: HTTP:80/index.html) 上のインスタンスに対して発行された HTTP GET リクエストで、200 以外の応答コードが受信されます。 **原因 1**: インスタンスでターゲットページが設定されていない。 **ソリューション 1**: 各登録インスタンスで、ターゲットページ (`index.html` など) を作成し、そのパスを ping パスとして指定します。 **原因 2**: 応答の Content-Length ヘッダーの値が設定されていない。 ** 解決方法 2**: 応答に本文が含まれている場合、Content-Length ヘッダーの値を 0 以上に設定するか、Transfer-Encoding の値を "chunked" に設定します。 **原因 3**: アプリケーションがロードバランサーからリクエストを受け取るか、200 応答コードを返すように設定されていない。 ** 解決方法 3**: インスタンス上のアプリケーションを確認し、原因を調査します。 ## インスタンスへの接続がタイムアウトした **問題**: ロードバランサーから EC2 インスタンスへのヘルスチェックのリクエストがタイムアウトしたか、断続的に失敗しています。 まず、インスタンスに直接接続して問題を確認します。そのインスタンスのプライベート IP アドレスを使用して、ネットワーク内からインスタンスに接続することをお勧めします。 TCP 接続では、次のコマンドを使用します。 ``` telnet private-IP-address-of-the-instance port ``` HTTP または HTTPS 接続では、次のコマンドを使用します。 ``` curl –I private-IP-address-of-the-instance:port/health-check-target-page ``` HTTP/HTTPS 接続を使用している場合に、200 以外の応答が返されたときは、「[ヘルスチェックのターゲットページのエラー](#ts-elb-healthcheck-targetpage)」を参照してください。インスタンスに直接接続できる場合は、以下を確認してください。 **原因 1**: インスタンスが、設定された応答タイムアウト期間内に応答できない。 ** 解決方法 1**: ロードバランサーのヘルスチェック設定で、応答タイムアウト設定を調整します。 **原因 2**: インスタンスに大きな負荷がかかっていて、設定された応答タイムアウト期間よりも応答に時間がかかっている。 **解決策 2**: + モニタリンググラフで、CPU の過度の使用率について確認します。詳細については、*Amazon EC2 ユーザーガイド*の「[特定の EC2 インスタンスの統計を取得する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/US_SingleMetricPerInstance.html)」を参照してください。 + EC2 インスタンスに接続して、メモリ、制限など他のアプリケーションリソースの使用状況を確認します。 + 必要に応じて、さらにインスタンスを追加するか、Auto Scaling を有効にします。詳細については[Amazon EC2 Auto Scaling ユーザーガイド](https://docs.aws.amazon.com/autoscaling/ec2/userguide/)を参照してください。 **原因 3**: HTTP または HTTPS 接続を使用していて、ping パスフィールドで指定したターゲットページ (例: `HTTP:80/index.html`) でヘルスチェックを実行している場合、ターゲットページからの応答は、設定したタイムアウトより長くかかる場合があります。 ** 解決方法 3**: よりシンプルなヘルスチェックのターゲットページを使用するか、ヘルスチェック間隔の設定を調整します。 ## パブリックキー認証が失敗する **問題**: バックエンド認証が有効で、HTTPS または SSL プロトコルを使用するように設定されたロードバランサーが、パブリックキー認証に失敗します。 ** 原因**: SSL 証明書のパブリックキーが、ロードバランサーで設定されたパブリックキーと一致しない。`s_client` コマンドを使用して、証明書チェーン内のサーバー証明書のリストを表示します。詳細については、OpenSSL ドキュメントの「[s\$1client](https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html)」を参照してください。 ** 解決方法**: SSL 証明書の更新が必要な場合があります。SSL 証明書が最新状態である場合は、その証明書をロードバランサーに再インストールしてみます。詳細については、「[Classic Load Balancer の SSL 証明書の置き換え](elb-update-ssl-cert.md)」を参照してください。 ## インスタンスがロードバランサーからのトラフィックを受信しない **問題**: インスタンスのセキュリティグループが、ロードバランサーからのトラフィックをブロックしています。 インスタンスでパケットキャプチャを実行して、問題を確認します。次の コマンドを使用します。 ``` # tcpdump port health-check-port ``` **原因 1**: インスタンスに関連付けられたセキュリティグループが、ロードバランサーからのトラフィックを許可していません。 ** 解決方法 1**: ロードバランサーからのトラフィックを許可するようにインスタンスのセキュリティグループを編集します。ロードバランサーのセキュリティグループからのトラフィックを許可するルールを追加します。 **原因 2**: ロードバランサーのセキュリティグループで、EC2 インスタンスへのトラフィックが許可されていません。 **解決方法 2**: ロードバランサーのセキュリティグループを編集して、サブネットおよび EC2 インスタンスへのトラフィックを許可します。 セキュリティグループの管理方法の詳細については、「[Classic Load Balancer のセキュリティグループの設定](elb-vpc-security-groups.md)」を参照してください。 ## インスタンスのポートが開いていない **問題**: ロードバランサーによって EC2 インスタンスに送信されるヘルスチェックが、ポートまたはファイアウォールによってブロックされます。 次のコマンドを使用して問題を確認します。 ``` netstat –ant ``` **原因**: 指定されたポートまたはリスナーポート (異なる設定の場合) が開いていません。ヘルスチェックに指定したポートと、リスナーポートの両方が開いていて、リッスンしている必要があります。 ** 解決方法**: リスナーポートと、ヘルスチェックで指定したポート (異なる設定の場合) をインスタンスで開き、ロードバランサーのトラフィックを受信できるようにします。 ## Auto Scaling グループのインスタンスが ELB ヘルスチェックに失敗する **問題**: Auto Scaling グループのインスタンスがデフォルトの Auto Scaling ヘルスチェックには合格するにもかかわらず、ELB ヘルスチェックには合格しません。 **原因**: Auto Scaling は EC2 ヘルスチェックを使用して、インスタンスに存在するハードウェアとソフトウェアの問題を検出します。一方、ロードバランサーはリクエストをインスタンスに送信して 200 応答コードを待つか、インスタンスとの TCP 接続を確立することによって (TCP ベースのヘルスチェックの場合) ヘルスチェックを実行します。 インスタンスは、インスタンスで実行するアプリケーションに、ロードバランサーがインスタンスを停止中と判断する問題があることが原因で、ELB ヘルスチェックに失敗する場合があります。このインスタンスは、Auto Scaling ヘルスチェックに合格する場合があります。EC2 のステータスチェックに基づいて正常な状態と見なされているため、Auto Scaling ポリシーによる置き換えは行われません。 **解決方法**: Auto Scaling グループに対し ELB ヘルスチェックを使用します。ELB ヘルスチェックを使用すると、Auto Scaling は、インスタンスのステータスチェックと ELB ヘルスチェックの両方の結果を確認して、インスタンスのヘルスステータスを判断します。詳細については、*Amazon EC2 Auto Scaling 開発者ガイド*の「[Auto Scaling グループへの Elastic Load Balancing ヘルスチェックの追加](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html)」を参照してください。 # Classic Load Balancer のトラブルシューティング: クライアント接続 ## クライアントがインターネット向けロードバランサーに接続できない ロードバランサーがリクエストに応答しない場合は、以下の点を確認します。 **インターネット向けロードバランサーがプライベートサブネットにアタッチされている** ロードバランサーのパブリックサブネットを指定する必要があります。パブリックサブネットには Virtual Private Cloud (VPC) のインターネットゲートウェイへのルートがあります。 **セキュリティグループまたはネットワーク ACL でトラフィックが許可されていない** ロードバランサーのセキュリティグループ、およびロードバランサーサブネットのネットワーク ACL で、クライアントからのインバウンドトラフィックとクライアントへのアウトバウンドトラフィックをリスナーポートで許可する必要があります。詳細については、「[Classic Load Balancer のセキュリティグループの設定](elb-vpc-security-groups.md)」を参照してください。 ## ロードバランサーがカスタムドメインに送信されたリクエストを受信しません ロードバランサーがカスタムドメインに送信されたリクエストを受信しない場合は、以下の点を確認します。 **カスタムドメイン名がロードバランサーの IP アドレスを解決しません** + コマンドラインインターフェイスを使用して、カスタムドメイン名がどの IP アドレスを解決するのかを確認します。 + **Linux、macOS、または Unix** — ターミナルで `dig` コマンドを使用できます。例 `dig example.com` + **Windows** — コマンドプロンプトで `nslookup` コマンドを使用できます。例 `nslookup example.com` + コマンドラインインターフェイスを使用して、ロードバランサーの DNS 名がどの IP アドレスを解決するのかを確認します。 + 2 つの出力の結果を比較します。IP アドレスは一致する必要があります。 ## ロードバランサーに送信された HTTPS リクエストは「NET::ERR\$1CERT\$1COMMON\$1NAME\$1INVALID」を返します ロードバランサーから HTTPS リクエストが `NET::ERR_CERT_COMMON_NAME_INVALID` を受信している場合は、次の原因が考えられます。 + HTTPS リクエストで使用されているドメイン名が、リスナーに関連付けられた ACM 証明書で指定されている代替名と一致しません。 + ロードバランサーのデフォルトの DNS 名が使用されています。`*.amazonaws.com` ドメインに対してパブリック証明書をリクエストできないため、デフォルトの DNS 名を使用して HTTPS リクエストを実行できません。 # Classic Load Balancer のトラブルシューティング: インスタンスの登録 ロードバランサーにインスタンスを登録する場合、ロードバランサーがインスタンスへのリクエストの送信を開始する前に行うべき手順があります。 以下は EC2 インスタンスを登録するときにロードバランサーが遭遇する可能性のある問題、考えられる原因、問題の解決のためのステップです。 **Topics** + [EC2 インスタンスの登録に時間がかかりすぎる](#ts-elb-register-too-long) + [有料 AMI から起動したインスタンスを登録できない](#ts-elb-paid-ami-instance) ## EC2 インスタンスの登録に時間がかかりすぎる **問題**: 登録した EC2 インスタンスが `InService` 状態になるまで予期されるより時間がかかっています。 **原因**: インスタンスのヘルスチェックが失敗している可能性があります。最初のインスタンスを登録するステップ (最大約 30 秒かかります) が完了した後、ロードバランサーがヘルスチェックリクエストの送信を開始します。ヘルスチェックが 1 つ成功するまで、インスタンスは `InService` になりません。 **解決方法**: 「[インスタンスへの接続がタイムアウトした](ts-elb-healthcheck.md#ts-elb-healthcheck-failed)」を参照してください。 ## 有料 AMI から起動したインスタンスを登録できない **問題**: 有料 AMI を使用して起動したインスタンスが Elastic Load Balancing に登録されません。 **原因**: このインスタンスは、有料 AMI を使用しながら [Amazon DevPay](https://aws.amazon.com/devpay/) から起動された可能性があります。 **解決方法**: Elastic Load Balancing では、有料 AMI を使用して [Amazon DevPay](https://aws.amazon.com/devpay/) から起動したインスタンスの登録はサポートされていません。[AWS Marketplace](https://aws.amazon.com/marketplace) からであれば、有料 AMI を使用可能です。から有料 AMI を既に使用 AWS Marketplace していて、その有料 AMI から起動されたインスタンスを登録できない場合は、 [AWS サポート センター](https://console.aws.amazon.com/support/home#/)にアクセスしてください。