ALB のエラーステータスコード - Server Load Balancer - Alibaba Cloud ドキュメントセンター

ALB からの HTTP エラーを迅速にトラブルシューティングするには、ALB アクセスログを有効にすることをお勧めします。まず、アクセスログで ALB ステータスコード (status フィールド) とバックエンドステータスコード (upstream_status フィールド) を比較します。値が同じ場合、ALB がバックエンドサーバーからステータスコードを渡した可能性が高いと考えられます。この場合、バックエンドサービスのトラブルシューティングを優先してください。

5 つのクイックチェック

ステータスコードによるトラブルシューティングの前に、まずこれらの 5 つのチェックを実行してください。これらは、ALB の障害で最も一般的な根本原因に対応しています。

ALB インスタンス診断ツールを実行します。インスタンス ページで、対象のインスタンスを見つけます。インスタンスの診断 列で診断をクリックすると、インスタンス設定、リスナー、およびバックエンドサービスに関する一般的な問題をワンクリックでチェックできます。
リスナーの ヘルスチェックステータス が正常 であることを確認します。 リスナーの詳細 ページで、バックエンドサーバーグループの ヘルスチェックステータス を確認します。ステータスが異常の場合は、「ALB ヘルスチェックの失敗のトラブルシューティング」をご参照ください。
バックエンド ECS が、ALB インスタンスが配置されている VSwitch の CIDR ブロックをブロックしないようにしてください。 ALB は、その VSwitch によって割り当てられた Local IP を使用してバックエンドサーバーと通信します。バックエンド ECS インスタンス上の iptables ルールまたはサードパーティのセキュリティソフトウェアが VSwitch の CIDR ブロックをブロックすると、ALB はバックエンドに到達できなくなり、502 や 504 などのエラーを引き起こす可能性があります。
サーバーグループのバックエンドサーバーに設定されているポートが、バックエンドサービスが実際にリッスンしているポートと一致することを確認します。ALB サーバーグループの各バックエンドサーバーに設定されているポートは、アプリケーションプロセスがリッスンしているポートと一致する必要があります。たとえば、サーバーグループでポートが 8080 として設定されているにもかかわらず、バックエンドサービスがポート 80 でリッスンしている場合、接続は失敗します。バックエンド ECS で ss -tlnp | grep ':<port> ' または netstat -tlnp | grep ':<port> ' を実行して確認できます。
HTTPS リスナーの場合、証明書の有効期限が切れていないこと、およびそのドメインがアクセスドメインと一致することを確認してください。リスナーの詳細 ページで、バインドされた証明書とその有効期限を確認してください。有効期限切れの証明書やドメインの不一致は、SSL ハンドシェイクの失敗、またはエラーステータスコードが返される原因となる場合があります。

502 Bad Gateway

このエラーは、HTTP または HTTPS リスナーがクライアントリクエストを受信したものの、ALB がリクエストをバックエンドサーバーに転送できなかったり、バックエンドサーバーからレスポンスを受信できなかったりした場合に発生します。

トラブルシューティング方法：まず、アクセスログの upstream_status フィールドの値を確認し、次の手順を判断します。

もし upstream_status = 502 であれば： ALB はバックエンドサーバーから 502 ステータスコードをパススルーしたことを意味します。問題はバックエンドサービス自体にあります。バックエンドサービスを調査してください。例えば、バックエンドの Nginx またはゲートウェイレイヤーが到達不能なアップストリームにリバースプロキシしようとしているかどうかを確認してください。
もし upstream_status が別の値の場合 (504、444、または 500 など): ALB がクライアントに返す status は upstream_status とは異なり、ALB がステータスコードを変更したことを意味します。バックエンドの Nginx、ゲートウェイ、またはアプリケーションログを確認し、バックエンドサービスがその特定のステータスコードを返している理由を調査してください。
もし upstream_status が - または空の場合: ALB はバックエンドからレスポンスを受信していません。これは、リクエストがバックエンドに到達しなかったか、またはレスポンスが送信される前にバックエンド接続が異常終了したことを意味します。以下の原因を順番に確認してください。
- ALB とバックエンドサーバー間の TCP 通信が失敗しています。バックエンドサービスが稼働していること、サービスポートが正しくリッスンしていること、およびバックエンド ECS 上の iptables ルールやサードパーティのセキュリティソフトウェアが、ALB インスタンスが配置されている VSwitch の CIDR ブロックをブロックしていないことを確認してください。ALB は、VSwitch によって割り当てられたLocal IP を使用してバックエンドサーバーと通信します。パケットをキャプチャして、TCP ハンドシェイクが成功しているかどうかを確認できます。
- バックエンドサーバーのバックログがいっぱいです。これにより、サーバーは新しい接続リクエストをドロップします。バックエンドサーバーで netstat -s | grep -i listen を実行し、drop カウンターを確認します。
- バックエンドサーバーが時間内にリクエストを処理できませんでした。バックエンドサーバーのログを確認し、CPU とメモリの使用率をレビューして、パフォーマンスのボトルネックを特定してください。
- クライアントリクエストのパケットサイズがバックエンドサーバーの MTU を超えています。これにより、ヘルスチェックなどの短いパケットは成功するものの、長いパケットは失敗する可能性があります。バックエンドサーバーでパケットキャプチャを実行し、パケット長が必要な制限内であるか分析してください。
- バックエンドサーバーのレスポンスのフォーマットが無効、または無効な HTTP ヘッダーが含まれています。バックエンドサーバーでパケットキャプチャを実行し、レスポンスフォーマットが標準に準拠しているか分析してください。

