Server Load Balancer:CLB リスナーに関するよくある質問

CLB におけるポートリダイレクトのサポート

はい、サポートしています。

Classic Load Balancer (CLB) はポートリダイレクトをサポートしています。詳細については、「CLB を使用した HTTP リクエストから HTTPS へのリダイレクト」をご参照ください。

レイヤー 4 リスナーにおけるポート範囲のサポート

いいえ、サポートしていません。TCP リスナーまたは UDP リスナーでポート範囲をリッスンするには、Network Load Balancer (NLB) インスタンスを作成し、リスナーで全ポート機能を有効にしてください。詳細については、「NLB の全ポートリスナー機能を使用した複数ポートでのトラフィック転送」をご参照ください。

リスナーポート設定時の注意事項

一部のキャリアでは、25、135、139、444、445、5800、5900 などのポートを高リスクポートとして分類し、デフォルトでブロックしています。セキュリティグループルールでこれらのポートを許可した場合でも、特定の地域のユーザーはサービスにアクセスできない可能性があります。高リスクではない他のポートを使用することを推奨します。

• Windows Server システム上のアプリケーションが使用するポートについては、Microsoft Documentation の「Windows Server のサービス概要とネットワークポート要件」をご参照ください。

• 一般的なポートの詳細については、「一般的なポート」をご参照ください。

WebSocket のリスナー設定

• バックエンドサーバーで WebSocket サービスをホストしている場合は、TCP リスナーまたは HTTP リスナーを設定できます。

• バックエンドサーバーで WebSocket Secure サービスをホストしている場合は、TCP リスナーまたは HTTPS リスナーを設定できます。

リスナー設定変更の影響

変更は即座に有効となり、新しいリクエストにのみ適用されます。既存の接続には影響しません。

URL 転送ルールにおける特殊文字

