

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Application Load Balancer のトラブルシューティング
<a name="load-balancer-troubleshooting"></a>

以下の情報は、Application Load Balancer の問題のトラブルシューティングに役立ちます。

**Topics**
+ [登録されたターゲットが実行中でない](#target-not-inservice)
+ [クライアントがインターネット向けロードバランサーに接続できない](#client-cannot-connect)
+ [ロードバランサーがカスタムドメインに送信されたリクエストを受信しません](#custom-domain-request)
+ [ロードバランサーに送信された HTTPS リクエストは「NET::ERR\_CERT\_COMMON\_NAME\_INVALID」を返します](#https-cert-invalid)
+ [ロードバランサーが処理時間の増加を示しています](#elevated-processing-time)
+ [ロードバランサーは、レスポンスコード 000 を送信します。](#response-code-000)
+ [ロードバランサーが HTTP エラーを生成する](#load-balancer-http-error-codes)
+ [ターゲットが HTTP エラーを生成する](#target-http-errors)
+ [AWS Certificate Manager 証明書は使用できません](#acm-cert-unavailable)
+ [複数行のヘッダーはサポートされていません](#multi-line-headers-issue)
+ [リソースマップを使用して異常なターゲットをトラブルシューティングする](#troubleshoot-with-resourcemap)
+ [ターゲットオプティマイザのトラブルシューティング](#troubleshoot-target-optimizer)

## 登録されたターゲットが実行中でない
<a name="target-not-inservice"></a>

ターゲットが `InService` 状態になるまでに予想以上に時間がかかっている場合、ヘルスチェックに合格していない可能性があります。ターゲットは、ヘルスチェックに合格するまで実行されません。詳細については、「[Application Load Balancer ターゲットグループのヘルスチェック](target-group-health-checks.md)」を参照してください。

インスタンスがヘルスチェックに合格していないことを確認したら、以下の点を確認します。

**セキュリティグループでトラフィックが許可されていない**  
インスタンスに関連付けられたセキュリティグループでは、ヘルスチェックポートとヘルスチェックプロトコルを使用してロードバランサーからのトラフィックを許可する必要があります。インスタンスセキュリティグループにルールを追加して、ロードバランサーセキュリティグループからのすべてのトラフィックを許可できます。また、ロードバランサーのセキュリティグループは、インスタンスへのトラフィックを許可する必要があります。

**ネットワークアクセスコントロールリスト (ACL) ではトラフィックが許可されない**  
インスタンスのサブネットに関連付けられたネットワーク ACL では、ヘルスチェックポートでインバウンドトラフィックを許可し、一時ポート (1024-65535) でアウトバウンドトラフィックを許可する必要があります。ロードバランサーノードのサブネットに関連付けられたネットワーク ACL では、一時ポートでインバウンドトラフィックを許可し、ヘルスチェックおよび一時ポートでアウトバウンドトラフィックを許可する必要があります。

**ping パスが存在しない**  
ヘルスチェックのターゲットページを作成し、そのパスを ping パスとして指定します。

**接続がタイムアウトする**  
最初に、ターゲットのプライベート IP アドレスとヘルスチェックプロトコルを使用して、ネットワーク内から直接ターゲットに接続できることを確認します。接続できない場合は、インスタンスの使用率が高すぎないかどうかを確認し、ビジー状態で応答できない場合はさらにターゲットをターゲットグループに追加します。接続できる場合、ヘルスチェックのタイムアウト時間の前に、ターゲットページが応答していない可能性があります。ヘルスチェック用のよりシンプルなターゲットページを選択するか、ヘルスチェックの設定を調整します。

**ターゲットが正常なレスポンスコードを返さなかった**  
デフォルトの成功コードは 200 ですが、ヘルスチェックを設定するときにオプションで成功コードを追加して指定できます。ロードバランサーで予期される成功コードを確認し、成功時にアプリケーションがそれらのコードを返すよう設定されていることを確認します。

**ターゲットレスポンスコードの形式が正しくないか、ターゲットへの接続中にエラーが発生しました**  
アプリケーションがロードバランサーの正常性チェックリクエストに応答することを確認します。一部のアプリケーションでは、正常性チェックに応答するために追加の設定が必要です。例えば、ロードバランサーから送信された HTTP ホストヘッダーに応答するための仮想ホスト設定などです。ホストヘッダー値には、ターゲットのプライベート IP アドレスが含まれ、その後は、デフォルトのポートが使用されない場合、ヘルスチェックのポートが続きます。ターゲットがデフォルトのヘルスチェックポートを使用する場合、ホストヘッダー値には、ターゲットのプライベート IP アドレスのみが含まれます。例えば、ターゲットのプライベート IP アドレスが `10.0.0.10` で、ヘルスチェックポートが `8080` の場合、ヘルスチェックでロードバランサーから送信される HTTP ホストヘッダーは `Host: 10.0.0.10:8080` です。ターゲットのプライベート IP アドレスが `10.0.0.10` で、ヘルスチェックポートが `80` の場合、ヘルスチェックでロードバランサーから送信される HTTP ホストヘッダーは `Host: 10.0.0.10` です。アプリケーションの正常性チェックを正常に実行するには、そのホストに応答する仮想ホスト設定、またはデフォルト設定が必要になる場合があります。正常性チェックリクエストは、次の属性を有しています。すなわち、`User-Agent` が `ELB-HealthChecker/2.0` に設定され、メッセージヘッダーフィールドの行終端記号はシーケンス CRLF、ヘッダーは最初の空の行で終了し、その後に CRLF が続きます。

## クライアントがインターネット向けロードバランサーに接続できない
<a name="client-cannot-connect"></a>

ロードバランサーがリクエストに応答しない場合は、以下の点を確認します。

**インターネット向けロードバランサーがプライベートサブネットにアタッチされている**  
ロードバランサーのパブリックサブネットを指定する必要があります。パブリックサブネットには Virtual Private Cloud (VPC) のインターネットゲートウェイへのルートがあります。

**セキュリティグループまたはネットワーク ACL でトラフィックが許可されていない**  
ロードバランサーのセキュリティグループ、およびロードバランサーサブネットのネットワーク ACL で、クライアントからのインバウンドトラフィックとクライアントへのアウトバウンドトラフィックをリスナーポートで許可する必要があります。

## ロードバランサーがカスタムドメインに送信されたリクエストを受信しません
<a name="custom-domain-request"></a>

ロードバランサーがカスタムドメインに送信されたリクエストを受信しない場合は、以下の点を確認します。

**カスタムドメイン名がロードバランサーの IP アドレスを解決しません**  
+ コマンドラインインターフェイスを使用して、カスタムドメイン名がどの IP アドレスを解決するのかを確認します。
  + **Linux、macOS、または Unix** — ターミナルで `dig` コマンドを使用できます。例 `dig example.com`
  + **Windows** — コマンドプロンプトで `nslookup` コマンドを使用できます。例 `nslookup example.com`
+ コマンドラインインターフェイスを使用して、ロードバランサーの DNS 名がどの IP アドレスを解決するのかを確認します。
+ 2 つの出力の結果を比較します。IP アドレスは一致する必要があります。

Route 53 を使用してカスタムドメインをホストしている場合は、*Amazon Route 53 開発者ガイド*の 「[ドメインがインターネットで利用できない](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/troubleshooting-domain-unavailable.html)」を参照してください。

## ロードバランサーに送信された HTTPS リクエストは「NET::ERR\_CERT\_COMMON\_NAME\_INVALID」を返します
<a name="https-cert-invalid"></a>

ロードバランサーから HTTPS リクエストが `NET::ERR_CERT_COMMON_NAME_INVALID` を受信している場合は、次の原因が考えられます。
+ HTTPS リクエストで使用されているドメイン名が、リスナーに関連付けられた ACM 証明書で指定されている代替名と一致しません。
+ ロードバランサーのデフォルトの DNS 名が使用されています。`*.amazonaws.com` ドメインに対してパブリック証明書をリクエストできないため、デフォルトの DNS 名を使用して HTTPS リクエストを実行できません。

## ロードバランサーが処理時間の増加を示しています
<a name="elevated-processing-time"></a>

ロードバランサーは、設定に基づいて処理時間を異なる方法でカウントします。
+  AWS WAF が Application Load Balancer に関連付けられていて、クライアントが HTTP POST リクエストを送信する場合、POST リクエストのデータを送信する時間はロードバランサーアクセスログの `request_processing_time`フィールドに反映されます。この動作は HTTP POST リクエストで想定されるものです。
+  AWS WAF が Application Load Balancer に関連付けられておらず、クライアントが HTTP POST リクエストを送信する場合、POST リクエストのデータを送信する時間はロードバランサーアクセスログの `target_processing_time`フィールドに反映されます。この動作は HTTP POST リクエストで想定されるものです。

## ロードバランサーは、レスポンスコード 000 を送信します。
<a name="response-code-000"></a>

HTTP/2 接続では、1 つの接続を介して処理されるリクエスト数が 10,000 を超える場合、ロードバランサーは GOAWAY フレームを送信し、TCP FIN を使用して接続を閉じます。

## ロードバランサーが HTTP エラーを生成する
<a name="load-balancer-http-error-codes"></a>

次の HTTP エラーは、ロードバランサーで生成されます。ロードバランサーはクライアントに HTTP コードを送信し、アクセスログにリクエストを保存して、`HTTPCode_ELB_4XX_Count` または `HTTPCode_ELB_5XX_Count` メトリクスを増やします。

**Topics**
+ [HTTP 400: Bad request](#http-400-issues)
+ [HTTP 401: Unauthorized](#http-401-issues)
+ [HTTP 403: Forbidden](#http-403-issues)
+ [HTTP 405: Method not allowed](#http-405-issues)
+ [HTTP 408: Request timeout](#http-408-issues)
+ [HTTP 413: Payload too large](#http-413-issues)
+ [HTTP 414: URI too long](#http-414-issues)
+ [HTTP 460](#http-460-issues)
+ [HTTP 463](#http-463-issues)
+ [HTTP 464](#http-464-issues)
+ [HTTP 500: Internal server error](#http-500-issues)
+ [HTTP 501: Not implemented](#http-501-issues)
+ [HTTP 502: Bad gateway](#http-502-issues)
+ [HTTP 503: Service Unavailable](#http-503-issues)
+ [HTTP 504: Gateway Timeout](#http-504-issues)
+ [HTTP 505: バージョンはサポートされていません](#http-505-issues)
+ [HTTP 507: ストレージ不足](#http-507-issues)
+ [HTTP 561: Unauthorized](#http-561-issues)
+ [HTTP 562: JWKS リクエストに失敗しました](#http-562-issues)

### HTTP 400: Bad request
<a name="http-400-issues"></a>

考えられる原因:
+ クライアントが HTTP 仕様を満たさない誤った形式のリクエストを送信した。
+ リクエストヘッダーが、リクエスト行あたり 16 K、1 つのヘッダーあたり 16 K、またはリクエストヘッダー全体に対して 64 K を超えている。
+ クライアントが、リクエスト本文全体を送信する前に接続を閉じた。

### HTTP 401: Unauthorized
<a name="http-401-issues"></a>

ユーザーを認証するようリスナールールを設定しましたが、以下のいずれかが該当しません。
+ `OnUnauthenticatedRequest` が認証されていないユーザーを拒否するように設定されているか、IdP によってアクセスが拒否されました。
+ IdP によって返されるクレームのサイズが、ロードバランサーによってサポートされる最大サイズを超えています。
+ クライアントがホストヘッダーなしで HTTP/1.0 リクエストを送信し、ロードバランサーはリダイレクト URL を生成できませんでした。
+ リクエストされたスコープで ID トークンが返さません。
+ クライアントのログインがタイムアウトする前にログインプロセスが完了しません。詳細については、「[クライアントログインタイムアウト](listener-authenticate-users.md#client-login-timeout)」を参照してください。
+ 次のいずれかの理由で JWT 認証が失敗しました。
  + リクエストに認可ヘッダーがありません。(JWTHeaderNotPresent)
  + リクエストのトークン形式が無効です。これは、次の場合に発生する可能性があります。
    + トークンの形式が正しくないか、必須部分 (ヘッダー、ペイロード、または署名) がない
    + ヘッダーに「ベアラー」プレフィックスがありません
    + ヘッダーに別の認証タイプ (「Basic」など) が含まれている
    + 認可ヘッダーは存在しますが、トークンがありません
    + リクエストに複数のトークンが存在する (JWTRequestFormatInvalid)
  + トークン署名の検証に失敗しました。これは、次の場合に発生する可能性があります。
    + 署名が一致しません
    + パブリックキーが無効であるか、デコードキーに変換できません
    + パブリックキーサイズが 2K ではない
    + トークンがサポートされていないアルゴリズムで署名されている
    + トークンの KID が JWKS エンドポイントに存在しません (JWTSignatureValidationFailed)
  + JWT に検証に必要なクレームがありません。(JWTClaimNotPresent)
  + JWT のクレームの値の形式が、指定された設定形式と一致しません。(JWTClaimFormatInvalid)

### HTTP 403: Forbidden
<a name="http-403-issues"></a>

Application Load Balancer へのリクエストをモニタリングするように AWS WAF ウェブアクセスコントロールリスト (ウェブ ACL) を設定し、リクエストをブロックしました。

### HTTP 405: Method not allowed
<a name="http-405-issues"></a>

クライアントが、Application Load Balancer でサポートされていない TRACE メソッドを使用しました。

### HTTP 408: Request timeout
<a name="http-408-issues"></a>

アイドルタイムアウト期間の期限が切れる前に、クライアントからデータが送信されませんでした。TCP キープアライブを送信しても、このタイムアウトを防ぐことはできません。各アイドルタイムアウト期間が経過する前に、1 バイト以上のデータを送信します。必要に応じて、アイドルタイムアウト期間を長くします。

### HTTP 413: Payload too large
<a name="http-413-issues"></a>

考えられる原因:
+ ターゲットは Lambda 関数で、リクエストボディが 1 MB を超えています。
+ リクエストヘッダーが、リクエスト行あたり 16 K、1 つのヘッダーあたり 16 K、またはリクエストヘッダー全体に対して 64 K を超えている。

### HTTP 414: URI too long
<a name="http-414-issues"></a>

リクエストの URL またはクエリ文字列パラメータが大きすぎます。

### HTTP 460
<a name="http-460-issues"></a>

ロードバランサーはクライアントからリクエストを受信したが、クライアントはアイドルタイムアウトが経過する前に、ロードバランサーとの接続を閉じました。

クライアントのタイムアウト期間がロードバランサーのアイドルタイムアウト期間より長いかどうか確認してください。クライアントのタイムアウト期間が経過する前に、ターゲットがクライアントにレスポンスを返すことを確認するか、クライアントがサポートする場合は、クライアントのタイムアウト期間を増やしてロードバランサーのアイドルタイムアウトに合わせます。

### HTTP 463
<a name="http-463-issues"></a>

多すぎる IP アドレスを含む **X-Forwarded-For** リクエストヘッダーがロードバランサーに送信されました。IP アドレスの上限は 30 です。

### HTTP 464
<a name="http-464-issues"></a>

ロードバランサーは、ターゲットグループプロトコルのバージョン構成と互換性のない着信リクエストプロトコルを受信しました。

考えられる原因:
+  リクエストプロトコルは HTTP/1.1 であるが、ターゲットグループのプロトコルバージョンが gRPC または HTTP/2 である。
+  リクエストプロトコルは gRPC であるが、ターゲットグループのプロトコルバージョンが HTTP/1.1 である。
+  リクエストプロトコルは HTTP/2 であり、リクエストは POST ではないが、ターゲットグループのプロトコルバージョンが gRPC である。

### HTTP 500: Internal server error
<a name="http-500-issues"></a>

考えられる原因:
+  AWS WAF ウェブアクセスコントロールリスト (ウェブ ACL) を設定し、ウェブ ACL ルールの実行中にエラーが発生しました。
+ ロードバランサーは、IdP トークンのエンドポイントまたは IdP ユーザー情報エンドポイントと通信できません。
  + IdP の DNS がパブリックに解決可能であることを確認します。
  + ロードバランサーのセキュリティグループおよび VPC のネットワーク ACL がこれらのエンドポイントに対するアウトバウンドアクセスを許可していることを検証します。
  + VPC がインターネット接続されていることを確認します。内部向けロードバランサーがある場合は、NAT ゲートウェイを使用してインターネットアクセスを有効にします。
+ IdP から受信したユーザークレームが 11 KB を超えています。
+ IdP トークンエンドポイントまたは IdP ユーザー情報エンドポイントの応答に 5 秒以上かかります。
+ ロードバランサーが JWKS エンドポイントと通信できないか、JWKS エンドポイントが 5 秒以内に応答しません。
+ JWKS エンドポイントによって返されるレスポンスのサイズが 150KB を超えているか、JWKS エンドポイントによって返されるキーの数が 10 を超えています。
+ ターゲットグループでターゲットオプティマイザが有効になっているため、エージェントが予期しないエラーが発生しました。「[ターゲットオプティマイザのトラブルシューティング](#troubleshoot-target-optimizer)」を参照してください。

### HTTP 501: Not implemented
<a name="http-501-issues"></a>

考えられる原因:
+ サポートされていない値を含む **Transfer-Encoding** ヘッダーがロードバランサーに送信されました。**Transfer-Encoding** でサポートされている値は、`chunked` と `identity` です。代わりに、**Content-Encoding** ヘッダーを使用することができます。
+ Websocket リクエストは、ターゲットオプティマイザが有効になっているターゲットグループにルーティングされました。

### HTTP 502: Bad gateway
<a name="http-502-issues"></a>

考えられる原因:
+ 接続の確立を試みているときに、ロードバランサーがターゲットから TCP RST を受信した。
+ 接続の確立を試みているときに、ロードバランサーがターゲットから予期しないレスポンスを受信した (例: 「ICMP Destination unreachable (Host unreachable) (ICMP 送信先に到達できません (ホストに到達できません))」など)。ターゲットポートでロードバランサーサブネットからターゲットへのトラフィックが許可されているかどうかを確認します。
+ ロードバランサーにターゲットへの未処理のリクエストがあるときに、ターゲットが TCP RST または TCP FIN との接続を閉じた。ターゲットのキープアライブ期間がロードバランサーのアイドルタイムアウト値よりも短いことを確認します。
+ ターゲットのレスポンス形式が正しくないか、有効でない HTTP ヘッダーが含まれている。
+ ターゲットレスポンスヘッダーは、レスポンスヘッダー全体で32 K を超えました。
+ 登録解除されたターゲットによって処理されていたリクエストで登録解除の遅延期間が経過しました。時間のかかるオペレーションが完了できるように、遅延期間を増やします。
+ ターゲットは Lambda 関数で、レスポンスボディが 1 MB を超えています。
+ ターゲットは、設定されたタイムアウトに達する前に応答しなかった Lambda 関数です。
+ ターゲットとなるのは、エラーを返した Lambda 関数、または Lambda サービスがスロットリングした関数です。
+ ロードバランサーがターゲットに接続するときに SSL ハンドシェイクエラーが発生しました。

詳細については、 AWS サポートナレッジセンターの[Application Load Balancer HTTP 502 エラーのトラブルシューティング方法](https://repost.aws/knowledge-center/elb-alb-troubleshoot-502-errors)」を参照してください。

### HTTP 503: Service Unavailable
<a name="http-503-issues"></a>

考えられる原因:
+ ロードバランサーのターゲットグループに登録されたターゲットがないか、登録されたすべてのターゲットが `unused` 状態です。
+ リクエストはターゲットオプティマイザが有効になっているターゲットグループにルーティングされ、リクエストを受信する準備ができているターゲットがないため拒否されました。「[ターゲットオプティマイザのトラブルシューティング](#troubleshoot-target-optimizer)」を参照してください。

### HTTP 504: Gateway Timeout
<a name="http-504-issues"></a>

考えられる原因:
+ ロードバランサーは、接続タイムアウトが期限切れになる (10 秒) 前にターゲットへの接続の確立に失敗した。
+ ロードバランサーはターゲットへの接続を確立したが、アイドルタイムアウト期間が経過する前にターゲットが応答しなかった。
+ サブネットのネットワーク ACL で、ターゲットから一時ポート (1024-65535) のロードバランサーノードへのトラフィックが許可されなかった。
+ ターゲットがエンティティ本文より大きな Content-Length ヘッダーを返した。ロードバランサーが欠落しているバイトを待機してタイムアウトした。
+ ターゲットは Lambda 関数であり、接続タイムアウトが期限切れになる前に Lambda サービスが応答しませんでした。
+ ロードバランサーがターゲットに接続するときに SSL ハンドシェイクタイムアウト (10 秒) が発生しました。

### HTTP 505: バージョンはサポートされていません
<a name="http-505-issues"></a>

ロードバランサーが予期しない HTTP バージョンリクエストを受信しました。例えば、ロードバランサーが HTTP/1 接続を確立したが、HTTP/2 リクエストを受信したとします。

### HTTP 507: ストレージ不足
<a name="http-507-issues"></a>

リダイレクト URL が長すぎます。

### HTTP 561: Unauthorized
<a name="http-561-issues"></a>

リスナールールがユーザーを認証するように設定されていますが、IdP がユーザーの認証時にエラーコードを返しました。関連する[エラー理由コード](load-balancer-access-logs.md#error-reason-codes)についてはアクセスログを確認してください。

### HTTP 562: JWKS リクエストに失敗しました
<a name="http-562-issues"></a>

ロードバランサーは、JWKS (JSON ウェブキーセット) エンドポイントから成功した有効なレスポンスを受信できませんでした。成功したレスポンスのステータスコードは 200～299 の範囲である必要がありますが、代わりに別のステータスコードが受信されました。有効なレスポンスには、次の問題があってはなりません。
+ 非 JSON 形式
+ 無効な文字
+ 無効な JWKS 形式
+ 必須の JWKS 属性がないか、無効です
+ パブリックキーにはサポートされていないアルゴリズムがあります
+ パブリックキーをデコードキーに変換できませんでした
+ パブリックキーサイズが 2K ではなかった

## ターゲットが HTTP エラーを生成する
<a name="target-http-errors"></a>

ロードバランサーはターゲットからの有効な HTTP レスポンスを、HTTP エラーを含めてクライアントに転送します。ターゲットによって生成された HTTP エラーは、`HTTPCode_Target_4XX_Count` および `HTTPCode_Target_5XX_Count` メトリクスに記録されます。

## AWS Certificate Manager 証明書は使用できません
<a name="acm-cert-unavailable"></a>

Application Load Balancer で HTTPS リスナーを使用することを決定する場合、 は証明書を発行する前にドメインの所有権を検証 AWS Certificate Manager する必要があります。設定中にこのステップを実行しなかった場合、証明書は `Pending Validation` 状態のままとなり、検証されるまで使用できません。
+ E メール検証を使用する場合は、「*AWS Certificate Manager ユーザーガイド*」の「[E メール検証](https://docs.aws.amazon.com/acm/latest/userguide/email-validation.html)」を参照してください。
+ DNS での検証を使用する場合は、「*AWS Certificate Manager ユーザーガイド*」の「[DNS での検証](https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html)」を参照してください。

## 複数行のヘッダーはサポートされていません
<a name="multi-line-headers-issue"></a>

Application Load Balancer は、`message/http` メディアタイプヘッダーを含め、複数行のヘッダーをサポートしていません。複数行のヘッダーが提供されると、Application Load Balancer は、コロン文字「`:`」を付加してターゲットに渡します。

## リソースマップを使用して異常なターゲットをトラブルシューティングする
<a name="troubleshoot-with-resourcemap"></a>

Application Load Balancer のターゲットがヘルスチェックに失敗した場合は、リソースマップを使用することで、異常なターゲットを特定し、障害理由コードに基づいたアクションを取ることができます。詳細については、「[Application Load Balancer リソースマップを表示する](view-resource-map.md)」を参照してください。

リソースマップには、**[概要]** と **[異常なターゲットマップ]** という 2 つのビューがあります。**[概要]** はデフォルトで選択され、ロードバランサーのすべてのリソースが表示されています。**[異常なターゲットマップ]** ビューを選択すると、Application Load Balancer に関連付けられている各ターゲットグループ内の異常なターゲットのみが表示されます。

**注記**  
リソースマップ内の該当するすべてのリソースのヘルスチェックの概要とエラーメッセージを表示するには、**[リソースの詳細を表示]** を有効にする必要があります。有効になっていない場合は、各リソースを選択して詳細を表示する必要があります。

**[ターゲットグループ]** 列には、各ターゲットグループの正常なターゲットと異常なターゲットの概要が表示されます。これは、すべてのターゲットがヘルスチェックに合格しなかったのか、特定のターゲットのみが合格しなかったのかを判断するのに役立ちます。ターゲットグループ内のすべてのターゲットがヘルスチェックに合格しなかった場合は、ターゲットグループの設定を確認します。ターゲットグループの名前を選択して、新しいタブで詳細ページを開きます。

**[ターゲット]** 列には、各ターゲットの TargetID と現在のヘルスチェックステータスが表示されます。ターゲットに異常がある場合、ヘルスチェックのエラー理由コードが表示されます。ヘルスチェックに合格しなかったターゲットが 1 つである場合、そのターゲットに十分なリソースがあることを確認し、そのターゲットで実行されているアプリケーションが使用可能であることを確認します。ターゲット ID を選択すると、詳細ページが新しいタブで開きます。

**[エクスポート]** を選択すると、Application Load Balancer のリソースマップの現在の画面を PDF でエクスポートできます。

インスタンスがヘルスチェックに合格していないことを確認したら、エラー理由コードに基づいて、以下の点を確認します。
+ **[異常: HTTP レスポンスの不一致]**
  + ターゲットで実行されているアプリケーションが、Application Load Balancer のヘルスチェックのリクエストに正しい HTTP レスポンスを送信していることを確認します。
  + または、Application Load Balancer のヘルスチェックのリクエストを、ターゲットで実行されているアプリケーションのレスポンスに一致するように更新することもできます。
+ **[異常: リクエストがタイムアウトしました]**
  + ターゲットと Application Load Balancer に関連付けられたセキュリティグループとネットワークアクセスコントロールリスト (ACL) が、接続をブロックしていないことを確認します。
  + ターゲットに Application Load Balancer からの接続を受け入れるのに十分なリソースがあることを確認します。
  + ターゲットで実行されているアプリケーションのステータスを確認します。
  + Application Load Balancer のヘルスチェックのレスポンスは、各ターゲットのアプリケーションログで確認できます。詳細については、「[ヘルスチェックの理由コード](target-group-health-checks.md#target-health-reason-codes)」を参照してください。
+ **[異常: FailedHealthChecks]**
  + ターゲットで実行されているアプリケーションのステータスを確認します。
  + ターゲットがヘルスチェックポートのトラフィックをリッスンしていることを確認します。
**HTTPS リスナーを使用する場合**  
フロントエンド接続に使用するセキュリティポリシーを選択します。バックエンド接続に使用するセキュリティポリシーは、使用中のフロントエンドのセキュリティポリシーに基づいて自動的に選択されます。リスナーに次のものがある場合:  
**FIPS ポスト量子 TLS ポリシー** - バックエンド接続の使用 `ELBSecurityPolicy-TLS13-1-0-FIPS-PQ-2025-09`
**FIPS ポリシー** - バックエンド接続の使用 `ELBSecurityPolicy-TLS13-1-0-FIPS-2023-04`
**ポスト量子 TLS ポリシー** - バックエンド接続の使用 `ELBSecurityPolicy-TLS13-1-0-PQ-2025-09`
**TLS 1.3 ポリシー** - バックエンド接続の使用 `ELBSecurityPolicy-TLS13-1-0-2021-06`
他のすべての TLS ポリシーのバックエンド接続では、 `ELBSecurityPolicy-2016-08`
詳細については、「[Security policies](describe-ssl-policies.md)」を参照してください。
  + ターゲットがサーバー証明書とキーをセキュリティポリシーで指定された正しい形式で提供していることを確認します。
  + ターゲットが、1 つ以上の一致する暗号と、TLS ハンドシェイクを確立するために Application Load Balancer が提供するプロトコルをサポートしていることを確認します。

## ターゲットオプティマイザのトラブルシューティング
<a name="troubleshoot-target-optimizer"></a>

 詳細なモニタリングについては、[「ターゲットオプティマイザメトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)」を参照してください。

**設定エラー**
+  `HTTPCode_ELB_502_Count`: ロードバランサーは、接続を確立しようとしたときにエージェントから TCP RST を受信しました。
+  `HTTPCode_ELB_504_Count`: ロードバランサーは、アイドルタイムアウト期間が経過する前にエージェントへの接続を確立できませんでした。
+ `HTTPCode_Target_5XX_Count`: エージェントが接続を確立しようとしたときに、ターゲットアプリケーションから TCP RST を受信しました。*(ターゲットアプリケーション自体がこのエラーレスポンスを生成していない場合にのみ適用されます）。*

これらの問題を解決するには、以下を確認してください。
+ ターゲットのセキュリティグループが正しく設定されています。
+ エージェントは想定された設定で実行されています。
+ ターゲットアプリケーションが実行されており、エージェントで設定された TARGET\_CONTROL\_DESTINATION\_ADDRESS をリッスンしています。

**サービス使用不可エラー (`HTTPCode_ELB_503_Count`)**

一貫した HTTP 503 エラーは、ALB からリクエストを受信する準備ができているターゲットが不足していることを意味します。TargetControlRequestRejectCount メトリクスは、これらの拒否されたリクエストを表します。TargetControlWorkQueueLength メトリクスはゼロに近い値になります。この問題を修正するには、次の点を考慮してください。
+ ターゲットの数を増やす
+ エージェントで TARGET\_CONTROL\_MAX\_CONCURRENCY 変数をより大きな値に設定します。

**ヘルスチェックエラー**
+ ヘルスチェックポートが TARGET\_CONTROL\_DATA\_ADDRESS と同じ場合、ALB からのヘルスチェックリクエストはエージェントを介してターゲットアプリケーションに送信されます。ヘルスチェックが失敗した場合 (HTTP 502 またはタイムアウトのため) は、「設定エラー」セクションを参照してください。