Application Load Balancer (ALB) によって返された異常なステータスコードが発生した場合、このトピックで説明されている考えられる原因に基づいてエラーをトラブルシューティングできます。 このトピックでは、ALBの一般的なステータスコードと考えられる原因について説明します。
ALBはアクセスログをサポートしています。 アクセスログは、より効率的な方法で問題を見つけるのに役立ちます。 アクセスログを有効にする方法の詳細については、「アクセスログ」をご参照ください。
異常なステータスコードを受け取った場合は、アクセスログのALBステータスコードとバックエンドステータスコードが同じかどうかを確認します。 2つのステータスコードが同じである場合、異常なステータスコードがバックエンドサーバーによって返される可能性があります。 バックエンドサーバーがステータスコードを返す理由を最初に確認することをお勧めします。
400 (悪い要求)
クライアントからのHTTPリクエストの形式が無効です。
考えられる原因：
バックエンドサーバーはHTTP 400ステータスコードを返し、ALBはバックエンドステータスコードをクライアントに渡します。 バックエンドサーバーがHTTP 400のステータスコードを返す理由を確認します。
HTTPヘッダーの形式が無効です。 たとえば、コンテンツの長さはリクエストボディの長さと一致しません。 クライアントのHTTPリクエストの形式を分析し、有効なリクエストと比較することをお勧めします。
HTTPSリスナーがALBインスタンスに追加されます。 クライアントがHTTPSリクエストを送信せず、HTTP 400ステータスコードが返された場合は、クライアントがHTTPSポートにHTTPリクエストを送信したかどうかを確認することを推奨します。
HTTPリクエストが送信される前に、クライアントは接続を閉じます。 パケットをキャプチャし、切断の原因を特定することを推奨します。
ALBでは、各HTTPヘッダーの長さが32 KBを超えないようにする必要があります。 この制限を超えると、HTTP 400のステータスコードが返されます。 HTTPヘッダーの長さを調整することを推奨します。
405 (メソッドは許可されません)
リクエストメソッドはサポートされていません。
考えられる原因：
バックエンドサーバーは、クライアントが使用するリクエストメソッドをサポートしていません。 クライアントが使用するメソッドがバックエンドサーバーが使用するメソッドと一致するかどうかを確認することを推奨します。 たとえば、特定のメソッドがバックエンドサーバーでサポートされているかどうかを確認するには、
curl -X method ip:portコマンドを実行します。methodはクライアントが使用するリクエストメソッドを指定し、ipはバックエンドサーバーのIPアドレスを指定し、portはバックエンドサーバーのポートを指定します。ALBはTRACEリクエストメソッドをサポートしていません。 別の方法を使用することを推奨します。
408 (リクエストタイムアウト)
リクエストがタイムアウトし、ALBが接続を閉じました。
考えられる原因：
リクエストタイムアウト期間中、リクエストの一部のみが送信され、ALBは接続を閉じます。 たとえば、HTTPヘッダーのみが送信され、本文は送信されません。 パケットをキャプチャして、クライアントにパフォーマンスのボトルネックやその他の異常な動作があるかどうかを確認することを推奨します。 ALBリスナーのリクエストタイムアウト期間を延長して、問題が解決できるかどうかを確認することもできます。 詳細については、「リスナーの変更」をご参照ください。
クライアントとALBインスタンス間の接続にエラーがあります。 TCPパケットの往復時間 (RTT) が過度に大きいか、またはパケットが失われる。 アクセスログまたはキャプチャパケットのrequest_timeフィールドとtcpinfo_rttフィールドをチェックして、クライアントネットワークにエラーが含まれているかどうかを確認することを推奨します。
ALBインスタンスへのネットワークトラフィックの量が多すぎるため、帯域幅の調整とパケット損失が発生します。 CloudMonitorを使用して、ALBインスタンスのアウトバウンド帯域幅とドロップされた接続数を確認することを推奨します。 詳細については、「ALBモニタリングメトリクス」および「ALBインスタンスに関するモニタリング情報の表示」をご参照ください。
414 (URIが長すぎる)
クライアント要求のURI長がバックエンドサーバーがサポートする長さを超えているため、ALBは要求を拒否します。
考えられる原因：
バックエンドサーバーはHTTP 414ステータスコードを返し、ALBはバックエンドステータスコードをクライアントに渡します。 バックエンドサーバーがHTTP 414のステータスコードを返す理由を確認します。
ALBへのリクエストのURI長は32 KBを超えることはできません。 リクエストのURIが32 KBを超える場合、HTTP 414のステータスコードが返されます。 URIを短くすることを推奨します。 送信するデータ量が多い場合は、POSTメソッドを使用してデータを送信することを推奨します。 ALBへのPOSTリクエストの本体のサイズは最大50 GBです。
499 (クライアントクローズ要求)
クライアントが接続を閉じました。
考えられる原因：
クライアントとALBインスタンス間の接続にエラーがあります。 RTTが大きいか、またはパケットが失われる。 アクセスログまたはキャプチャパケットのrequest_timeフィールドとtcpinfo_rttフィールドをチェックして、クライアントネットワークにエラーが含まれているかどうかを確認することを推奨します。
ALBインスタンスへのネットワークトラフィックの量が多すぎるため、帯域幅の調整とパケット損失が発生します。 CloudMonitorを使用して、ALBインスタンスのアウトバウンド帯域幅とドロップされた接続数を確認することを推奨します。 詳細については、「ALBモニタリングメトリクス」および「ALBインスタンスに関するモニタリング情報の表示」をご参照ください。
バックエンドサーバーのリクエスト処理時間が長すぎ、クライアントのリクエストタイムアウト期間を超えています。 アクセスログのupstream_response_timeフィールドは、バックエンドサーバーがリクエストを処理するのに必要な時間を示します。 バックエンドサーバーのCPU、メモリ、およびネットワークでパフォーマンスのボトルネックを確認することを推奨します。
クライアントで設定されているリクエストタイムアウト期間が短すぎます。 その結果、クライアントはHTTPリクエストが送信される前に接続を閉じます。 アクセスログのrequest_timeフィールドを確認することを推奨します。 このフィールドは、クライアントがリクエストを送信するのに必要な時間を示します。 クライアントで適切なリクエストタイムアウト期間を設定するには、このフィールドの値を参照します。
クライアントは不明な問題に遭遇し、HTTPリクエストが送信される前に接続を閉じます。 HTTPリクエストが送信される前に、クライアントが接続を閉じるかどうかを確認することをお勧めします。
500 (内部サーバーエラー)
バックエンドサーバーで内部エラーが発生しました。 リクエストはバックエンドサーバーで処理できません。
考えられる原因：
バックエンドサーバーはHTTP 500ステータスコードを返し、ALBはバックエンドステータスコードをクライアントに渡します。 バックエンドサーバーがHTTP 500のステータスコードを返す理由を確認します。
バックエンドサーバーは、応答を送信する前に接続を閉じます。 原因を特定し、トラブルシューティングするために、バックエンドサーバーでパケットをキャプチャすることを推奨します。
502 (悪いゲートウェイ)
ALBのHTTPまたはHTTPSリスナーがバックエンドサーバーにリクエストを送信できなかったか、バックエンドサーバーからレスポンスが返されませんでした。 その結果、HTTP 502のステータスコードがクライアントに返されました。
考えられる原因：
バックエンドサーバーはHTTP 502ステータスコードを返し、ALBはバックエンドステータスコードをクライアントに渡します。 バックエンドサーバーがHTTP 502のステータスコードを返す理由を確認します。
ALBバックエンドサーバーは別のHTTPステータスコード (504や444など) を返しますが、ALBはHTTP 502ステータスコードを返します。 アクセスログまたはキャプチャパケットのupstream_statusフィールドとstatusフィールドをチェックして、バックエンドサーバーにエラーがないかどうかを確認することを推奨します。
TCPを介したALBとバックエンドサーバー間の通信にエラーが含まれています。 バックエンドサーバーが正常かどうか、サービスポートがリスナーによってリッスンされているかどうか、またはTCPハンドシェイクが成功したかどうかを確認します。
バックエンドサーバーのバックログがいっぱいになると、パケットがドロップされます。 バックエンドサーバーのネットワーク統計がドロップされたパケットの数を示すかどうかを確認するには、netstatを使用することを推奨します。 たとえば、
netstat -s | grep -i listenコマンドを実行できます。クライアントから送信されたパケットの長さが、バックエンドサーバーの最大送信単位 (MTU) を超えています。 この場合、ヘルスチェックが成功するか、短いパケットが期待どおりに送信されます。 しかしながら、より長いパケットは期待通りに送信されない。 バックエンドサーバーでパケットをキャプチャして、パケット長が要件を満たしているかどうかを分析することを推奨します。
バックエンドサーバーから返されたパケットは、無効な形式であるか、無効なHTTPヘッダーが含まれています。 バックエンドサーバーでパケットをキャプチャして、HTTP応答の形式が無効かどうかを確認することを推奨します。
ALBのバックエンドサーバーがリクエストの処理を完了していません。 バックエンドサーバーのログデータを確認します。 また、CPUとメモリの使用量を確認してください。
503 (一時的に使用できないサービス)
サービスは利用できません。 これは、トラフィックが制限を超えているか、バックエンドサーバーが利用できないためです。
考えられる原因：
バックエンドサーバーはHTTP 503ステータスコードを返し、ALBはバックエンドステータスコードをクライアントに渡します。 バックエンドサーバーがHTTP 503のステータスコードを返す理由を確認します。
クライアントからのネットワークトラフィックがALBスロットリングをトリガーします。 次のいずれかの方法を使用して、問題をトラブルシューティングできます。
CloudMonitorコンソールで1秒あたりのリクエスト数を表示します。 詳細については、「ALBモニタリングメトリクス」および「ALBインスタンスに関するモニタリング情報の表示」をご参照ください。
CloudMonitorは、モニタリングデータを分レベルで表示します。 アクセスログを使用して、1秒あたりのリクエスト数を表示できます。 アクセスログのupstream_statusフィールドを表示します。 コンテンツが「-」の場合、リクエストはバックエンドサーバーに送信されません。
レスポンスヘッダーにALB-QPS-Limited:Limitedフィールドが含まれているかどうかを確認します。 そうである場合、要求がALBスロットリングをトリガしたことを示す。
クライアントは、ALBにアクセスするときにドメイン名を使用する代わりにALBインスタンスのIPアドレスにアクセスします。または、クライアントがドメイン名を使用してALBにアクセスするときにDNS解決結果を更新しません。 その結果、リクエストを複数のALB IPアドレスに分散することはできず、HTTP 503エラーコードが返されます。 クライアントは、IPアドレスではなくALBのドメイン名にアクセスすることを推奨します。 さらに、クライアントがALBにアクセスするためにDNSによって返された異なるIPアドレスを使用することを確認します。
バックエンドサーバーがALBリスナーに関連付けられていないか、バックエンドサーバーの重みが0に設定されています。
504 (ゲートウェイのタイムアウト)
バックエンドサーバーの応答がタイムアウトしました。
考えられる原因：
バックエンドサーバーから504ステータスコードが返された場合は、バックエンドサーバーがオーバーロードされているかどうかを確認します。
ALBからバックエンドサーバーへの接続がタイムアウトしました。 タイムアウト時間はデフォルトで5秒に設定されています。 アクセスログのupstream_connect_timeフィールドが5秒または約5秒に設定されているかどうかを確認できます。 レスポンスタイムアウトの原因を特定するために、パケットをキャプチャすることを推奨します。
バックエンドサーバーのワークロードは重く、応答を返すのに必要な時間は、指定されたタイムアウト期間よりも長くなります。 たとえば、リクエストタイムアウト時間は60秒に設定されます。 応答時間が60.001秒の場合、ALBはHTTP 504ステータスコードを返します。 CloudMonitorコンソールまたはアクセスログで、問題が発生した期間中のネットワーク待ち時間を表示できます。 ネットワーク遅延を表示するには、CloudMonitorのupstream_rtフィールド、またはアクセスログのupstream_response_timeフィールドを確認します。