すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Jun 23, 2026

    アクセスログを有効にすることで、CLB のエラーステータスコードを迅速にトラブルシューティングできます。まず、アクセスログ内のstatusフィールドとupstream_statusフィールドの値が同じかどうかを確認します。両方が同じ場合、ステータスコードはバックエンドサーバーから直接返された可能性が高いため、バックエンドサービスを最初に調査します。ログにstatusフィールドのみが含まれている場合、エラーはクライアント側の問題が原因である可能性があります。

    5つの簡易確認項目

    特定のステータスコードのトラブルシューティングを行う前に、以下の 5 つの設定を順番に確認してください。これらは CLB 障害の最も一般的な原因です。

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

    2. リスナーの ヘルスチェックステータス が 正常 であることを確認します。 インスタンスのリスナーページで、バックエンドサーバーグループの ヘルスチェックステータス を確認します。 ステータスが異常な場合は、「ヘルスチェックに関する FAQ」をご参照ください。

    3. バックエンド ECS インスタンスが 100.64.0.0/10 CIDR ブロックをブロックしないようにしてください。これは、CLB とバックエンドサーバー間の通信のために Alibaba Cloud によって予約された内部 CIDR ブロックであり、セキュリティリスクはありません。ECS インスタンスのセキュリティグループに、この CIDR ブロックに対する許可ルールを追加する必要はありません。ただし、バックエンド ECS インスタンス上の iptables ルールまたはサードパーティのセキュリティソフトウェアがこの CIDR ブロックをブロックする場合、CLB はバックエンドにアクセスできなくなり、502、504、またはその他のエラーが引き起こされる可能性があります。

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

    5. HTTPS リスナーの場合：証明書の有効期限が切れていないこと、および証明書にバインドされているドメイン名がアクセスドメインと一致していることを確認してください。リスナーの詳細ページで、バインドされている証明書とその有効期限を確認してください。証明書の有効期限切れまたはドメイン名の不一致により、SSL ハンドシェイクが失敗したり、エラーステータスコードが返されたりする可能性があります。

    502 (Bad Gateway)

    このエラーは、HTTP または HTTPS リスナーがクライアントからリクエストを受信したものの、CLB がそれをバックエンドサーバーに転送できない場合や、応答を受信できない場合に発生します。

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

    • もし upstream_status が 502 であれば: バックエンドサービス自体が 502 エラーを返し、CLB がそれをクライアントにそのまま転送したことを示します。バックエンドの Nginx、ゲートウェイ、またはアプリケーションのログを調査してください。

    • upstream_status が (504、444、500 など) その他の値の場合: CLB がアクセスログで返す status は upstream_status と一致せず、CLB がステータスコードを変換したことを示します。upstream_status の実際の値に基づいて、バックエンドサービスがこのステータスコードを返した理由を調査してください (バックエンドの Nginx、ゲートウェイ、またはアプリケーションのログを確認してください)。

    • もし upstream_status が - または空の場合: CLB がバックエンドからレスポンスを受信しなかったことは、リクエストがバックエンドに到達しなかったか、またはバックエンドが応答する前に予期せず接続を閉じたことを示します。 次の項目を順番に確認してください：

      • CLB とバックエンドサーバー間の TCP 通信の異常。バックエンドサービスが実行されているか、サービスポートが正しくリッスンしているか、およびバックエンドの ECS インスタンス上の iptables ルールまたはサードパーティ製のセキュリティソフトウェアが 100.64.0.0/10 CIDR ブロックをブロックしているかどうかを確認してください。 また、パケットをキャプチャして、TCP ハンドシェイクが成功するかどうかを確認することもできます。

      • バックエンドサーバーのバックログがいっぱいです。これにより、新しい接続リクエストが拒否またはドロップされます。バックエンドサーバーで netstat -s | grep -i listen を実行し、drop カウントを確認できます。

      • バックエンドサーバーがリクエストを時間内に処理できませんでした。バックエンドサーバーのログを確認し、CPU とメモリの使用率を確認して、パフォーマンスのボトルネックを特定してください。

      • クライアントが送信したパケットがバックエンドサーバーの MTU を超えています。これは、ヘルスチェックが成功し、小さなパケットの処理が正常であるにもかかわらず、大きなパケットで失敗する現象として現れる可能性があります。バックエンドサーバーでパケットキャプチャを実行し、パケットサイズが適切かどうかを分析することを推奨します。

      • バックエンドサーバーの応答の形式が無効であるか、HTTP ヘッダーが無効です。バックエンドサーバーでパケットキャプチャを実行して、応答形式が有効かどうかを分析してください。

      • サーバーグループ内のすべてのバックエンドサーバーがヘルスチェックに失敗しています。利用可能なバックエンドがないため、CLB は 502 エラーを返します。リスナーのヘルスチェック設定とバックエンドサービスのステータスをトラブルシューティングしてください。詳細については、「ヘルスチェックの失敗をトラブルシューティングする方法」をご参照ください。

      • リスナーのヘルスチェックは正常ですが、転送ルールに関連付けられたサーバーグループが異常です。ヘルスチェックは、リスナーにバインドされたデフォルトのサーバーグループにのみ適用され、転送ルールで設定されたサーバーグループには適用されません。リクエストが転送ルールに一致する場合は、そのルールに関連付けられたサーバーグループ内のバックエンドサーバーのステータスを確認する必要があります。

    400 (Bad Request)

    HTTP リクエストの形式が無効です。

    • バックエンドサーバーが 400 エラーを返します。 upstream_status は 400 であり、CLB はレスポンスをパススルーします。この問題は、CLB が HTTP プロトコルで HTTPS プロトコルを使用するバックエンドサーバーにアクセスする場合や、バックエンドサーバーに特別なメッセージ検証ロジックがある場合に多く発生します。バックエンドサービスがなぜ 400 エラーを返しているかを調査してください。

    • クライアントから送信されたリクエストの HTTP ヘッダー形式が不正です。 たとえば、Content-Length ヘッダーの値がリクエストボディの長さと一致しない、リクエストメソッドが大文字で指定されていない、またはヘッダーサイズが 32 KB の制限を超えている場合などです。クライアントでパケットをキャプチャして HTTP リクエスト形式を分析し、有効なリクエストと比較することをお勧めします。

    • クライアントが CLB インスタンスの HTTPS リスナーポートに HTTP リクエストを送信しました。CLB はリクエストを拒否し、400 エラーを返します。クライアントが正しいプロトコルを使用しているかどうかを確認してください。

    • HTTP リクエストが完全に送信される前に、クライアントが接続を閉じました。パケットキャプチャを実行して、クライアントが切断した理由を調査することを推奨します。

    405 (Method Not Allowed)

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

    • バックエンドサーバーは、クライアントが使用するリクエストメソッドをサポートしていません。 upstream_status は 405 です。 バックエンドサーバーで curl -X method ip:port コマンドを実行して確認できます。ここで、method はクライアントのリクエストメソッド、ip はバックエンドの IP アドレス、port はバックエンドのポートです。 クライアントのリクエストメソッドがバックエンドサーバーでサポートされているか確認してください。

    • CLB は TRACE リクエストメソッドをサポートしていません。別のメソッドを使用してください。

    408 (Request Timeout)

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

    • クライアントが部分的なデータのみを送信しました。クライアントは、リクエストタイムアウト期間 (デフォルト 60 秒) 内に部分的なデータ (HTTP ヘッダーのみなど) しか送信しませんでした。パケットキャプチャを実行して、クライアント側のパフォーマンスボトルネックまたは異常な動作を確認してください。

    • クライアントから CLB へのネットワークリンク品質が悪い。 TCP ラウンドトリップタイム (RTT) が高いか、パケットロスが発生します。 アクセスログの request_time フィールドと tcpinfo_rtt フィールドを確認するか、クライアントでネットワーク診断を実行できます。

    • CLB インスタンスへの過剰なトラフィックが帯域幅スロットリングとパケットロスを引き起こしています。CloudMonitor を使用して、インスタンスのアウトバウンド帯域幅とドロップされた接続メトリクスを確認してください。

    414 (URI Too Long)

    クライアントリクエストの URI の長さが制限を超えており、CLB がリクエストを拒否しました。

    • バックエンドサーバー自体が 414 エラーを返します。upstream_status=414。バックエンドサーバーの URI の長さの制限は、CLB よりも厳しくなっています。クライアント URI を短くするか、バックエンドサーバーの URI の長さの制限を増やしてください。

    • クライアントリクエストの URI が CLB の 32 KB 制限を超えています。URI の長さを短縮してください。大量のデータを送信する必要がある場合は、POST メソッドを使用してリクエストボディに配置してください。

    499 (Client Closed Request)

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

    • クライアントと CLB 間のネットワークリンク品質不良。これは、高い TCP RTT またはパケットロスによって示されます。アクセスログの request_time フィールドおよび tcpinfo_rtt フィールドを確認するか、パケットキャプチャを実行してクライアントネットワークを診断できます。

    • CLB インスタンスへの過剰なトラフィックが帯域幅スロットリングとパケットロスを引き起こしています。CloudMonitor を使用して、インスタンスのアウトバウンド帯域幅とドロップされた接続メトリクスを確認してください。

    • バックエンドサーバーでのリクエスト処理に時間がかかりすぎます。 処理時間がクライアントのリクエストタイムアウトを超えています。 (アクセスログでは、 upstream_response_time はバックエンドの処理時間を表します)。 バックエンドサーバーの CPU、メモリ、またはネットワークにパフォーマンスのボトルネックがないか確認することをお勧めします。

    • クライアントで設定されたリクエストタイムアウト期間が短すぎます。これにより、リクエストが完了する前にクライアントが接続を閉じてしまいます。アクセスログの request_time フィールドは、合計リクエスト時間を示します。このフィールドに基づいてクライアントのタイムアウト設定を調整することをお勧めします。

    • クライアントで不明な問題が発生しました。これにより、接続が早期に閉じられました。接続が早期に終了する原因となりうる動作がないか、クライアント側を調査してください。

    500 (Internal Server Error)

    バックエンドサーバーで内部エラーが発生しました。

    • バックエンドサーバー自体が 500 エラーを返します。 upstream_status は 500 で、CLB はレスポンスをパススルーします。バックエンドサーバーのエラーログを確認して、根本原因をトラブルシューティングしてください。

    • バックエンドサーバーが完全な応答を送信する前に、予期せず接続を閉じました。バックエンドサーバーでパケットキャプチャを実行して、予期しない接続閉鎖の原因を調査します。

    503 (Service Temporarily Unavailable)

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

    • バックエンドサーバー自体が 503 エラーを返します。 upstream_status は 503 で、CLB はレスポンスをパススルーします。 バックエンドサーバーのログを確認して、根本原因を調査してください。

    • クライアントリクエストトラフィックによって、CLB のレート制限がトリガーされます。CloudMonitor で 1 秒あたりのリクエスト数メトリックを確認できます。CloudMonitor は分単位の粒度でデータを表示するため、1 秒あたりの制限を超過しても表示されない場合があります。アクセスログで 1 秒あたりのリクエスト数を確認できます。upstream_status フィールドの値が - の場合、リクエストがバックエンドサーバーに送信されなかったことを示します。

      解決策：

      • CLB インスタンスの仕様をアップグレードします。

      • Alibaba Cloud DNS を使用して、ドメイン名を複数の CLB インスタンスにポイントし、トラフィックを分散します。

      • レイヤー 4 サービスの場合は、NLB を使用してより多くの同時接続を処理することを検討してください。

      • レイヤー 7 サービスの場合は、ALB を使用してより高い QPS を実現することを検討してください。

    • CLB リスナーにバックエンドサーバーが設定されていないか、設定されたバックエンドサーバーの重みが 0 です。

    504 (Gateway Timeout)

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

    • バックエンドサーバー自体が 504 エラーを返す。 upstream_status は 504 で、CLB はレスポンスをパススルーします。 一般的な原因として、バックエンドサーバーが他の内部サービスにアクセスする際にタイムアウトすることが挙げられます。 これらの内部サービスをトラブルシューティングしてください。

    • CLB がバックエンドサーバーに接続するときにタイムアウトが発生します。デフォルトの接続タイムアウトは 5 秒で、変更できません。アクセスログで、upstream_connect_time フィールドの値が 5 秒に近いかどうかを確認できます。バックエンドサーバーの応答が遅い理由を調査するために、パケットキャプチャを使用することをお勧めします。

    • バックエンドサーバーの応答時間が CLB のリクエストタイムアウト期間を超過しました。 デフォルトは 60 秒です。 この問題は、CloudMonitor の upstream_rt メトリクス、またはアクセスログの upstream_response_time フィールドで確認できます。