CLB の状態コードの説明 - - Alibaba Cloud ドキュメントセンター

このトピックでは、クラシックロードバランサー (CLB) の一般的な状態コードとその考えられる原因について説明します。CLB インスタンスがエラー状態コードを返した場合、このトピックを参照して問題をトラブルシューティングしてください。

エラー状態コードを受け取った場合は、アクセスログの status フィールドと upstream_status フィールドを確認してください。これら 2 つのフィールドの値が同じである場合、エラーはバックエンドサーバーが原因である可能性が高く、CLB がバックエンドサーバーからの状態コードをそのまま渡していることを意味します。この場合、まずバックエンドサーバーを調査してください。status フィールドのみがエラーを示している場合、問題はクライアントに関連している可能性があります。

説明

問題をより迅速に診断するために、ご利用の CLB インスタンスのアクセスログを有効にしてください。詳細については、「アクセスログの設定」をご参照ください。

400 (Bad Request)

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

upstream_status コードの考えられる原因：

CLB は HTTP 経由でバックエンドサーバーにアクセスしますが、サーバーは HTTPS 用に設定されています。この問題を解決するには、次のいずれかの方法を使用できます：
- バックエンドサーバーが HTTP プロトコルを使用するように設定します。
- Application Load Balancer (ALB) インスタンスを使用し、バックエンドプロトコルとして HTTPS を使用するサーバーグループを作成します。詳細については、「サーバーグループの作成と管理」をご参照ください。
リクエストは CLB の検証を通過しましたが、バックエンドサーバーのカスタム検証ロジックによって拒否されました。バックエンドサーバーがリクエストパケットの検証に失敗した原因を調査してください。

status コードの考えられる原因：

バックエンドサーバーが 400 状態コードを返し、CLB がそれをクライアントにそのまま渡します。バックエンドサーバーが 400 状態コードを返す原因を調査してください。
クライアントのリクエストに含まれる HTTP ヘッダーのフォーマットが無効です。例えば、Content-Length が実際の本文の長さと一致しない、リクエストメソッドが大文字でない、または HTTP リクエストが HTTPS サービスに送信された、などです。クライアント側のパケットをキャプチャして分析し、リクエストのフォーマットを有効なものと比較してください。
CLB インスタンスに HTTPS リスナーが追加されています。クライアントからの非 HTTPS リクエストに対して 400 状態コードが返された場合は、クライアントが HTTPS ポートに HTTP リクエストを送信したかどうかを確認してください。
クライアントが完全な HTTP リクエストを送信する前に接続を閉じました。パケットをキャプチャして、クライアントが切断している原因を調査してください。
CLB では、各 HTTP ヘッダーが 32 KB を超えないことが要求されます。この制限を超えると、CLB は 400 状態コードを返します。HTTP ヘッダーのサイズを小さくしてください。

405 (Method Not Allowed)

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

バックエンドの状態コード (upstream_status) の考えられる原因：バックエンドサーバーが、クライアントリクエストで使用されたメソッドをサポートしていません。クライアントが使用したメソッドがバックエンドサーバーでサポートされているメソッドと一致するかどうかを調査することを推奨します。例えば、バックエンドサーバーで curl -X method ip:port コマンドを実行して、特定のメソッドをサポートしているかどうかをテストします。このコマンドで、method はクライアントリクエストで使用されたメソッド、ip はバックエンドサーバーの IP アドレス、port はバックエンドサーバーのポートです。

status コードの考えられる原因：

CLB は TRACE リクエストメソッドをサポートしていません。別のメソッドを使用してください。
バックエンドサーバーが 405 状態コードを返し、CLB がそれをクライアントにそのまま渡します。バックエンドサーバーが 405 状態コードを返す原因を調査してください。

408 (Request Timeout)

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

status コードの考えられる原因：

クライアントから CLB へのリクエストタイムアウト期間である 60 秒が経過する前に、クライアントが HTTP ヘッダーのみで本文がないなど、部分的なデータしか送信しませんでした。パケットをキャプチャして、クライアント側のパフォーマンスボトルネックやその他の異常な動作を確認してください。
クライアントから CLB へのネットワークリンクに、高い TCP ラウンドトリップタイム (RTT) やパケットロスなどの問題があります。アクセスログの request_time フィールドと tcpinfo_rtt フィールドを確認するか、パケットをキャプチャしてネットワークの異常を確認してください。
CLB インスタンスへのトラフィックが多すぎて帯域幅調整がトリガーされ、接続がドロップされます。CloudMonitor でインスタンスの アウトバウンド帯域幅 と ドロップされた接続 のメトリックを確認してください。詳細については、「CLB インスタンスのモニタリングデータの表示」をご参照ください。