URL 内の特殊文字は、正しくアクセスできるよう URL エンコードする必要があります。例えば、ハッシュ文字 (#) は %23 としてエンコードされるため、URL は http://www.example.com/%23/ となります。完全なエンコードルールについては、RFC 3986 をご参照ください。

転送ルールのバックエンドサーバーの管理

[転送ルール] ページで、[仮想サーバーグループ] 列にある対象の vServer グループの名前をクリックします。[仮想サーバーグループの編集] ページで、バックエンドサーバーを追加または削除し、ポートやウェイトを変更できます。

CLB はリクエストボディサイズの制限設定をサポートしていますか？

CLB は client_max_body_size パラメータをサポートしていません。50 GB のリクエストボディサイズ制限は Application Load Balancer (ALB) の機能であり、CLB には適用されません。

リクエストボディサイズを制御するには、TCP レイヤー 4 リスナーを使用し、バックエンドの ECS インスタンスの Web サーバー (Nginx など) で client_max_body_size を設定してください。

http {
    client_max_body_size 100m;
}

TCP リスナーを使用すると、CLB はレイヤー 4 トラフィックを透過的に転送し、リクエストボディサイズの制限はバックエンドの ECS インスタンスが適用します。

Classic Load Balancer (CLB) 固定帯域幅インスタンスの帯域幅の計算方法

Classic Load Balancer (CLB) の固定帯域幅インスタンスでは、アウトバウンド帯域幅とインバウンド帯域幅はそれぞれ独立して計算されます。固定帯域幅の値を設定すると、アウトバウンド帯域幅とインバウンド帯域幅の両方に、設定された値が個別の帯域幅上限として適用されます。これらを合計する必要はありません。例えば、固定帯域幅を 80 Mbps に設定した場合、最大アウトバウンド帯域幅は 80 Mbps、最大インバウンド帯域幅も 80 Mbps となります。これら 2 つの値は独立して計算され、互いに影響しません。

CLB コンソールのモニタリングページで、リアルタイムのアウトバウンドおよびインバウンド帯域幅のモニタリングデータを表示できます。モニタリングメトリクスにおいて、inBitsPS はインバウンド帯域幅を、outBitsPS はアウトバウンド帯域幅を表します。帯域幅を調整する際は、コンソールの分レベルのモニタリングデータを参考にすることを推奨します。

帯域幅制限を超えていない場合のトラフィックドロップ

この問題は、通常、以下の理由で発生します。

• Alibaba Cloud の帯域幅監視では、1 分間の平均値を使用しています。1 秒以内の瞬間的なトラフィックスパイクがインスタンスの帯域幅制限を超えると、トラフィックがドロップされます。これは、1 分間全体の平均帯域幅が設定された制限を下回っている場合でも発生する可能性があります。その結果、監視グラフでは、全体的な帯域幅使用量が指定された制限よりも低く表示されることがあります。

• CLB インスタンスは、受信リクエストをサーバー間で均等に分散するサーバークラスター上で動作します。設定されたピーク帯域幅も、クラスター内のサーバー間で分散されます。単一のクライアント接続によってダウンロードされるデータが個々のサーバーのしきい値を超えると、トラフィックがドロップされます。単一接続の最大ダウンロードトラフィックの計算方法の詳細については、「特定のシナリオで接続がピーク帯域幅に達しないのはなぜですか?」をご参照ください。

監視トラフィックが設定した上限を超える場合

CLB インスタンスは、分散型レート制限のためにサーバークラスターを使用します。単一ノードのピークレート制限は 単一ノードのピークレート制限 = 設定された合計帯域幅 / (N - 1) として計算されます。ここで、N はクラスター内のノード数です。その結果、合計有効レート制限が設定値よりわずかに高くなる場合があります。

接続がピーク帯域幅に達しない場合

• シナリオ： 性能保証型 (固定帯域幅) 課金方法を使用するパブリック向け CLB インスタンスへの単一接続では、設定されたピーク帯域幅に達しない場合があります。この問題は、単一クライアントの負荷テスト中、または非常に大きなデータパケットを転送する際によく発生します。

• 原因：

  CLB インスタンスは、サーバークラスター上で動作します。クラスターは、すべての受信リクエストをサーバー間で均等に分散します。

  単一接続の最大ダウンロードトラフィックは、接続あたりのピークダウンロードトラフィック = 設定された合計帯域幅 / (N - 1) の式で計算されます。ここで、N はクラスター内のサーバー数です。 N は、レイヤー 4 リスナーの場合は 4、レイヤー 7 リスナーの場合は 8 です。 たとえば、コンソールで帯域幅制限を 10 Mbps に設定した場合、複数のクライアントを同時に使用すると、合計帯域幅は 10 Mbps に達することができます。 ただし、単一のクライアントがダウンロードできる最大トラフィックは 10 / (4 - 1) = 3.33 Mbps です。

• ソリューション：

  • パブリック向け CLB インスタンスには、トラフィック課金方法を使用してください。

  • EIP と共有帯域幅を使用する Network Load Balancer (NLB) または Application Load Balancer (ALB) インスタンスを使用してください。この構成はより柔軟性が高く、この制限を回避できます。

CLB インスタンスがピーク QPS に達しない場合

• シナリオ： 少数の永続的な接続を使用する場合、接続が転送クラスター内のすべてのサーバーに分散されない可能性があります。その結果、CLB インスタンスがピーク QPS に達しない場合があります。

• 原因：

  CLB インスタンスは、クラスターにデプロイされます。システムは、受信リクエストをクラスター内のサーバー間で均等に分散します。したがって、CLB インスタンスのピーク QPS も、これらのサーバー間で分散されます。

  1 台のサーバーあたりの最大 QPS は、次のように計算されます: Peak QPS per server = Total instance QPS / (N - 1)。ここで、N は転送クラスター内のサーバー数です。たとえば、1,000 QPS をサポートする slb.s1.small 仕様の CLB インスタンスを購入した場合、複数のクライアントを使用すると、合計 QPS は 1,000 に達することができます。ただし、クラスターに 8 台のサーバーがある場合、1 台のサーバーあたりの最大 QPS は 1000 / (8 - 1) = 142 QPS です。

  説明

  性能保証型 CLB インスタンスの新規販売は、2025 年 6 月 1 日 00:00:00 (UTC+8) に終了します。詳細については、「性能保証型 Classic Load Balancer (CLB) インスタンスの販売終了」をご参照ください。

• ソリューション：

  • 負荷テストには、単一クライアントからの短期間の接続を使用してください。

  • 実際のビジネス要件に基づいて、接続の再利用を減らしてください。

  • CLB インスタンスの仕様をアップグレードしてください。詳細については、「従量課金 (性能保証型) インスタンスのアップグレードまたはダウングレード」をご参照ください。

  • Application Load Balancer (ALB) インスタンスを使用してください。このインスタンスタイプは、より高い柔軟性を提供します。

新規接続レートがピークに達しない場合

• シナリオ： 性能保証型 CLB インスタンスを使用する場合、特に単一クライアントの負荷テスト中、または単一のソースからトラフィックが発生する場合、新規接続レート (CPS) が指定されたレベルに達しない可能性があります。

  説明

  性能保証型 CLB インスタンスの新規販売は、2025 年 6 月 1 日 00:00:00 (UTC+8) に終了します。詳細については、「性能保証型 Classic Load Balancer (CLB) インスタンスの販売終了」をご参照ください。

• 原因：

  ロードバランシングシステムは、高可用性とスケーラビリティのためにクラスターアーキテクチャを使用します。受信接続リクエストをクラスター内のサーバー間で均等に分散します。したがって、CLB インスタンスのピーク CPS も、これらのサーバー間で分散されます。

  単一サーバーのピーク CPS は次のように計算されます: サーバーあたりのピーク CPS = インスタンスの合計 CPS / (N - 1)。ここで、N は転送クラスター内のサーバー数です。

  例えば、3,000 CPS に対応する slb.s1.small 仕様の CLB インスタンスを購入した場合、複数のクライアントからのリクエストで、インスタンスは 3,000 CPS を達成できます。ただし、クラスターに 4 台のサーバーがある場合、単一サーバーの最大 CPS は 3000 / (4 - 1) = 1,000 CPS です。

• ソリューション：

  • インスタンスの課金方法を性能保証型から従量課金に変更してください。従量課金インスタンスは、特定のパフォーマンス仕様に縛られず、より高い制限を提供するため、ボトルネックの防止に役立ちます。

  • 高同時実行性と高い新規接続レートのシナリオには、Network Load Balancer (NLB) にアップグレードしてください。Network Load Balancer (NLB) は、CLB と比較して優れたパフォーマンスと柔軟性を提供します。単一の Network Load Balancer (NLB) インスタンスは 1 億の同時接続数をサポートしており、大規模なアプリケーションに最適で、CLB クラスターアーキテクチャの CPS 制限を回避できます。

設定可能な接続タイムアウト範囲

• TCP リスナーの接続タイムアウト：10～900 秒。

• HTTP リスナー：

  • アイドルタイムアウト：1～60 秒。

  • リクエストタイムアウト：1～180 秒。

• HTTPS リスナー：

  • アイドルタイムアウト：1～60 秒。

  • リクエストタイムアウト：1～180 秒。

CLB の接続タイムアウトの原因

Classic Load Balancer (CLB) のサービスアドレスへの接続タイムアウトは、次のようなサーバー側の問題が原因で発生する可能性があります：

• サービスアドレスがセキュリティ対策によってブロックされている

  これには、トラフィックスクラビング、ブラックホールフィルタリング、WAF による保護などが含まれます。例えば、WAF は、接続を確立した後に、クライアントとサーバークラスターの両方に RST パケットを送信します。

• クライアントポートが不足している

  この問題はストレステスト中によく発生します。クライアントポートが不足すると、接続に失敗する可能性があります。デフォルトでは、CLB は TCP 接続から timestamp オプションを削除します。これにより、Linux カーネルの tw_reuse 機能 (TIME_WAIT 状態の接続の再利用) が有効にならないため、TIME_WAIT 状態の接続が蓄積し、利用可能なクライアントポートが不足します。

  解決策：短時間接続ではなく永続的な接続を使用してください。SO_LINGER ソケットオプションを設定して RST パケットを送信し、FIN パケットによる切断を回避してください。

• バックエンドサーバーの accept キューがいっぱいになっている

  バックエンドサーバーの accept キューがいっぱいになっている場合、SYN-ACK 応答が送信されず、クライアントのタイムアウトが発生します。

  解決策：net.core.somaxconn のデフォルト値は 128 です。トラフィック量を評価し、要件に合わせて値を調整してください。その後、sysctl -w net.core.somaxconn=<new_value> を実行してパラメーターを変更し、バックエンドサーバー上のアプリケーションを再起動してください。

• レイヤー 4 のバックエンドサーバーが、自身のロードバランサーのサービスアドレスにアクセスしている

  CLB のレイヤー 4 リスナー (TCP/UDP) では、バックエンドサーバーがクライアントとサーバーの両方として動作することはできません。バックエンドサーバーが、紐付け先の CLB インスタンスのサービスアドレスにアクセスしようとすると、接続に失敗します。よくあるシナリオとして、バックエンドアプリケーションが URL を組み立てて CLB サービスアドレスにリダイレクトするケースや、VPC 内の Elastic Compute Service (ECS) インスタンスがパブリックネットワーク経由で自身の CLB インスタンスのサービスアドレスにアクセスしてトラフィックループバックが発生するケースなどが挙げられます。

  この動作は、CLB がレイヤー 4 (LVS) でトラフィックを転送する仕組みに起因します。バックエンドの ECS インスタンスが CLB インスタンスにパケットを送信すると、CLB は宛先 IP アドレスを書き換えて、バックエンドサーバーにパケットを転送します。CLB が、送信元の ECS インスタンスと同じ ECS インスタンスにリクエストを転送した場合、パケットの送信元 IP アドレスと宛先 IP アドレスはどちらも当該 ECS インスタンスの IP アドレスになります。その結果、応答は ECS インスタンス上でローカルに完結し、CLB を経由して戻らないため、接続を確立できません。

  • CLB インスタンスにバックエンドサーバーが 1 台しかない場合、そのバックエンドサーバーからのすべてのリクエストが自分自身に転送され、接続失敗率は 100% になります。

  • CLB インスタンスに複数のバックエンドサーバーがある場合、例えば、ウェイトが同じ 2 台のバックエンドサーバーがある場合、CLB は約 50% のリクエストを別のバックエンドサーバーに転送します (接続は成功します)。約 50% のリクエストは元のバックエンドサーバーに転送されます (接続は失敗します)。全体の成功率は約 50% です。

  解決策：

  • レイヤー 4 のバックエンドサーバーではなく、別のクライアントを使用してサービスアドレスにアクセスしてください。

  • Network Load Balancer (NLB) インスタンスに移行し、サーバーグループで [クライアント IP の保持] を無効にします。この機能を無効にすると、サーバーグループ内の ECS インスタンスは、NLB インスタンスのバックエンドサーバーとクライアントの両方として動作できます。クライアントの送信元 IP アドレスを取得するには、Proxy Protocol を有効にしてください。詳細については、「How can an ECS instance act as both a backend server and a client of an NLB instance?」をご参照ください。

  • Alibaba Cloud DNS PrivateZone を使用してプライベートなドメイン名の名前解決を設定し、サービスドメイン名がバックエンドサーバーのプライベート IP アドレスに解決されるようにしてください。これにより、リクエストは CLB インスタンスを経由せずに内部ネットワーク経由でバックエンドサーバーに直接到達し、ループバック条件を解消できます。この方法は、バックエンドサーバーがドメイン名を使用して、紐付け先の CLB インスタンスのサービスにアクセスする場合に適用されます。なお、この場合リクエストは CLB をバイパスするため、ロードバランシングやヘルスチェックの恩恵を受けられなくなります。バックエンドサーバー自身が開始するリクエストにのみ、この方法を使用してください。

  • クライアントが稼働するサーバーの hosts ファイルを変更し、サービスドメイン名がバックエンドサーバーのプライベート IP アドレスを指すようにしてください。効果は PrivateZone と同じで、少数の個別サーバーにのみ回避策が必要なシナリオに適しています。hosts ファイルは各サーバーで保守する必要があるため、バックエンドサーバー数が多い場合は PrivateZone を使用してください。

• 接続タイムアウト時の RST パケットの処理が不適切である

  TCP 接続が確立された後、900 秒間アクティビティがない場合、CLB はクライアントとサーバーの両方に RST パケットを送信して接続を閉じます。一部のアプリケーションは RST パケットを正しく処理できず、閉じられた接続でデータ送信を試みて、アプリケーションタイムアウトが発生する場合があります。

  説明

  デフォルトのタイムアウトは 900 秒ですが、必要に応じて調整できます。

HTTP および HTTPS の接続タイムアウト

• HTTP の永続的な接続は、連続したリクエストを最大 100 回までサポートします。この上限に達すると、CLB は接続を閉じます。

• 永続的な接続において、2 つの HTTP または HTTPS リクエスト間のアイドルタイムアウトは 1～60 秒の範囲で設定できます (誤差は 1～2 秒)。このタイムアウトを超えると TCP 接続は閉じられます。アプリケーションで永続的な接続を使用する場合は、少なくとも 13 秒ごとにハートビートリクエストを送信することを推奨します。

• CLB インスタンスとバックエンド ECS インスタンス間の TCP 3 ウェイハンドシェイクは 5 秒でタイムアウトします。ハンドシェイクがタイムアウトした場合、CLB は次の ECS インスタンスを試行します。この問題は、アクセスログのアップストリームの応答時間を確認することで特定できます。

• リクエストタイムアウト (CLB インスタンスが ECS インスタンスからの応答を待機する時間) は 1～180 秒の範囲で設定できます。このタイムアウトを超えると、CLB は通常、クライアントに 504 または 408 のステータスコードを返します。この問題は、アクセスログのアップストリームの応答時間を確認することで特定できます。

• HTTPS セッション再利用のタイムアウトは 300 秒です。この期間を過ぎると、同一クライアントは完全な SSL ハンドシェイクを再度実行する必要があります。

CLB はタイムアウト後にリクエストを自動的に再試行しますか？

いいえ。リクエストがリスナーに設定されたリクエストタイムアウト (例：デフォルトの 60 秒) を超えると、CLB は接続を終了し、クライアントに 504 エラーコードを返します。CLB はリクエストを自動的に再試行しません。リクエストの再試行を実装するには、クライアント側でリトライロジックを実装する必要があります。この一般的な動作とは別に、HTTPS レイヤー 7 リスナーには、後述する特定の条件下で動作する暗黙的なリトライメカニズムがあります。

CLB HTTPS レイヤー 7 リスナーの暗黙的リトライメカニズム

CLB HTTPS レイヤー 7 リスナーでバックエンドサーバーが応答しない、またはエラーを返す場合、CLB は暗黙的リトライメカニズムを自動的にトリガーします。CLB は正常なバックエンドサーバーを順番に試行します。リトライは CLB 自身によって開始され、クライアントには依存しません。タイムアウトが発生すると、CLB は 504 エラーを記録し、別のバックエンドノードにリトライします。クライアントに返されるのは最終試行の結果のみです。

リトライ記録の確認：CLB コンソールには、リトライログを照会するための専用インターフェイスは用意されていません。CLB のアクセスログでリトライ記録を確認できます。upstream_addr フィールドに複数の値 (カンマ区切り) がある場合、リトライが行われたことを示します。upstream_response_time の複数の値は、各試行の応答時間に対応します。例えば、upstream_addr: 10.0.0.1:80, 10.0.0.2:80 は、CLB が 2 台のバックエンドサーバーを順番に試行したことを示します。

クライアントの早期切断時の CLB の動作

いいえ。CLB は読み取りおよび書き込みの処理中にバックエンドサーバーとの接続を閉じません。

CLB のバックエンド永続接続の有効化

CLB インスタンスはバックエンド永続接続をサポートしていません。この機能を使用するには、Application Load Balancer (ALB) インスタンスを作成し、HTTP または HTTPS リスナーを設定して、対応する ALB サーバーグループでバックエンド永続接続を有効にしてください。詳細については、「Create and manage a server group」をご参照ください。

CLB の高レイテンシのトラブルシューティング

CLB インスタンス経由でバックエンドサービスにアクセスすると、バックエンドサーバーに直接アクセスする場合と比べて、わずかな追加レイテンシが発生します。これは正常な動作です。CLB のレイヤー 7 リスナーはリバースプロキシアーキテクチャ (Tengine) を使用するため、追加のネットワークホップとプロトコル処理時間が発生します。LVS を使用して転送するレイヤー 4 リスナーの追加レイテンシは、通常これより小さくなります。

レイテンシが著しく高い場合は、次の手順でトラブルシューティングしてください：

1. アクセスログを有効にしてレイテンシ関連フィールドを分析する：CLB アクセスログを有効にし、次のフィールドに注目します：

   • request_time：CLB が最初のリクエストパケットを受信してから応答を返すまでの時間 (秒)。

   • upstream_response_time：バックエンドサーバーへの接続確立から、データを完全に受信して接続が閉じられるまでの時間 (秒)。

2. レイテンシの発生箇所を切り分ける：

   • upstream_response_time が高い場合：バックエンドサーバー側の処理遅延が原因である可能性があります。バックエンドアプリケーションのパフォーマンス、データベースクエリの効率、リソース使用率 (CPU/メモリ) を確認するか、負荷分散のためにバックエンドサーバーを追加してください。

   • request_time が upstream_response_time より大幅に大きい場合、レイテンシはクライアントから CLB までのネットワークリンクにある可能性があります。クライアントから CLB サービスアドレスに対して継続的な ping テストを実行するか、MTR 経路トレースを実行してネットワークリンクの問題をトラブルシューティングできます。

3. リージョン間アクセス：クライアントと CLB インスタンスが異なるリージョンにある場合、物理距離に起因するネットワークレイテンシは避けられません。Global Accelerator (GA) を使用して、リージョン間アクセスの体験を最適化することを推奨します。

502、503、または 504 エラーのトラブルシューティング

CLB インスタンス経由でバックエンドサービスにアクセスする場合、502、503、または 504 のエラーコードは、通常、バックエンドサーバーでリクエストが正しく処理されなかったことを示します。各エラーコードの意味は次のとおりです：

• 502 Bad Gateway：CLB がバックエンドサーバーにリクエストを転送できない、またはバックエンドサーバーから応答を受信できない状態です。よくある原因として、バックエンドサービスに到達できない、またはすべてのヘルスチェックが失敗していることが挙げられます。

• 503 Service Temporarily Unavailable：通常、トラフィックの上限超過、またはバックエンドサーバーが利用できないことが原因です。このエラーは、瞬間的なトラフィックが CLB インスタンス仕様の上限を超えた場合に返されます。

• 504 Gateway Timeout：バックエンドサーバーがタイムアウトしました。よくある原因として、バックエンド側の処理時間が長い、またはバックエンドサーバーとの接続確立時にタイムアウトしたことが挙げられます。

最初の手順：アクセスログの確認

最初に、CLB アクセスログを有効にし、ログ内の status (CLB がクライアントに返したステータスコード) と upstream_status (バックエンドサーバーが CLB に返したステータスコード) フィールドを確認してください：

• status と upstream_status が同じ場合、CLB はバックエンドサーバーのエラーコードをそのままパススルーした可能性があります。バックエンドサーバーがこのエラーを返している理由を調査してください。

• upstream_status が「-」、または status と異なる場合、エラーは CLB によって返されています。次の点を参照してトラブルシューティングしてください。

502 エラーのトラブルシューティング

• すべてのバックエンドサーバーのヘルスチェックが失敗している：リスナーに関連付けられたすべてのバックエンドサーバーのヘルスチェックが失敗すると、CLB はリクエストを転送できず、代わりに 502 エラーを返します。コンソールでヘルスチェックのステータスを確認し、iptables またはサードパーティのセキュリティソフトウェアによって CLB システム CIDR ブロック 100.64.0.0/10 がブロックされている、ヘルスチェックのステータスコードが一致していない、ヘルスチェックパスが存在しないなど、失敗原因をトラブルシューティングしてください。詳細については、「CLB Health Check FAQ」をご参照ください。

• バックエンドが返したエラーコードを CLB が 502 に変換している：バックエンドサーバーが特定のエラーコード (504 や 444 など) を返した場合、CLB はクライアントに 502 エラーを返すことがあります。アクセスログの upstream_status フィールドを確認して、バックエンドが返した実際のステータスコードを特定し、バックエンドエラーの原因を調査してください。

• バックエンドサービスのエラー：バックエンドサーバーの高負荷、不正な応答、予期しない接続切断なども 502 エラーの原因になります。CPU やメモリなど、バックエンドサーバーのログとリソース使用率を確認してください。

503 エラーのトラブルシューティング

• トラフィックがインスタンス仕様の上限を超えている：受信トラフィックの QPS、帯域幅、または新規接続レートが現在の CLB インスタンス仕様の上限を超えると、CLB は 503 エラーを返します。これらのメトリクスは、Cloud Monitor から取得できます。

• 瞬間的なトラフィックが上限を超えているが監視には表示されない：Cloud Monitor は分単位の粒度でデータを表示するため、秒レベルのスパイクが表示されない場合があります。アクセスログで秒レベルのリクエスト数を確認してください。upstream_status が「-」の場合、リクエストがバックエンドサーバーに送信されなかったことを示します。

504 エラーのトラブルシューティング

• バックエンドの応答タイムアウト：バックエンドサーバーが、リスナーに設定されたリクエストタイムアウト時間内に応答しない場合、CLB は 504 エラーを返します。アクセスログの upstream_response_time フィールドを確認してバックエンドの実際の応答時間を特定し、それに応じてリスナーのリクエストタイムアウトを調整してください。

• バックエンドの接続タイムアウト：CLB インスタンスがバックエンド ECS インスタンスとの TCP 3 ウェイハンドシェイクを完了するためのタイムアウトは 5 秒です。アクセスログの upstream_response_time が長すぎる場合、バックエンドサーバーとの接続問題を示している可能性があります。原因調査のためにパケットキャプチャを行うことを推奨します。

• バックエンドの高負荷：バックエンドサーバーでリソース使用率 (CPU、メモリなど) が高い場合、応答時間がタイムアウト時間を超えることがあります。バックエンドサービスのパフォーマンスを調査して最適化するか、負荷分散のためにバックエンドサーバーを追加してください。

CLB アクセス問題のトラブルシューティング

CLB インスタンスを設定した後にサービスにアクセスできない場合は、次の手順に従ってレイヤーごとにトラブルシューティングしてください：

1. ドメイン名の名前解決を確認する：ドメイン名を使用してサービスにアクセスする場合、ドメイン名が CLB インスタンスのサービスアドレスに正しく解決されることを確認してください。nslookup または dig コマンドを使用して名前解決を確認できます。ドメイン名の名前解決の誤りは、アクセス失敗の一般的な原因です。

2. リスナー設定を確認する：CLB コンソールで、リスナーが作成されているかを確認し、リスナーポートとプロトコルが正しく設定されていることを確認します。リスナーが存在しない、または設定が誤っている場合、CLB はリクエストを転送できません。

3. ヘルスチェックのステータスを確認する：CLB コンソールで、バックエンドサーバーのヘルスチェックのステータスを確認します。すべてのバックエンドサーバーがヘルスチェックに失敗している場合、CLB はリクエストを転送できません。

4. ファイアウォール設定を確認する：バックエンドサーバー上の iptables またはサードパーティのセキュリティソフトウェアが、バックエンドサービスのポートと CLB システム CIDR ブロック 100.64.0.0/10 を許可しているかを確認してください。

5. バックエンドサービスが正常に稼働していることを確認する：バックエンドサーバーに直接ログインし、telnet <private IP address of the backend server> <port> (レイヤー 4) または curl -I http://<private IP address of the backend server> (レイヤー 7) を実行して、バックエンドサービス自体が応答することを確認してください。

6. ネットワークリンクをトラブルシューティングする：異なるネットワーク環境から CLB サービスアドレスへのアクセスをテストしてください。ローカルネットワークのみが影響を受ける場合は、継続的な ping テストを実行するか、MTR 経路トレースを使用して追加調査を行えます。

IP ではアクセスできるがドメイン名ではアクセスできない

最も一般的な原因は、ドメイン名の ICP 登録が完了していないことです。

規制により、中国本土でドメイン名を使用してパブリックアクセスを提供する場合、有効な ICP 登録が必要です。ICP 登録がないドメインへのアクセスはブロックされ、403 のステータスコードが返されるか、接続がリセットされます。

次の手順に従って、問題をトラブルシューティングして解決することを推奨します：

1. ICP 登録ステータスを確認する：Alibaba Cloud ICP Filing System にログインして、ドメイン名の ICP 登録が完了しているかを確認してください。完了していない場合は、先に手続きを完了してください。詳細については、「ICP filing process」をご参照ください。

2. ICP 登録の引き継ぎが必要かどうかを確認する：ドメイン名が他のクラウドサービスプロバイダーで ICP 登録済みであり、Alibaba Cloud を初めて使用する場合は、Alibaba Cloud と登録情報を紐付けるために、transfer ICP filing も完了する必要があります。この引き継ぎを完了していない場合も、アクセスがブロックされる可能性があります。

3. その他の原因を切り分ける：ドメイン名の ICP 登録と ICP 登録の引き継ぎの両方が完了している場合は、ドメイン名の名前解決が CLB のサービスアドレスを正しく指しているか (nslookup または dig コマンドで確認できます)、および CLB のリスナーポートとプロトコルの設定がドメイン名でのアクセス方法と一致しているかを確認してください。

内部トラフィックに対するアクセス制御の影響

はい。アクセス制御はリスナーレベルで適用され、内部トラフィックとパブリックトラフィックの両方に影響します。特定のパブリック IP アドレスのみを許可する許可リストを設定した場合、許可リストに含まれない内部 IP アドレスからのリクエストはブロックされます。内部サービスへの影響を避けるため、関連する内部 CIDR ブロックを許可リストに追加するか、Cloud Firewall を使用して EIP へのパブリックアクセスを制限することを推奨します。

ストレステスト中のリクエストタイムアウトのトラブルシューティング

レイヤー 7 の CLB をストレステストした際に、504 のステータスコードまたはリクエストタイムアウトが発生し、ログ内の upstream_response_time が 5 秒付近に集中している場合、問題は通常、CLB とバックエンドサーバー間の TCP 3 ウェイハンドシェイク失敗に起因する接続タイムアウトです。よくある原因として、バックエンドサーバー上のコネクショントラッキングテーブル (nf_conntrack) がいっぱいになり、新規接続のパケットがドロップされることが挙げられます。

バックエンドサーバーにログインして /var/log/messages ログを確認してください。次のエラーメッセージが表示される場合、この問題を確認できます：

nf_conntrack: table full, dropping packet

解決策：実際のサービス要件に基づいて、次の nf_conntrack パラメーターの値を調整してください：

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_buckets=262144
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

注：前述のコマンドの効果は一時的です。インスタンスを再起動すると変更は失われます。変更を永続化するには、パラメーターを /etc/sysctl.conf に書き込んでください。

共有リスナーに対するバックエンド障害の影響

シナリオ：静的 Web サイト www.example.com と動的 Web サイト app.example.com など、複数の Web サイトを同じ CLB リスナーに紐付けているとします。動的 Web サイトのバックエンドデータベースで障害が発生すると、静的 Web サイトにもアクセスできなくなり、HTTP 502 エラーが返されます。

原因：両サイトは同じリスナーを共有しており、リスナーの ヘルスチェックドメイン名 には動的サイトのドメイン名が設定されています。動的サイトのバックエンドで障害が発生すると、すべてのバックエンドサーバーのヘルスチェックが失敗します。その結果、CLB はバックエンドへのトラフィック転送を停止し、このリスナー配下に設定されたすべてのサイトに影響します。

解決策：ビジネス分離を実現するため、動的サイトと静的サイトの負荷分散には別々の CLB インスタンスを使用してください。これにより、動的サイトの障害が静的サイトに影響しなくなります。

セッション維持が機能しない理由

• セッション維持が有効になっていない： リスナー設定でセッション維持が有効になっているかを確認してください。

• HTTP/HTTPS リスナーの問題： HTTP または HTTPS リスナーの場合、CLB はセッション維持に必要な Cookie を 4xx 応答に挿入できません。

  解決策：TCP リスナーに切り替えてください。TCP リスナーは、クライアントのソース IP アドレスを使用してセッション維持を行います。信頼性を高めるために、バックエンド ECS インスタンス側で Cookie を挿入し、Cookie の検証チェックを追加することもできます。

• 302 リダイレクトの問題： 302 リダイレクトにより、セッション維持に使用される SERVERID 文字列が変更される場合があります。

  バックエンド ECS インスタンスが 302 リダイレクトを返すと、CLB が挿入した Cookie 内の SERVERID 文字列が変更され、セッション維持が機能しなくなる可能性があります。

  トラブルシューティング方法：ブラウザの開発者ツール、またはパケットスニファを使用してリクエストとレスポンスをキャプチャします。パケットを分析し、302 リダイレクト応答の有無を確認したうえで、リダイレクト前後の Cookie 内の SERVERID 文字列を比較します。

  解決策：TCP リスナーに切り替えてください。TCP リスナーは、クライアントのソース IP アドレスを使用してセッション維持を行います。信頼性を高めるために、バックエンド ECS インスタンス側で Cookie を挿入し、Cookie の検証チェックを追加することもできます。

• セッション維持のタイムアウトが短すぎる： タイムアウト値を短く設定しすぎると、セッション維持が機能しない場合があります。

セッション維持文字列の確認

ブラウザの開発者ツール (F12) を使用して、レスポンスヘッダーに SERVERID 文字列またはカスタムキーワードが含まれているかを確認できます。または、curl www.example.com -c /tmp/cookie123 コマンドを実行して Cookie を保存し、その後 curl www.example.com -b /tmp/cookie123 を実行して次のリクエストで Cookie を送信します。

curl を使用したセッション維持のテスト

1. テストページを作成します。

   各バックエンド ECS インスタンスで、インスタンスのプライベート IP アドレスを表示するテストページを作成します。このアドレスで、どのサーバーがリクエストを処理しているかを特定できます。複数回のリクエストで IP アドレスが一貫している場合、セッション維持が機能しています。

2. Linux システムで curl コマンドを実行します。

   CLB のサービス IP アドレスが 10.170.XX.XX で、テストページの URL が http://10.170.XX.XX/check.jsp であるとします。

   1. テストに使用する Linux サーバーにログインします。

   2. 次のコマンドを実行して、ロードバランサーから Cookie を取得します。

      curl -c test.cookie http://10.170.XX.XX/check.jsp

      説明

      デフォルトでは、CLB はセッション維持に Cookie の挿入を使用します。ただし、curl はデフォルトで Cookie を保存も送信もしません。テストの前に Cookie を保存する必要があります。保存しない場合、後続の curl リクエストは Cookie なしで送信され、ランダムルーティングとなるため、セッション維持が機能していないと誤って判断する可能性があります。

   3. 次のコマンドを実行して継続的にテストします。

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '192.168.YY.YY';
          sleep 1;
      done

      説明

      a<=30 の 30 はテストの繰り返し回数で、必要に応じて変更できます。grep '192.168.YY.YY' コマンドは、表示される IP 情報をフィルタリングします。192.168.YY.YY をバックエンド ECS インスタンスのプライベート IP アドレスに置き換えてください。

   4. テストで返される IP アドレスを確認します。すべての応答が同じバックエンドサーバーのプライベート IP アドレスから返される場合、セッション維持は正常に機能しています。それ以外の場合、セッション維持は正常に機能していません。

バックエンド Cookie の設定: Cookie の上書き モード

レイヤー 7 のセッション維持に [Cookie の上書き] モードを選択した場合、バックエンドサーバー側で同じ名前の Cookie を設定する必要があります。Cookie 名は CLB コンソールで設定したものと完全に一致している必要があります。次の例は、一般的な Web サーバーでの設定方法を示しています：

server {
    listen 8080;
    server_name wqwq.example.com;
    location / {
        add_header Set-Cookie name=xxxx;
        root   html;
        index  index.html index.htm;
    }
}

サーバー負荷の偏りのトラブルシューティング

CLB インスタンスに複数のバックエンドサーバーを関連付けていて、1 台のサーバーの負荷が他のサーバーより著しく高い場合は、次の手順でトラブルシューティングしてください：

1. セッション維持が有効になっているかを確認する： CLB の HTTP/HTTPS リスナーは、Cookie の挿入によるセッション維持をサポートしています。セッション維持を有効にすると、同一クライアントからのすべてのリクエストは同じバックエンドサーバーにルーティングされます。一部のクライアントが大量のリクエストを生成すると、特定のバックエンドサーバーにトラフィックが集中し、負荷の偏りが発生します。

2. 均等に分散するためにセッション維持を無効にする： アプリケーションがセッション状態 (Cookie やサインイン状態など) に依存しない場合は、リスナーのセッション維持を無効にしてください。無効にすると、CLB は重み付きラウンドロビンなど、設定されたスケジューリングアルゴリズムに基づいて、すべてのバックエンドサーバーにリクエストを均等に分散します。この操作はオフピーク時間に実施し、直後にアプリケーションが引き続き利用できることを確認してください。セッション維持を無効にすると、ショッピングカートやサインイン状態の維持などのステートフルサービスに影響します。実施前に、アプリケーションがセッション維持に依存しているかどうかを評価してください。

3. バックエンドサーバーにおけるアプリケーション負荷の確認： CLB がトラフィックを均等に分散している場合でも、バックエンドサーバー自体の CPU、メモリなどのリソース使用状況の違いにより、一部のサーバーの負荷が高くなることがあります。各バックエンドサーバーにログインし、アプリケーションのリソース使用状況を比較して、パフォーマンスボトルネックがないかを確認してください。

HTTPS 経由でスタイルが読み込まれない

症状：

HTTP リスナーと HTTPS リスナーがあり、両方とも同じバックエンドサーバーを使用しています。HTTP リスナー経由で Web サイトにアクセスすると、正しく表示されます。ただし、HTTPS リスナー経由で Web サイトにアクセスすると、レイアウトが崩れて表示されます。

原因：

ロードバランサーは、デフォルトでスタイルシート (CSS) ファイルをブロックしません。この問題は、以下の原因で発生する可能性があります。

• 証明書がブラウザのセキュリティレベルと互換性がない。

• 信頼されていないサードパーティプロバイダーからの証明書である。この問題を解決するには、発行元にお問い合わせください。

解決策：

1. Web サイトを開く際に、ブラウザのプロンプトに従ってブロックされたコンテンツの読み込みを許可してください。

2. 対応する証明書をクライアントの信頼ストアに追加してください。

HTTP から HTTPS へのリダイレクトのためのバックエンドサーバー証明書

いいえ。 CLB インスタンスの HTTPS リスナーに証明書を設定するだけで十分です。詳細については、「SSL 証明書の設定」をご参照ください。

更新後にブラウザに古い証明書の有効期限が表示される

これは通常、CLB インスタンスが WAF 2.0 と透過的に統合されており、WAF の証明書が更新されていない場合に発生します。WAF は CLB から証明書を定期的に同期します。即座に同期をトリガーするには、WAF コンソールでトラフィックリダイレクションを無効にしてから再度有効にすることで、証明書の更新を強制できます。この操作により、1 ~ 2 秒間の短いサービス中断が発生する可能性があります。

バックエンドサーバーアクセス用の HTTP プロトコルバージョン

• クライアントリクエストが HTTP/1.1 または HTTP/2.0 を使用する場合、レイヤー 7 リスナーは HTTP/1.1 を使用してバックエンドサーバーと通信します。

• クライアントリクエストが HTTP/1.1 または HTTP/2.0 以外のプロトコルバージョンを使用する場合、レイヤー 7 リスナーは HTTP/1.0 を使用してバックエンドサーバーと通信します。

クライアントプロトコルバージョンの取得

はい。

URL ベースの制限

CLB は URL ベースの制限をサポートしておらず、リスナーレベルでの帯域幅制限のみをサポートしています。

ALB は URL ベースの制限をサポートしています。 リスナー転送ルールを設定して、特定のパスに QPS 制限を適用できます。 この機能は、「転送先」アクションと組み合わせて使用する必要があります。

CLB はサーバー送信イベント (SSE) をサポートしていますか？

サーバー送信イベント (SSE) は HTTP ベースのテクノロジーであり、サーバーがクライアントにデータを一方的にプッシュできるようにします。 これは、リアルタイムのデータストリーミングシナリオで一般的に使用されます。

• レイヤー 7 CLB は SSE プロトコルをサポートしています。

• レイヤー 4 CLB は SSE プロトコルをサポートしていません。

使用上の制限： CLB レイヤー 7 リスナーは SSE をサポートしていますが、HTTP 持続的接続 (keep-alive) での SSE の使用はサポートしていません。 短時間接続を使用する必要があります。

Transfer-Encoding: chunked フィールド

Transfer-Encoding: chunked は、メッセージ本文がチャンク転送で送信されることを示す標準の HTTP プロトコルフィールドです。 レイヤー7 CLB は Tengine 上に構築されたリバースプロキシで、バックエンドサーバーにリクエストを転送する際にチャンク転送を使用します。 このため、バックエンドサーバーはリクエストヘッダーでこのフィールドを受信します。 これはリバースプロキシの正常な動作であり、お客様のサービスに影響はありません。 レイヤー4 CLB はトラフィックを転送するだけで、このフィールドを追加しません。

削除されるレスポンスヘッダーフィールド

セッション維持を実装するために、CLB はレスポンスヘッダーから Date、Server、X-Pad、および X-Accel-Redirect などのフィールドを削除します。これらのフィールドを保持するには、xl-server などのプレフィックスをカスタムレスポンスヘッダーに追加するか、レイヤー 4 TCP リスナーに切り替えることができます。

proxy_buffering と proxy_cache

CLB では、proxy_buffering 機能および proxy_cache 機能は有効になっていません。CLB は、リクエストデータやレスポンスデータをバッファリングまたはキャッシュすることなく、透過転送モードでクライアントリクエストをバックエンドサーバーに直接転送します。これは CLB のデフォルトの動作であり、追加設定は不要です。

CLB はフォワードプロキシをサポートしていますか？

CLB はフォワードプロキシをサポートしていません。 CLB はリバースプロキシのロードバランサーです。クライアントリクエストをバックエンドサーバーに分散しますが、フォワードプロキシのようにクライアントの外部リソースへのアクセスをプロキシすることはできません。 フォワードプロキシ機能が必要な場合は、Nginx などのサービスを使用して独自のフォワードプロキシを構築してください。

Classic Load Balancer (CLB) に対する WAF 保護の有効化

パブリック ENI を無効にした場合の影響

ECS インスタンスにパブリック IP アドレスがある場合、そのパブリック Elastic Network Interface (ENI) を無効にすると、ロードバランサーサービスに影響します。

これは、ENI が存在する場合、デフォルトルートがパブリックネットワーク経由でトラフィックを転送するためです。インターフェイスを無効にすると、応答パケットが返信されなくなり、ロードバランサーサービスが中断されます。ENI を無効にしないことを推奨します。無効にする必要がある場合は、デフォルトルートをプライベートネットワークに変更して、サービスの中断を回避してください。ただし、RDS へのアクセスなど、サービスがパブリックネットワークアクセスに依存しているかどうかを考慮してください。

TOA フィールドを含むクライアントリクエストへの対応

いいえ。クライアントが提供する TCP Option Address (TOA) フィールドは、ロードバランサーが内部通信に使用する TOA フィールドと競合します。この競合により、バックエンドサーバーがクライアントのリアル IP アドレスを取得できなくなります。