CLBステータスコード - - Alibaba Cloud ドキュメントセンター

このトピックでは、Classic Load Balancer (CLB) の一般的なステータスコードと、考えられるステータスコードの原因について説明します。 CLBが異常なステータスコードを返した場合、異常なステータスコードの考えられる原因に基づいて問題をトラブルシューティングできます。

異常なステータスコードを受け取った場合は、アクセスログのstatusフィールドとupstream_statusフィールドをメモしてください。 statusフィールドとupstream_statusフィールドの値が同じ場合、異常なステータスコードがバックエンドサーバーから渡される可能性があります。バックエンドサーバーが異常なステータスコードを返す理由を確認することを推奨します。アクセスログにステータスフィールドのみが含まれている場合、異常なステータスコードはクライアントアクセスの問題が原因である可能性があります。

説明

CLBはアクセスログをサポートしています。アクセスログを有効にすると、より効率的に問題を特定できます。アクセスログを有効にする方法の詳細については、「アクセスログの設定」をご参照ください。

400 (悪い要求)

HTTPリクエストの形式が不正です。

upstream_statusフィールドの値が400の場合、考えられる原因

CLBはHTTPを使用してバックエンドサーバーにアクセスしますが、バックエンドサーバーはHTTPSを使用します。この問題を解決するには、次のいずれかの方法を使用することを推奨します。
- バックエンドサーバーのプロトコルをHTTPに変更します。
- Application Load Balancer (ALB) を使用し、HTTPSを使用するサーバーグループを作成します。詳細については、「サーバーグループの作成と管理」をご参照ください。
パケットはCLBインスタンスの検証に合格しますが、異なるロジックを使用するバックエンドサーバーの検証に失敗します。パケットがバックエンドサーバーの検証に失敗する理由を確認することを推奨します。

statusフィールドの値が400

バックエンドサーバーは400ステータスコードを返し、CLBはバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが400ステータスコードを返す理由を確認することを推奨します。
クライアント要求のHTTPヘッダーが無効な形式を使用しています。たとえば、コンテンツの長さがリクエスト本文の長さと異なる、リクエストメソッドが大文字化されていない、またはHTTPSサービスがHTTP経由でアクセスされている場合などです。クライアントでパケットをキャプチャし、HTTPリクエストを有効なHTTPリクエストと比較することを推奨します。
HTTPSリスナーがCLBインスタンスに追加されます。クライアントがHTTPSリクエストを送信せず、400ステータスコードが返された場合は、クライアントがHTTPSポートにHTTPリクエストを送信したかどうかを確認することを推奨します。
HTTPリクエストが送信される前に、クライアントは接続を閉じます。パケットをキャプチャし、切断の原因を特定することを推奨します。
CLBにはHTTPヘッダーが必要ですしない 32 KBを超えるサイズで。それ以外の場合、CLBは400ステータスコードを返します。 HTTPヘッダーの長さを調整することを推奨します。

405 (メソッドは許可されません)

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

upstream_statusフィールドの値が405の場合に考えられる原因: バックエンドサーバーは、クライアントが使用するリクエストメソッドをサポートしていません。リクエストメソッドがバックエンドサーバーで使用されているメソッドと一致するかどうかを確認することを推奨します。たとえば、特定のメソッドがバックエンドサーバーでサポートされているかどうかを確認するには、curl -X method ip:portコマンドを実行します。 methodはクライアントが使用するリクエストメソッドを指定し、ipはバックエンドサーバーのIPアドレスを指定し、portはバックエンドサーバーのポートを指定します。

statusフィールドの値が405

CLBはTRACEリクエストメソッドをサポートしていません。他の方法を使用することを推奨します。
バックエンドサーバーは405を返し、CLBはバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが405を返す理由を確認することを推奨します。

408 (リクエストタイムアウト)

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

statusフィールドの値が408

リクエストタイムアウト期間中、リクエストの一部のみが送信され、CLBは接続を閉じます。たとえば、HTTPヘッダーのみが送信され、本文は送信されません。パケットをキャプチャして、クライアントにパフォーマンスのボトルネックやその他の異常な動作があるかどうかを確認することを推奨します。 CLBリスナーのリクエストタイムアウト期間を延長して、問題が解決できるかどうかを確認することもできます。詳細については、「CLB FAQ」をご参照ください。
クライアントとCLBインスタンス間の接続に問題があります。 TCPパケットのラウンドトリップタイム (RTT) が大きいか、パケットロスが発生します。アクセスログまたはキャプチャパケットのrequest_timeフィールドとtcpinfo_rttフィールドをチェックして、クライアントネットワークが異常であるかどうかを確認することを推奨します。
CLBインスタンスへのトラフィックが大きすぎるため、帯域幅の調整とパケット損失が発生します。 CloudMonitorを使用して、CLBインスタンスのアウトバウンド帯域幅とドロップされた接続数を確認することを推奨します。詳細については、「CLBインスタンスに関するモニタリング情報の表示」をご参照ください。