414 (URI Too Long)

クライアントリクエストの URI がバックエンドサーバーで処理できる長さを超えているため、CLB はリクエストを拒否しました。

upstream_status コードの考えられる原因：バックエンドサーバーが 414 状態コードを返します。この問題を解決するには、次のいずれかの方法を使用できます：

URI を短くするか、POST メソッドを使用してデータを送信します。
バックエンドサーバーの最大 URI 長の制限を増やします。

status コードの考えられる原因：

バックエンドサーバーが 414 状態コードを返し、CLB がそれをクライアントにそのまま渡します。バックエンドサーバーが 414 状態コードを返す原因を調査してください。
CLB へのリクエストの最大 URI 長は 32 KB です。この制限を超えると、CLB は 414 状態コードを返します。URI を短くしてください。データ量が大きい場合は、POST メソッドを使用してデータを送信してください。

499 (Client closed request)

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

status コードの考えられる原因：

クライアントから CLB へのネットワークリンクに、高いラウンドトリップタイム (RTT) やパケットロスなどの問題があります。アクセスログの request_time フィールドと tcpinfo_rtt フィールドを確認するか、パケットをキャプチャしてネットワークの異常を確認してください。
CLB インスタンスへのトラフィックが多すぎて帯域幅調整がトリガーされ、接続がドロップされます。CloudMonitor でインスタンスの アウトバウンド帯域幅 と ドロップされた接続 のメトリックを確認してください。詳細については、「CLB インスタンスのモニタリングデータの表示」をご参照ください。
バックエンドサーバーがリクエストの処理に時間がかかりすぎ、クライアントのリクエストタイムアウト期間を超えました。アクセスログの upstream_response_time フィールドは、バックエンドサーバーの処理時間を表します。バックエンドサーバーの CPU、メモリ、またはネットワークに関連するパフォーマンスボトルネックを確認してください。
クライアントで設定されたリクエストタイムアウト期間が短すぎるため、クライアントは HTTP リクエストが完全に送信される前に接続を閉じます。アクセスログの request_time フィールドは、合計リクエスト時間を表します。この値を参考にして、クライアントで適切なリクエストタイムアウト期間を設定してください。
クライアントで不明な問題が発生し、HTTP リクエストが完了する前に接続を閉じました。クライアントの動作を調査して、接続を早期に閉じているかどうかを判断してください。

500 (Internal Server Error)

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

upstream_status コードの考えられる原因：バックエンドサーバーが 500 状態コードを返します。バックエンドサーバーのエラーログなどのツールを使用して、エラーの原因を調査してください。

status コードの考えられる原因：

バックエンドサーバーが 500 状態コードを返し、CLB がそれをクライアントにそのまま渡します。バックエンドサーバーが 500 状態コードを返す原因を調査してください。
バックエンドサーバーが完全な応答を送信する前に異常に接続を閉じました。バックエンドサーバーでパケットをキャプチャして、接続が閉じられた原因を調査してください。

502 (Bad Gateway)

HTTP または HTTPS リスナーがクライアントリクエストを受信したものの、バックエンドサーバーに転送できない、またはバックエンドサーバーから応答を受信できない場合、CLB は 502 Bad Gateway 状態コードを返します。

upstream_status コードの考えられる原因：

CLB とバックエンドサーバー間で TCP 通信エラーが発生しています。バックエンドサーバーが期待どおりに実行されているか、またそのサービスポートが正しくリッスンしているかどうかを確認します。パケットをキャプチャして TCP ハンドシェイクが成功しているかを確認することもできます。
バックエンドサーバーが過負荷で応答に失敗しています。例えば、サーバーのバックログキューがいっぱいになり、パケットがドロップされます。netstat コマンドを使用して、バックエンドサーバーのネットワーク統計でドロップ数を確認します。
クライアントから送信されたパケットが、バックエンドサーバーの最大伝送単位 (MTU) を超えています。これは、ヘルスチェックや小さいパケットは成功するが、大きいパケットは失敗するという形で現れることがあります。バックエンドサーバーでパケットをキャプチャして、パケットサイズが許容範囲内であるかどうかを分析してください。
バックエンドサーバーからの応答パケットのフォーマットが無効であるか、不正な HTTP ヘッダーが含まれています。バックエンドサーバーでパケットをキャプチャして、HTTP フォーマットが正しいことを確認してください。
バックエンドサーバーが時間内にリクエストを処理しませんでした。対応するバックエンドサーバーのログと、CPU やメモリなどのリソース使用率を確認してください。