400 Bad Request

リクエストのフォーマットが無効です。

バックエンドが直接 400 を返す：アクセスログを確認します。upstream_status が 400 の場合、ALB がバックエンドからのステータスコードをパススルーした可能性が高いです。バックエンドサービスを調査してください。
HTTPS リスナーに HTTP リクエストが送信される：ALB HTTPS リスナーは、HTTPS ではないリクエストを拒否し、400 ステータスコードを返します。クライアントが誤って HTTP リクエストを HTTPS ポートに送信していないか確認してください。
リクエストヘッダーのサイズが制限を超えている: ALB では、各 HTTP リクエストヘッダーを 32 KB 以下にする必要があります。この制限を超えると、ALB は 400 ステータスコードを返します。リクエストヘッダーのサイズを削減してください。
クライアントが完全なリクエストを送信しなかった：クライアントは、完全な HTTP リクエストを送信する前に接続を閉じました。クライアントでパケットキャプチャを実行し、原因を特定してください。
リクエストヘッダーの形式が無効です：たとえば、Content-Lengthの値がリクエストボディの実際の長さと一致しません。クライアントでパケットをキャプチャし、HTTP リクエストの形式を分析して、有効なリクエストと比較してください。

405 Method Not Allowed

リクエストメソッドがサポートされていません。

ALB の制限: ALB は TRACE リクエストメソッドをサポートしていません。別のメソッドを使用してください。
バックエンドサービスの制限: TRACE を除き、他のリクエストメソッドがサポートされているかどうかは、バックエンドサーバーに依存します。確認するには、curl -X METHOD http://<backend_service_IP>:<service_port> を実行します。ここで、METHOD はクライアントが使用するリクエストメソッドです。

408 Request Timeout

リクエストがタイムアウトし、ALB が接続を閉じます。

クライアントのデータ送信が遅い: クライアントから ALB へのリクエストタイムアウト期間 (デフォルト: 60 秒) 内に、クライアントが HTTP Header のみを送信して HTTP Body を送信しないなど、データの一部のみを送信するケースです。クライアントでパケットをキャプチャし、パフォーマンスのボトルネックやその他の問題がないか確認してください。
クライアントと ALB 間のネットワーク品質が悪い：TCP ラウンドトリップタイム (RTT) が高いか、パケットロスなどの他のネットワーク問題が発生しています。アクセスログの request_time フィールドと tcpinfo_rtt フィールドを確認するか、クライアントでネットワーク診断を実行することをお勧めします。
ALB インスタンスの帯域幅スロットリング: ALB インスタンスへのトラフィックが多いために、帯域幅のスロットリングとパケットロスが発生しています。Cloud Monitor で outbound bandwidth および Dropped Connections メトリクスを確認してください。

414 URI Too Long

リクエスト URI の長さが制限を超えているため、ALB またはバックエンドサーバーがリクエストを拒否しました。

ALB の制限: ALB では、リクエスト URI を 32 KB 以下にする必要があります。そうでない場合、414 ステータスコードが返されます。 URI を短くしてください。大量のデータを送信する場合は、POST メソッドを使用して、リクエストボディにデータを含めることができます。 ALB は、最大 50 GB の POST リクエストボディをサポートします。
バックエンドサービスの制限: URI の長さが ALB の制限を超えていないものの、バックエンドサービスにさらに厳しい制限がある場合、ALB はバックエンドから返された 414 ステータスコードをパススルーします。バックエンドサービスを調査してください。

463

463 ステータスコードは、リスナーが IP タイプのサーバーグループに関連付けられている場合にのみ返されます。

リクエストパスにループが存在します。リクエストが ALB を通過すると、システムは HTTP ヘッダー に ALICLOUD-ALB-TRACE フィールドを追加します。このフィールド値は、ルール ID から生成された 16 文字のハッシュです。重複するルール ID が検出された場合、または ALICLOUD-ALB-TRACE フィールドの数が 16 を超えた場合、ALB はループと判断します。ALB はネットワークストームを防ぐためにリクエストの転送を停止し、463 ステータスコードを返します。