414 (URIが長すぎる)

クライアント要求のURI長がバックエンドサーバーでサポートされている長さを超えているため、CLBは要求を拒否します。

考えられる原因: upstream_statusフィールドの値が414の場合: バックエンドサーバーが414を返した場合、次のいずれかの方法でこの問題を解決することを推奨します。

URIを短くし、POSTメソッドを使用してデータを送信します。
バックエンドサーバーでサポートされているクライアント要求のURI長を増やします。

statusフィールドの値が414

バックエンドサーバーは414を返し、CLBはバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが414を返す理由を確認することを推奨します。
CLBへのリクエストのURIのサイズは32 KBを超えることはできません。リクエストのURIが32 KBを超える場合、414ステータスコードが返されます。 URIを短くすることを推奨します。送信するデータ量が多い場合は、POSTメソッドを使用してデータを送信することを推奨します。

499 (クライアントクローズ要求)

クライアントは接続を閉じます。

statusフィールドの値が499

クライアントとCLBインスタンス間の接続に問題があります。 RTTが大きいか、パケットロスが発生します。アクセスログまたはキャプチャパケットのrequest_timeフィールドとtcpinfo_rttフィールドをチェックして、クライアントネットワークが異常であるかどうかを確認することを推奨します。
CLBインスタンスへのトラフィックが大きすぎるため、帯域幅の調整とパケット損失が発生します。 CloudMonitorを使用して、CLBインスタンスのアウトバウンド帯域幅とドロップされた接続数を確認することを推奨します。詳細については、「CLBインスタンスに関するモニタリング情報の表示」をご参照ください。
バックエンドサーバーのリクエスト処理時間が長すぎて、クライアントのリクエストタイムアウト期間を超えています。アクセスログのupstream_response_timeフィールドは、バックエンドサーバーがリクエストを処理するのに必要な時間を示します。バックエンドサーバーのCPU、メモリ、およびネットワークでパフォーマンスのボトルネックを確認することを推奨します。
クライアントで設定されているリクエストタイムアウト期間が短すぎます。その結果、クライアントはHTTPリクエストが送信される前に接続を閉じました。アクセスログのrequest_timeフィールドを確認することを推奨します。このフィールドは、クライアントがリクエストを送信するのに必要な時間を示します。クライアントで適切なリクエストタイムアウト期間を設定するには、このフィールドの値を参照します。
クライアントは不明な問題に遭遇し、HTTPリクエストが送信される前に接続を閉じます。 HTTPリクエストが送信される前に、クライアントが接続を閉じるかどうかを確認することをお勧めします。

500 (内部サーバーエラー)

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

考えられる原因: upstream_statusフィールドの値が500の場合: バックエンドサーバーは500のステータスコードを返します。バックエンドサーバーのエラーログなどのツールを使用して、バックエンドサーバーが500ステータスコードを返す理由を特定することを推奨します。

statusフィールドの値が500

バックエンドサーバーは500を返し、CLBはバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが500を返す理由を確認することを推奨します。
バックエンドサーバーは、応答を送信する前に接続を閉じます。原因を特定し、トラブルシューティングするために、バックエンドサーバーでパケットをキャプチャすることを推奨します。

502 (悪いゲートウェイ)

CLBのHTTPまたはHTTPSリスナーがバックエンドサーバーにリクエストを送信できないか、バックエンドサーバーから応答が返されません。その結果、502ステータスコードがクライアントに返されます。

upstream_statusフィールドの値が502の場合、考えられる原因

TCPを介したCLBとバックエンドサーバー間の通信が異常です。バックエンドサーバーのステータスが正常かどうか、サービスポートが期待どおりにリッスンされているかどうか、またはTCP SYNパケットが正常かどうかを確認します。
バックエンドサーバーは、過剰なワークロードのために応答できません。たとえば、バックエンドのバックログがいっぱいの場合、パケットはドロップされます。バックエンドサーバーのネットワーク統計がドロップされたパケットの数を示すかどうかを確認するには、netstatを使用することを推奨します。
クライアントから送信されたパケットの長さが、バックエンドサーバーの最大送信単位 (MTU) を超えています。この場合、ヘルスチェックが成功するか、短いパケットが期待どおりに送信されます。しかしながら、より長いパケットは期待通りに送信されない。バックエンドサーバーでパケットをキャプチャして、パケット長が要件を満たしているかどうかを分析することを推奨します。
バックエンドサーバーから返されたパケットは、無効な形式であるか、無効なHTTPヘッダーが含まれています。バックエンドサーバーでパケットをキャプチャして、パケットの形式が無効かどうかを確認することを推奨します。
CLBのバックエンドサーバーがリクエストの処理を完了していません。バックエンドサーバーのログデータを確認します。また、CPU使用率とメモリ使用率を確認してください。

