CLB からエラー状態コードが返された場合は、このトピックを参照して問題をトラブルシューティングしてください。
エラー状態コードを受け取った場合、アクセスログの status フィールドおよび upstream_status フィールドを確認します。両フィールドの値が同一の場合、その状態コードはバックエンドサーバーからそのまま渡されている可能性があります。この場合は、まずバックエンドサーバーを調査してください。アクセスログに status フィールドのみが含まれている場合、エラーはクライアント側の問題によって発生している可能性があります。
この機能を有効化すると、問題をより迅速に特定できます。詳細については、「アクセスログの設定」をご参照ください。
400 (不正なリクエスト)
HTTP リクエストの形式が不正です。
upstream_status が 400 となる原因の可能性：
CLB が HTTP を使用してバックエンドサーバーにアクセスしていますが、バックエンドサーバーが HTTPS で構成されています。この問題を解決するには、以下のいずれかの方法を使用してください。
バックエンドサーバーを HTTP プロトコルで構成します。
Application Load Balancer (ALB) を使用し、バックエンドプロトコルとして HTTPS を使用するサーバーグループを作成します。詳細については、「サーバーグループの作成と管理」をご参照ください。
CLB の検証を通過したリクエストが、バックエンドサーバーでのカスタム検証に失敗しました。バックエンドサーバーを調査し、検証が失敗した理由を特定してください。
status が 400 となる原因の可能性：
バックエンドサーバーが 400 状態コードを返し、CLB がその状態コードをクライアントに渡しました。バックエンドサーバーが 400 状態コードを返した理由を調査してください。
クライアントリクエストの HTTP ヘッダーの形式が不正です。たとえば、
Content-Lengthがリクエストボディのサイズと一致しない、リクエストメソッドが大文字になっていない、または HTTP リクエストが HTTPS リスナーに送信されたなどが考えられます。クライアント側でパケットキャプチャを行い、リクエストフォーマットを有効なリクエストと比較してください。CLB インスタンスに HTTPS リスナーが設定されています。クライアントが非 HTTPS リクエストを送信し、400 状態コードを受け取った場合は、クライアントが HTTP リクエストを HTTPS ポートに送信していないか確認してください。
クライアントが HTTP リクエストの完了前に接続を閉じました。パケットキャプチャを行い、クライアントが切断した理由を調査してください。
CLB では、各 HTTP ヘッダーのサイズが 32 KB を超えてはなりません。この制限を超えると、CLB は 400 状態コードを返します。HTTP ヘッダーのサイズを制限内に収まるように削減してください。
405 (許可されていないメソッド)
リクエストメソッドがサポートされていません。
バックエンド状態コード (upstream_status) の原因の可能性： バックエンドサーバーがクライアントリクエストで使用されたメソッドをサポートしていません。クライアントが使用しているメソッドがバックエンドサーバーと互換性があるかどうかを確認することを推奨します。たとえば、curl -X method ip:port コマンドを使用して、バックエンドサーバーが特定のメソッドをサポートしているかどうかを直接テストできます。ここで、method はクライアントリクエストで使用されたメソッド、ip はバックエンドサーバーの IP アドレス、port はバックエンドサーバーのポートです。
status が 405 となる原因の可能性：
CLB は TRACE リクエストメソッドをサポートしていません。別のメソッドを使用してください。
バックエンドサーバーが 405 状態コードを返し、CLB がその状態コードをクライアントに渡しました。バックエンドサーバーが 405 状態コードを返した理由を調査してください。
408 (リクエストタイムアウト)
リクエストがタイムアウトし、CLB が接続を閉じました。
status が 408 となる原因の可能性：
クライアントがクライアントから CLB へのリクエストタイムアウト期間（デフォルトで 60 秒）内に、HTTP ヘッダーのみなど一部のデータしか送信しませんでした。クライアント側でパケットキャプチャを行い、パフォーマンスボトルネックやその他の異常な動作がないか確認してください。
クライアントと CLB 間の接続にネットワークの問題が存在します。たとえば、TCP 往復レイテンシ (RTT) が高かったり、パケット損失が発生していたりする可能性があります。
request_timeフィールドおよびtcpinfo_rttフィールドをアクセスログで確認するか、パケットキャプチャを行い、クライアント側のネットワーク問題を診断してください。CLB インスタンスへのトラフィックが多すぎて、帯域幅調整および接続のドロップがトリガーされました。CloudMonitor でインスタンスのアウトバウンド帯域幅およびドロップされた接続のメトリックを確認してください。詳細については、「CLB モニタリング情報の表示」をご参照ください。
414 (URI が長すぎます)
CLB は、リクエスト URI が長すぎてバックエンドサーバーが処理できないため、リクエストを拒否しました。
upstream_status が 414 となる原因の可能性： バックエンドサーバーが 414 状態コードを返した場合は、以下のいずれかの方法でこの問題を解決してください。
URI を短縮するか、POST メソッドを使用してデータを送信します。
バックエンドサーバーが受け付ける最大 URI 長を増やします。
status が 414 となる原因の可能性：
バックエンドサーバーが 414 状態コードを返し、CLB がその状態コードをクライアントに渡しました。バックエンドサーバーが 414 状態コードを返した理由を調査してください。
CLB に送信されたリクエストの URI は 32 KB を超えてはなりません。この制限を超えると、414 状態コードが返されます。URI を短縮してください。大量のデータを送信する場合は、POST メソッドを使用します。
499 (クライアントがリクエストを閉じました)
クライアントが接続を閉じました。
status が 499 となる原因の可能性：
クライアントと CLB 間の接続にネットワークの問題が存在します。たとえば、往復レイテンシ (RTT) が高かったり、パケット損失が発生していたりする可能性があります。
request_timeフィールドおよびtcpinfo_rttフィールドをアクセスログで確認するか、パケットキャプチャを行い、クライアント側のネットワーク問題を診断してください。CLB インスタンスへのトラフィックが多すぎて、帯域幅調整および接続のドロップがトリガーされました。CloudMonitor でインスタンスのアウトバウンド帯域幅およびドロップされた接続のメトリックを確認してください。詳細については、「CLB モニタリング情報の表示」をご参照ください。
バックエンドサーバーのリクエスト処理に時間がかかりすぎて、クライアントのリクエストタイムアウト期間を超えました。アクセスログの
upstream_response_timeフィールドはバックエンド処理時間を示します。バックエンドサーバーの CPU、メモリ、ネットワーク使用率などのパフォーマンスボトルネックを確認してください。クライアントに設定されたリクエストタイムアウト期間が短すぎます。そのため、HTTP リクエストが完全に送信される前にタイムアウトによりクライアントが接続を閉じました。アクセスログの
request_timeフィールドを確認してください。このフィールドはクライアントリクエストの合計時間を示します。この値を参考にして、クライアント側に適切なリクエストタイムアウトを設定してください。クライアントが不明な問題に遭遇し、HTTP リクエストが完了する前に接続を閉じました。クライアントが接続を早期に閉じていないか確認してください。
500 (内部サーバーエラー)
バックエンドサーバーで内部エラーが発生し、リクエストを処理できませんでした。
upstream_status が 500 となる原因の可能性： バックエンドサーバーが 500 状態コードを返しました。バックエンドサーバーのエラーログおよびその他のツールを確認し、原因を特定してください。
status が 500 となる原因の可能性：
バックエンドサーバーが 500 状態コードを返し、CLB がその状態コードをクライアントに渡しました。バックエンドサーバーが 500 状態コードを返した理由を調査してください。
バックエンドサーバーが完全な応答を送信する前に予期せず接続を閉じました。バックエンドサーバーでパケットキャプチャを行い、接続が予期せず閉じられた理由を調査してください。
502 (バッドゲートウェイ)
CLB がクライアントリクエストをバックエンドサーバーに転送できない、またはバックエンドサーバーからの応答を受信できない場合、HTTP または HTTPS リスナーは 502 Bad Gateway 状態コードを返します。
upstream_status が 502 となる原因の可能性：
CLB とバックエンドサーバー間の TCP 通信が異常です。バックエンドサーバーが正常な状態であること、およびサービスポートが正しくリスニングしていることを確認してください。また、TCP ハンドシェイクが成功しているかどうかを確認するためにパケットキャプチャを行うこともできます。
バックエンドサーバーが過負荷になり、応答に失敗しました。たとえば、バックエンドサーバーの backlog がいっぱいになると、パケットがドロップされます。
netstatを使用してバックエンドサーバーのネットワーク統計情報を確認し、パケットドロップ数をチェックしてください。例:クライアントが送信したパケットの長さがバックエンドサーバーの最大転送単位 (MTU) を超えています。これにより、長いパケットは失敗する一方で、短いパケットやヘルスチェックは成功する可能性があります。バックエンドサーバーでパケットキャプチャを行い、パケット長が許容範囲内であるかどうかを分析してください。
バックエンドサーバーが返したパケットの形式が不正、または無効な HTTP ヘッダーを含んでいます。バックエンドサーバーでパケットキャプチャを行い、HTTP フォーマットが有効かどうかを確認してください。
バックエンドサーバーがリクエスト処理を時間内に完了できませんでした。バックエンドサーバーのログおよび CPU やメモリなどのリソース使用率を確認してください。
status が 502 となる原因の可能性：
バックエンドサーバーが 502 状態コードを返し、CLB がその状態コードをクライアントに渡しました。バックエンドサーバーが 502 状態コードを返した理由を調査してください。
バックエンドサーバーが 504 や 444 などの別のエラー状態コードを返しましたが、CLB がクライアントに 502 状態コードを返しています。アクセスログの
upstream_statusフィールドおよびstatusフィールドを確認するか、パケットキャプチャを行い、バックエンドサーバー側の問題をチェックしてください。サーバーグループ内のすべてのバックエンドサーバーがヘルスチェックに失敗しました。関連付けられた CLB インスタンスはリクエストを転送できず、直接 502 状態コードを返します。リスナーに設定されたヘルスチェックが期待どおりに動作しているかどうかを確認してください。詳細については、「ヘルスチェック FAQ」をご参照ください。
503 (サービス一時利用不可)
サーバーが一時的にリクエストを処理できません。これは通常、トラフィックが制限を超えたか、バックエンドサーバーが利用できないために発生します。
upstream_status が 503 となる原因の可能性： バックエンドサーバーが 503 状態コードを返しました。バックエンドサーバーのログおよびその他のツールを確認し、原因を特定してください。
status が 503 となる原因の可能性：
バックエンドサーバーが 503 状態コードを返し、CLB がその状態コードをクライアントに渡しました。バックエンドサーバーが 503 状態コードを返した理由を調査してください。
クライアントリクエストトラフィックが CLB インスタンスのレート制限をトリガーしました。CLB インスタンスの仕様の詳細については、「CLB インスタンスの概要」をご参照ください。この問題を解決するには、以下のいずれかの方法を使用してください。
インスタンスの仕様をアップグレードします。詳細については、「従量課金インスタンスの仕様変更」をご参照ください。
Alibaba Cloud DNS を使用して、ドメイン名を複数の CLB インスタンスにポイントし、スケールアウトします。
同時接続数が多いレイヤー 4 のワークロードには Network Load Balancer (NLB) を使用します。QPS が高いレイヤー 7 のワークロードには Application Load Balancer (ALB) を使用します。詳細については、「Application Load Balancer (ALB) とは」および「Network Load Balancer (NLB) とは」をご参照ください。
CLB インスタンスのパフォーマンスメトリクスを表示するには、以下のいずれかの方法を使用できます。
CloudMonitor でインスタンスの秒間リクエスト数メトリックを表示します。詳細については、「CLB モニタリング情報の表示」をご参照ください。
CloudMonitor は 1 分単位の粒度でデータを表示するため、秒単位の速度制限は表示されない可能性があります。アクセスログで秒間リクエスト数を確認できます。アクセスログの
upstream_statusフィールドが "-" の場合、リクエストはバックエンドサーバーに送信されていません。
CLB リスナーにバックエンドサーバーが設定されていない、または設定されたすべてのバックエンドサーバーの重みが 0 です。
504 (ゲートウェイタイムアウト)
バックエンドサーバーの応答がタイムアウトしました。
upstream_status が 504 となる原因の可能性： バックエンドサーバーが 504 状態コードを返しました。バックエンドサーバーが他の内部サービスにアクセス中にタイムアウトしていないか調査してください。
status が 504 となる原因の可能性：
バックエンドサーバーが 504 状態コードを返し、CLB がその状態コードをクライアントに渡しました。バックエンドサーバーが 504 状態コードを返した理由を調査してください。
CLB からバックエンドサーバーへの接続がタイムアウトしました。バックエンドサーバーのデフォルトの接続タイムアウト期間は 5 秒です。アクセスログの
upstream_connect_timeフィールドの値が 5 または 5 に近いかどうかを確認してください。パケットキャプチャを行い、応答タイムアウトの原因を調査してください。バックエンドサーバーのワークロードが高いため、応答時間が設定されたリクエストタイムアウト期間を超えました。たとえば、リクエストタイムアウト期間が 60 秒で応答時間が 60.001 秒の場合、CLB は 504 状態コードを返します。CloudMonitor の
upstream_rtメトリックまたはアクセスログのupstream_response_timeフィールドを確認して、問題が発生した期間の遅延をチェックできます。