Server Load Balancer:ALB エラー状態コード

バックエンドサーバーが直接 400 状態コードを返す：アクセスログを確認します。upstream_status フィールドの値が 400 の場合、ALB はバックエンドサーバーから受け取った状態コードをそのままクライアントに渡しています。バックエンドサービスをトラブルシューティングしてください。

HTTP リクエストが HTTPS リスナーに送信される：ALB インスタンスの HTTPS リスナーは非 HTTPS リクエストを拒否し、400 状態コードを返します。クライアントが HTTPS ポートに HTTP リクエストを送信していないか確認してください。

リクエストヘッダーのサイズが制限を超える：ALB では、各 HTTP リクエストヘッダーのサイズが 32 KB を超えてはなりません。この制限を超えた場合、ALB は 400 状態コードを返します。リクエストヘッダーのサイズを小さくしてください。

リクエストが完全に送信されない：HTTP リクエストが完全に送信される前にクライアントが接続を閉じました。クライアント側でパケットキャプチャを行い、早期切断の原因を特定してください。

リクエストヘッダーが不正な形式である：たとえば、Content-Length ヘッダーの値がリクエスト本文の実際のサイズと一致していません。クライアント側でパケットキャプチャを行い、HTTP リクエストのフォーマットを分析し、有効なリクエストと比較してください。

ALB の制限：ALB は TRACE リクエストメソッドをサポートしていません。別のメソッドを使用してください。

バックエンドサービスの制限：TRACE を除き、他のリクエストメソッドのサポートはバックエンドサーバーに依存します。確認するには、次のコマンドを実行してバックエンドサーバーに直接接続テストを行ってください：curl -X METHOD http://<Backend-Server-IP>:<Port>。ここで METHOD はクライアントが使用しているリクエストメソッドです。

クライアントからの遅いデータ送信: クライアントから ALB へのリクエストタイムアウト期間（デフォルトは 60 秒）内に、クライアントが部分的なデータのみを送信する場合があります。たとえば、Request Header は送信されるが、Request Body は送信されないといった状況です。パフォーマンスボトルネックやその他のエラーを確認するために、クライアントでパケットをキャプチャします。

クライアントと ALB 間のネットワーク品質が不良：TCP 往復時間（RTT）が長いか、ネットワーク上でパケット損失が発生しています。アクセスログの request_time フィールドおよび tcpinfo_rtt フィールドを確認するか、クライアント側でネットワーク診断を実行してください。

ALB インスタンスでの帯域幅速度制限：ALB インスタンスへのトラフィックが帯域幅制限を超え、速度制限とパケット損失が発生しています。CloudMonitor を使用して、アウトバウンド帯域幅 および Dropped Connections メトリックを確認してください。

ALB の制限：ALB ではリクエスト URI の長さが 32 KB を超えてはなりません。この制限を超えた場合、ALB は 414 状態コードを返します。URI を短縮してください。大量のデータを転送する必要がある場合は、POST メソッドを使用し、データをリクエスト本文に配置します。ALB は最大 50 GB の POST リクエスト本文をサポートしています。

バックエンドサービスの制限：URI は ALB の制限を超えていませんが、バックエンドサービスに設定されたより厳しい制限を超えています。このシナリオでは、ALB はバックエンドサーバーから返された 414 状態コードをそのまま渡します。バックエンドサービスをトラブルシューティングしてください。

バックエンドサービスの誤った構成：バックエンドサービスの誤った構成により、リクエストが同じ ALB インスタンスに再びルーティングされ、ループが発生しています。ALB インスタンス用のバックエンドサービス構成を確認・修正してください。

ネットワークアーキテクチャ設計の欠陥：たとえば、単一のリクエストパスに複数のロードバランサーインスタンスが関与しています。ネットワークアーキテクチャを最適化してください。

クライアントと ALB 間のネットワーク品質が不良：TCP 往復時間（RTT）が長いか、ネットワーク上でパケット損失が発生しています。アクセスログの request_time フィールドおよび tcpinfo_rtt フィールドを確認するか、クライアント側でネットワーク診断を実行してください。

ALB インスタンスでの帯域幅速度制限：ALB インスタンスへのトラフィックが帯域幅制限を超え、速度制限とパケット損失が発生しています。CloudMonitor を使用して、アウトバウンド帯域幅 および Dropped Connections メトリックを確認してください。

バックエンドサービスのリクエスト処理に時間がかかりすぎる：バックエンドサービスの処理時間がクライアントのタイムアウト設定を超えています。アクセスログの upstream_response_time フィールド（バックエンドサービスのリクエスト処理時間を記録）を確認してください。この値が常に高い場合は、バックエンドサービスにパフォーマンスボトルネックがないか調査してください。

クライアントのリクエストタイムアウトが短すぎる：リクエストが完了する前にタイムアウトによりクライアントが接続を閉じています。アクセスログの request_time フィールド（クライアントリクエストの合計持続時間を表す）を確認し、この値を参考にしてクライアント側のタイムアウトをより適切な値に設定してください。

