Server Load Balancer:ALB エラーステータスコード

5つのクイックチェック

ステータスコード別にトラブルシューティングを行う前に、まず次の5つの項目を確認してください。これらは ALB 障害における最も一般的な根本原因です。

1. ALB インスタンス診断ツールを実行します。 インスタンス ページで対象のインスタンスを見つけ、インスタンスの診断 列で 診断 をクリックし、インスタンス設定、リスナー、およびバックエンドサービスに関する一般的な問題のワンクリックチェックを実行します。

2. リスナーの ヘルスチェックステータス が 正常 であることを確認します。 リスナーの詳細 ページで、バックエンドサーバーグループの ヘルスチェックステータス を確認します。 ステータスが 異常 の場合は、「ALB のヘルスチェックの失敗のトラブルシューティング」をご参照ください。

3. バックエンド ECS で、ALB インスタンスが配置されている VSwitch の CIDR ブロックがブロックされないようにしてください。 ALB は、その VSwitch によって割り当てられた Local IP を使用してバックエンドサーバーと通信します。 バックエンド ECS インスタンス上の iptables ルールまたはサードパーティのセキュリティソフトウェアによって VSwitch の CIDR ブロックがブロックされると、ALB はバックエンドに到達できなくなり、502 や 504 などのエラーが発生する可能性があります。

4. サーバーグループのバックエンドサーバーに設定されているポートが、バックエンドサービスが実際にリッスンしているポートと一致することを確認してください。 ALB サーバーグループの各バックエンドサーバーに設定されているポートは、アプリケーションプロセスがリッスンしているポートと一致する必要があります。 例えば、サーバーグループでポートが 8080 に設定されていても、バックエンドサービスがポート 80 でリッスンしている場合、接続は失敗します。 バックエンド ECS で ss -tlnp | grep ':<port> ' または netstat -tlnp | grep ':<port> ' を実行して確認できます。

5. 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 がバックエンドからのステータスコードをパススルーした可能性が高いです。バックエンドサービスを調査してください。

• HTTP リクエストが HTTPS リスナーに送信される: 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 で アウトバウンド帯域幅 と ドロップされた接続 のメトリクスを確認してください。

413 Request Entity Too Large

リクエストボディが大きすぎます。まず、アクセスログの upstream_status フィールドの値を確認し、413 ステータスコードが ALB によって返されたか、バックエンドサーバーから渡されたかを判断します。

• upstream_status = 413 の場合、バックエンドサーバーが 413 ステータスコードを返し、ALB がそれをそのまま転送したことを示します。 これは、より一般的なケースです。 これは通常、Nginx などのバックエンドプロキシサーバーで設定されたリクエストボディサイズの制限が原因です。 バックエンドサービスの関連設定 (たとえば Nginx の client_max_body_size パラメーター) を調査してください。

• もし upstream_status が - または空の場合: ALB は 413 ステータスコード自体を返します。これは、リクエストボディが ALB 自身のサイズ制限 (50 GB) を超えていることを意味します。このケースは稀です。クライアントリクエストボディのサイズを小さくすることを推奨します。

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 のバックエンドサービス設定を確認してください。

• ネットワークアーキテクチャの欠陥：たとえば、単一リクエストの転送パス上に複数の SLB インスタンスが存在するケースです。ネットワークアーキテクチャを最適化することを推奨します。

499 Client Closed Request

クライアントが接続をクローズしました。

• クライアントと ALB 間のネットワーク品質の低下: TCP RTT が高いか、パケットロスなどの他のネットワーク問題が発生しています。アクセスログの request_time および tcpinfo_rtt フィールドを確認するか、クライアントでネットワーク診断を実行することをお勧めします。

• ALB インスタンスの帯域幅スロットリング：ALB インスタンスへの大量のトラフィックにより、帯域幅のスロットリングとパケットロスが発生しています。Cloud Monitor で アウトバウンド帯域幅 と ドロップされた接続 のメトリクスを確認してください。

• バックエンド処理時間が長い：バックエンドの処理時間がクライアントのタイムアウト期間を超過しました。アクセスログの 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 フィールドを確認することで判断できます。