status コードの考えられる原因：

バックエンドサーバーが 502 状態コードを返し、CLB がそれをクライアントにそのまま渡します。バックエンドサーバーが 502 状態コードを返す原因を調査してください。
バックエンドサーバーは 504 や 444 などの異なるエラー状態コードを返しますが、CLB は一律に 502 状態コードを返します。アクセスログの upstream_status フィールドと status フィールドを確認するか、パケットをキャプチャしてバックエンドサーバーの異常を調査してください。
サーバーグループ内のすべてのバックエンドサーバーのヘルスチェックが失敗します。その結果、関連付けられた CLB インスタンスはリクエストを転送できず、502 状態コードを返します。リスナーのヘルスチェックが正常であるかどうかを確認してください。詳細については、「ヘルスチェックに関するよくある質問」をご参照ください。

503 (Service Temporarily Unavailable)

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

upstream_status コードの考えられる原因：バックエンドサーバーが 503 状態コードを返します。バックエンドサーバーのログなどのツールを使用して、エラーの原因を調査してください。

status コードの考えられる原因：

バックエンドサーバーが 503 状態コードを返し、CLB がそれをクライアントにそのまま渡します。バックエンドサーバーが 503 状態コードを返す原因を調査してください。
リクエストトラフィックが CLB インスタンスのレート制限を超えました。CLB インスタンス仕様の詳細については、「CLB インスタンスの概要」をご参照ください。この問題を解決するには、次のいずれかの方法を使用できます：
- インスタンス仕様をアップグレードします。詳細については、「従量課金 CLB インスタンスの設定変更」をご参照ください。
- Alibaba Cloud DNS を使用してドメイン名を複数の CLB インスタンスにマッピングし、容量をスケールアウトします。
- より多くの同時接続 (レイヤー 4) には Network Load Balancer (NLB) インスタンスを、より高い秒間クエリ数 (QPS) (レイヤー 7) には ALB インスタンスを使用します。詳細については、「ALB とは」および「NLB とは」をご参照ください。
CLB インスタンスのパフォーマンスメトリックは、次の 2 つの方法で確認できます：
- CloudMonitor でインスタンスの 秒間クエリ数 (QPS) メトリックを表示します。詳細については、「CLB インスタンスのモニタリングデータの表示」をご参照ください。
- CloudMonitor は 1 分の粒度でデータを表示するため、秒単位の速度制限をキャプチャできない場合があります。アクセスログを確認して、1 秒あたりのリクエスト数を表示できます。upstream_status フィールドがハイフン (-) の場合、リクエストがバックエンドサーバーに送信されなかったことを示します。
CLB リスナーにバックエンドサーバーが設定されていないか、設定されているすべてのバックエンドサーバーの重みが 0 に設定されています。

504 (Gateway Timeout)

バックエンドサーバーの応答がタイムアウトしました。

upstream_status コードの考えられる原因：バックエンドサーバーが 504 状態コードを返します。バックエンドサーバーが他の内部サービスにアクセスする際にタイムアウトしていないか確認してください。

status コードの考えられる原因：

バックエンドサーバーが 504 状態コードを返し、CLB がそれをクライアントにそのまま渡します。バックエンドサーバーが 504 状態コードを返す原因を調査してください。
バックエンドサーバーへの接続がタイムアウトしました。バックエンドサーバーのデフォルトの接続タイムアウト期間は 5 秒です。アクセスログの upstream_connect_time フィールドの値が 5 秒または約 5 秒であるかどうかを確認してください。パケットをキャプチャして、接続タイムアウトの原因を調査してください。
バックエンドサーバーの負荷が増加し、応答時間が設定されたリクエストタイムアウト期間よりも長くなっています。例えば、リクエストタイムアウト期間が 60 秒に設定されていて、応答時間が 60.001 秒の場合、CLB は 504 状態コードを返します。問題が発生した期間のレイテンシーを CloudMonitor またはアクセスログで確認してください。CloudMonitor では upstream_rt メトリックを確認します。アクセスログでは upstream_response_time フィールドを確認します。