すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Jul 30, 2026

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

    5つのクイックチェック

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

    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 ハンドシェイクが成功しているかを確認することもできます。

      • バックエンドサーバーの backlog がフルです。この場合、新しい接続要求が拒否またはドロップされます。バックエンドサーバーで 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)

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

    トラブルシューティングの進め方：アクセスログのフィールド (例：request_time (クライアントが接続をクローズするまでの総経過時間) 、upstream_response_time (バックエンドの処理時間) 、client_ip (トラフィック送信元)) を使用して、ネットワーク層からアプリケーション層へ順に切り分けながら、根本原因を迅速に特定します。upstream_response_time が高く、request_time に近い場合、バックエンドの応答が遅すぎるため、以下のバックエンド性能に関する項目を重点的に確認してください。request_time が非常に短い場合、クライアントがタイムアウト設定またはネットワーク問題により早期に切断しているため、以下のクライアント側およびネットワークに関する項目を重点的に確認してください。tcpinfo_rtt が同一経路の通常レベルより大幅に高い場合、クライアントと CLB 間のネットワーク経路が劣化しています。

    • クライアントと CLB 間のネットワークリンク品質が低下しています。TCP RTT の増大またはパケット損失で判断できます。アクセスログ内の request_time および tcpinfo_rtt フィールドを確認するか、パケットキャプチャを実施してクライアントネットワークを診断してください。また、アクセスログ内の client_ip フィールドを確認してトラフィック送信元を特定します。client_ip がパブリック IP アドレスの場合は、クライアントと CLB 間のインターネット回線品質 (例：ISP のパケット損失、リージョン間アクセスの遅延) を重点的に確認してください。client_ip がプライベート IP アドレスの場合は、接続安定性に影響する可能性があるセキュリティグループルールやネットワーク ACL などの VPC ネットワーク設定を重点的に確認してください。

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

    • バックエンドサーバーによるリクエストの処理に時間がかかりすぎる。処理時間がクライアントのリクエストタイムアウトを超えています。(アクセスログでは、upstream_response_time はバックエンドの処理時間を表します。) クライアントのタイムアウトとネットワークの問題を区別するには、アクセスログの request_time の値をクライアントで設定されたタイムアウトと比較します。2 つの値が近い場合、ネットワークの問題ではなく、タイムアウトが原因でクライアントが接続を閉じたことになります。バックエンドサーバーの CPU、メモリ、ネットワークにパフォーマンスのボトルネックがないか確認します。また、ECS インスタンスのネットワークインターフェイスでのパケットドロップの有無 (ifconfig または ethtool -S <interface> を実行してドロップカウンターを表示) と、カーネルの SYN バックログキューが満杯かどうか (netstat -s | grep -i syn を実行して SYN 関連の統計を確認) を確認します。

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

    • クライアントで不明な問題が発生しました。これにより、クライアントが早期に接続をクローズしました。早期の接続終了を引き起こす可能性がある動作がないか、クライアントを調査してください。

    • 同時パケットキャプチャ。上記の手順で根本原因が特定できない場合は、クライアントとバックエンドサーバーの両方で同時に tcpdump を実行し、TCP 接続の確立シーケンスとクローズシーケンスを比較します。バックエンドサーバーがリクエストを処理している間にクライアントが FIN パケットを送信した場合、タイムアウトが原因でクライアントが能動的に接続をクローズしたと判断できます。

    500 (Internal Server Error)

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

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

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

    503 (Service Temporarily Unavailable)

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

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

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

      解決策：

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

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

      • レイヤー 4 サービスの場合、より多くの同時接続数を処理するために Network Load Balancer (NLB) の使用を検討してください。

      • レイヤー 7 サービスの場合、より高い QPS を実現するために Application Load Balancer (ALB) の使用を検討してください。

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

    504 (Gateway Timeout)

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

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

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

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