statusフィールドの値が502

バックエンドサーバーは502を返し、CLBはバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが502を返す理由を確認することを推奨します。
バックエンドサーバーは別のステータスコード (504や444など) を返しますが、CLBは502を返します。アクセスログまたはキャプチャパケットのupstream_statusフィールドとstatusフィールドをチェックして、バックエンドサーバーに例外があるかどうかを確認することを推奨します。
同じサーバーグループのすべてのバックエンドサーバーが異常です。サーバーグループに関連付けられているCLBインスタンスは、リクエストを転送できず、502を返します。リスナーがヘルスチェックに合格するかどうかを確認することを推奨します。詳細については、「ヘルスチェックに関するFAQ」をご参照ください。

503 (一時的に使用できないサービス)

トラフィックが制限を超えているか、バックエンドサーバーが利用できないため、サービスは利用できません。

考えられる原因: upstream_statusフィールドの値が503の場合: バックエンドサーバーは503のステータスコードを返します。バックエンドサーバーのエラーログなどのツールを使用して、バックエンドサーバーが503ステータスコードを返す理由を特定することを推奨します。

statusフィールドの値が503

バックエンドサーバーは503を返し、CLBはバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが503を返す理由を確認することを推奨します。
クライアントからのトラフィックがCLBスロットリングをトリガーします。 CLBインスタンスの仕様の詳細については、「概要」をご参照ください。この問題を解決するには、次のいずれかの方法を使用することを推奨します。
- インスタンス仕様をアップグレードします。詳細については、次をご参照ください：従量課金インスタンスの設定を変更する。
- Alibaba Cloud DNSを使用して、ドメイン名を複数のCLBインスタンスに指定します。このように、より多くの要求を処理することができる。
- レイヤー4でより多くの同時接続が必要な場合は、Network Load Balancer (NLB) を使用します。レイヤー7で1秒あたりのクエリ数 (QPS) の値が高い場合は、ALBを使用します。詳細については、「ALBとは」および「NLBとは」をご参照ください。
次のいずれかの方法を使用して、CLBインスタンスのパフォーマンスメトリックを表示できます。
- CloudMonitorコンソールで1秒あたりのリクエスト数を表示します。詳細については、「CLBインスタンスに関するモニタリング情報の表示」をご参照ください。
- CloudMonitorは、モニタリングデータを分レベルで表示します。アクセスログを使用して、1秒あたりのリクエスト数を表示できます。アクセスログのupstream_statusフィールドを表示します。コンテンツが「-」の場合、リクエストはバックエンドサーバーに送信されません。
リスナーに関連付けられているバックエンドサーバーがないか、バックエンドサーバーの重みが0に設定されています。

504 (ゲートウェイのタイムアウト)

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

考えられる原因: upstream_statusフィールドの値が504の場合: バックエンドサーバーは504のステータスコードを返します。バックエンドサーバーが他の内部サービスにアクセスするため、応答がタイムアウトしたかどうかを確認することを推奨します。

statusフィールドの値が504

バックエンドサーバーは504を返し、CLBはバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが504を返す理由を確認することを推奨します。
CLBからバックエンドサーバーへの接続がタイムアウトしました。バックエンドサーバーの応答タイムアウト時間は、デフォルトで5秒に設定されています。アクセスログのupstream_connect_timeフィールドが5秒または約5秒に設定されているかどうかを確認できます。レスポンスタイムアウトの原因を特定するために、パケットをキャプチャすることを推奨します。
バックエンドサーバーのワークロードは重く、応答を返すのに必要な時間は、指定されたタイムアウト期間よりも長くなります。たとえば、設定されたリクエストタイムアウト期間は60秒です。応答時間が60.001秒の場合、CLBは504を返します。 CloudMonitorコンソールまたはアクセスログで、問題が発生した期間中のレイテンシを表示できます。レイテンシを表示するには、CloudMonitorのupstream_rtフィールド、またはアクセスログのupstream_response_timeフィールドを確認します。