クライアントに不明な問題が発生：リクエストが完了する前にクライアントが意図せず接続を早期に閉じています。クライアントの動作を調査し、意図的に接続を早期に閉じているかどうかを確認してください。

バックエンドサーバーが直接 500 状態コードを返す：アクセスログを確認します。upstream_status フィールドが 500 の場合、ALB はバックエンドサーバーから受け取った状態コードをそのままクライアントに渡しています。バックエンドサービスをトラブルシューティングしてください。

バックエンドサーバーが予期せず接続を閉じる：バックエンドサーバーが完全な応答を送信する前に予期せず接続を閉じました。バックエンドサーバー側でパケットキャプチャを行い、予期しない接続切断の原因を調査してください。

バックエンドサーバーが直接 502 状態コードを返す：アクセスログを確認します。upstream_status フィールドが 502 の場合、ALB はバックエンドサーバーから受け取った状態コードをそのままクライアントに渡しています。バックエンドサービスをトラブルシューティングしてください。

バックエンドサーバーが異なるエラーコードを返す：たとえば、バックエンドサーバーが 504 または 444 状態コードを返しているにもかかわらず、ALB がクライアントに 502 状態コードを返しています。アクセスログの status フィールドと upstream_status フィールドを比較し、バックエンドサーバーが実際に返した状態コードに基づいて問題をトラブルシューティングしてください。

ALB とバックエンドサーバー間の TCP 通信エラー：バックエンドサービスが実行中であること、サービスポートが正しくリッスンしていること、TCP ハンドシェイクが成功することを確認してください。パケットキャプチャを使用して TCP ハンドシェイクを分析できます。

バックエンドサーバーのバックログキューがいっぱいになり、新しい接続リクエストが拒否または破棄されています。バックエンドサーバーでコマンド netstat -s | grep -i listen を実行し、増加している drop カウンターを確認してください。

リクエストパケットサイズがバックエンドサーバーの MTU を超える：これは、ヘルスチェックなどの小さいパケットは正常に配信されるが、大きなデータパケットが失敗するという形で現れる可能性があります。バックエンドサーバー側でパケットキャプチャを行い、パケット長が必要な制限内にあるかどうかを分析してください。

バックエンドサーバーの応答が不正な形式である、または無効な HTTP ヘッダーを含む：バックエンドサーバー側でパケットキャプチャを行い、応答パケットのフォーマットが有効かどうかを分析してください。

バックエンドサーバーがリクエストをタイムリーに処理しなかった：バックエンドサーバーのログを確認し、CPU およびメモリ使用率をモニターしてください。

バックエンドサーバーが直接 503 状態コードを返す：アクセスログを確認します。upstream_status フィールドが 503 の場合、ALB はバックエンドサーバーから受け取った状態コードをそのままクライアントに渡しています。バックエンドサービスをトラブルシューティングしてください。

クライアントのリクエストレートが ALB の速度制限をトリガー：

• CloudMonitor の Requests per second メトリックを確認してください。

• CloudMonitor は 1 分単位の粒度でデータを表示するため、秒単位のレート制限を検出できない場合があります。アクセスログを確認してください。upstream_status フィールドの値が - の場合、リクエストはバックエンドサーバーに送信されていません。

• 応答パケットヘッダーを確認してください。ALB-QPS-Limited:Limited フィールドが含まれている場合、そのリクエストは ALB インスタンスの速度制限をトリガーしています。

クライアントが ALB IP に直接アクセスしている、または DNS 解決に失敗している：これにより、トラフィックが少数の IP アドレスに集中し、それらの制限を超えてしまう可能性があります。クライアントは ALB インスタンスにドメイン名経由でアクセスする必要があります。詳細については、「ALB インスタンスの CNAME レコードの設定」をご参照ください。CNAME 解決が正しく機能していることを確認してください。

リスナーにバックエンドサーバーが設定されていない、または設定されているすべてのバックエンドサーバーの重みが 0 です。

バックエンドサーバーが直接 504 状態コードを返す：アクセスログを確認します。upstream_status フィールドが 504 の場合、ALB はバックエンドサーバーから受け取った状態コードをそのままクライアントに渡しています。バックエンドサービスをトラブルシューティングしてください。

ALB からバックエンドサーバーへの接続試行がタイムアウト：接続確立のタイムアウトは 5 秒で、変更できません。バックエンドサーバーが 5 秒のタイムアウト内に接続試行に応答しない理由を調査するために、パケットキャプチャを実行してください。

バックエンドサーバーの応答がタイムアウト：接続リクエストタイムアウト のデフォルト値は 60 秒です。CloudMonitor の UpstreamResponseTime メトリックおよびアクセスログの upstream_response_time フィールドを確認し、バックエンドサーバーの応答がタイムアウトしたかどうかを判断してください。