バックエンドサービスの設定ミス：バックエンドサービスが誤って設定されており、リクエストをループで ALB に送り返しています。ALB のバックエンドサービス設定を確認してください。
ネットワークアーキテクチャの欠陥：たとえば、単一リクエストの転送パスに複数のロードバランシングインスタンスが存在する場合などです。ネットワークアーキテクチャを最適化することを推奨します。

499 Client Closed Request

クライアントが接続を能動的に閉じました。

クライアントと ALB 間のネットワーク品質が悪い: TCP RTT が高いか、パケットロスなどの他のネットワーク問題が発生しています。アクセスログの request_time フィールドと tcpinfo_rtt フィールドを確認するか、クライアントでネットワーク診断を実行することをお勧めします。
ALB インスタンスの帯域幅スロットリング: ALB インスタンスへのトラフィックが多いため、帯域幅スロットリングとパケットロスが発生しています。Cloud Monitor で outbound bandwidth および Dropped Connections メトリックを確認してください。
長いバックエンド処理時間: バックエンドの処理時間がクライアントのタイムアウト期間を超過しました。バックエンドの処理時間を示すアクセスログ内の upstream_response_time フィールドを確認してください。この値が一貫して高い場合は、バックエンドサービスでパフォーマンスのボトルネックがないか調査してください。
クライアントリクエストのタイムアウトが短すぎます: クライアントがリクエストの送信を完了する前にタイムアウトになり、接続を閉じました。アクセスログの request_time フィールドで合計リクエスト時間を確認し、この値を参考にして、より適切なクライアント側のリクエストタイムアウトを設定してください。
クライアントで未知の問題が発生した：クライアントは、リクエストが完了する前に接続を閉じました。クライアント側で、早期に接続が切断される原因となる動作がないか調査してください。

500 Internal Server Error

バックエンドサーバーで内部エラーが発生し、リクエストを処理できませんでした。

バックエンドが直接 500 を返す: アクセスログを確認します。 upstream_status が 500 の場合、ALB はバックエンドのステータスコードをパススルーしたと考えられます。バックエンドサービスを調査してください。
バックエンドサーバーが予期せず接続を閉じた：バックエンドサーバーは、完全なレスポンスを送信する前に接続を閉じました。バックエンドサーバーでパケットキャプチャを実行し、予期しない接続切断の原因を特定してください。

503 Service Temporarily Unavailable

サーバーは一時的に利用できません。通常、トラフィックが制限を超えたか、バックエンドサービスが利用できないことが原因です。

バックエンドが 503 を直接返す：アクセスログを確認してください。upstream_status が 503 の場合、ALB がバックエンドからのステータスコードをパススルーした可能性が高いです。バックエンドサービスを調査してください。
クライアントリクエストが ALB のスロットリングをトリガーする：
- Cloud Monitor で、Requests per second メトリックを確認します。
- Cloud Monitor は分単位のデータを表示し、秒単位のスパイクを反映しない場合があります。アクセスログを確認してください。upstream_status フィールドが - の場合、リクエストはバックエンドサーバーに到達していません。
- レスポンスパケットヘッダーを確認します。ヘッダーに ALB-QPS-Limited:Limited フィールドが含まれている場合、リクエストが ALB のスロットリングをトリガーしたことを示します。
直接 IP アクセスまたは異常な DNS 名前解決：これにより、トラフィックが少数の IP アドレスに集中し、スロットリングがトリガーされる可能性があります。ドメイン名を使用して ALB にアクセスし (「ALB インスタンスの CNAME の設定」をご参照ください)、DNS 名前解決が期待どおりに機能することを確認してください。
リスナーにバックエンドサーバーが設定されていないか、設定されているバックエンドサーバーの重みが 0 です。

504 Gateway Timeout

ALB がバックエンドサーバーからのレスポンスを待機中にタイムアウトしました。

バックエンドが直接 504 を返す：アクセスログを確認します。upstream_status が 504 の場合、ALB はバックエンドからのステータスコードをパススルーしたと考えられます。バックエンドサービスを調査してください。
ALB からバックエンドサーバーへの接続試行がタイムアウトする: このタイムアウトはデフォルトで 5 秒で、変更できません。パケットをキャプチャして、バックエンドサーバーが時間内に応答しない理由を特定します。
バックエンドの応答タイムアウト：接続リクエストのタイムアウトは、デフォルトで 60 秒です。バックエンドサーバーの応答がタイムアウトしたかどうかは、Cloud Monitor の UpstreamResponseTime メトリクスと、アクセスログの upstream_response_time フィールドで確認できます。