Server Load Balancer:Classic 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 ドキュメントの「Windows Server のサービスの概要とネットワークポートの要件」をご参照ください。

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

WebSocket のリスナー設定

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

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

リスナー設定変更の影響

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

URL 転送ルールでの特殊文字

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

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

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

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

Classic Load Balancer (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 インスタンスが適用します。

CLB 性能保証型インスタンスの帯域幅の計算方法

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 と共有帯域幅を使用した NLB または ALB インスタンスを使用してください。この構成はより柔軟で、この制限を回避できます。

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

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

• 原因：

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

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

  説明

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

• ソリューション：

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

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

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

  • ALB インスタンスを使用してください。このインスタンスタイプは、より高い柔軟性を備えています。

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

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

  説明

  性能保証型 CLB インスタンスの新規購入は、2025 年 6 月 1 日 00:00:00 (UTC+8) をもって終了となります。詳細については、「性能保証型 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) にアップグレードしてください。NLB は、CLB と比較して優れたパフォーマンスと柔軟性を備えています。単一の NLB インスタンスは 1 億の同時接続をサポートし、大規模アプリケーションに最適で、CLB クラスターアーキテクチャの CPS 制限を回避できます。

サポートされている接続タイムアウトの範囲

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

• HTTP リスナー：

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

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

• HTTPS リスナー：

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

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

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

以下のサーバー側の問題により、CLB サービスアドレスへの接続タイムアウトが発生する可能性があります。

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

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

• クライアントポートの不足

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

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

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

  バックエンドサーバーの accept キューがいっぱいの場合、サーバーは SYN-ACK 応答を送信しないため、クライアントでタイムアウトが発生します。

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

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

  CLB のレイヤー4 リスナー (TCP/UDP) では、バックエンドサーバーがクライアントとサーバーの両方として機能することはできません。バックエンドサーバーが、接続されている CLB インスタンスのサービスアドレスにアクセスしようとすると、接続は失敗します。一般的なトリガーシナリオには、URL を構築して CLB サービスアドレスにリダイレクトするバックエンドアプリケーションや、VPC 内の ECS インスタンスがパブリックネットワーク経由で自身の CLB インスタンスのサービスアドレスにアクセスすることによるトラフィックループバックなどがあります。

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

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

  • CLB インスタンスに複数のバックエンドサーバーがある場合 (たとえば、重みが等しい 2 台のバックエンドサーバー)、CLB はリクエストの約 50% を他のバックエンドサーバーに転送します (接続は成功します)。CLB はリクエストの約 50% を元のバックエンドサーバーに転送します (接続は失敗します)。全体的な成功率は約 50% です。

  解決策：

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

  • Network Load Balancer (NLB) インスタンスに移行し、サーバーグループで クライアント IP の保持 を無効にしてください。この機能を無効にすると、サーバーグループ内の ECS インスタンスは、NLB インスタンスのバックエンドサーバーとクライアントの両方として機能できます。クライアントの送信元 IP アドレスを取得するには、Proxy Protocol を有効にしてください。詳細については、「ECSインスタンスをNLBインスタンスのバックエンドサーバーとクライアントの両方として機能させる方法」をご参照ください。

  • 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 インスタンスを試行します。この問題は、アクセスログで upstream_response_time を確認することで特定できます。

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

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

CLB はタイムアウト後にリクエストを自動的にリトライしますか?

通常、CLB はリクエストを自動的にリトライしません。リクエストがリスナーに設定されたリクエストタイムアウト (たとえば、デフォルトの 60 秒) を超えた場合、CLB は接続を終了し、クライアントに 504 エラーコードを返します。この時点では、CLB はそれ以上のリトライを行いません。リクエストのリトライを実装するには、クライアント側でリトライロジックを実装する必要があります。ただし、HTTPS レイヤー7 リスナーには、個々のバックエンドサーバーへの接続が失敗した場合に作動する、特殊な内部リトライメカニズムがあります。詳細については、「CLB HTTPS レイヤー7 リスナーの暗黙的なリトライメカニズム」をご参照ください。

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

CLB の HTTPS レイヤー7 リスナーには、暗黙的なリトライメカニズムが組み込まれています。あるバックエンドサーバーへの接続試行が失敗した場合 (たとえば、応答がない、またはエラーが返された場合)、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 インスタンスは、バックエンド永続接続をサポートしていません。この機能を使用するには、ALB インスタンスを作成し、HTTP または HTTPS リスナーを設定し、対応する ALB サーバーグループのバックエンド永続接続を有効にしてください。詳細については、「サーバーグループの作成と管理」をご参照ください。

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 ヘルスチェックに関する 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 <バックエンドサーバーのプライベート IP アドレス> <ポート> (レイヤー 4) または curl -I http://<バックエンドサーバーのプライベート IP アドレス> (レイヤー 7) を実行して、バックエンドサービス自体が応答することを確認します。

6. ネットワークリンクのトラブルシューティング: さまざまなネットワーク環境から CLB サービスアドレスへのアクセスをテストします。お客様のローカルネットワークのみが影響を受ける場合、継続的な ping テストを実行するか、MTR ルートトレースを使用してさらに調査を行うことができます。

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

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

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

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

1. ICP 登録ステータスを確認する：Alibaba Cloud ICP 登録システムにログオンして、ドメイン名が ICP 登録を完了しているかどうかを確認してください。完了していない場合は、まずプロセスを完了してください。詳細については、「ICP 登録プロセス」をご参照ください。

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

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 はセッション維持に必要なクッキーを 4xx レスポンスに挿入できません。

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

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

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

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

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

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

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

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

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. 次のコマンドを実行して、ロードバランサーからクッキーを取得します。

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

      説明

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

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

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

      説明

      a <= 30 の 30 は繰り返しテストの回数であり、必要に応じて変更できます。grep '192.168.XX.XX' コマンドは、表示される IP 情報をフィルタリングします。192.168.XX.XX を、バックエンド 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. セッション維持が有効か確認する：CLB の HTTP/HTTPS リスナーは、Cookie の挿入によりセッション維持をサポートします。セッション維持を有効にすると、同一クライアントからのすべてのリクエストは同一のバックエンドサーバーにルーティングされます。少数のクライアントが大量のリクエストを生成すると、特定のバックエンドサーバーにトラフィックが集中し、不均一な負荷につながります。

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

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

HTTPS 経由でのスタイル読み込みエラー

症状：

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

原因：

ロードバランサーは、デフォルトでは JavaScript (JS) ファイルをブロックしません。この問題は、以下のいずれかが原因と考えられます。

• 証明書がブラウザのセキュリティレベルに対応していません。

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

解決策：

1. ウェブサイトを開く際に、ブラウザのプロンプトに従ってスクリプトを読み込んでください。

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 スロットリングを適用できます。この機能は、「転送先」アクションと組み合わせて使用する必要があります。

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

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

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

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

CLB の WAF 保護の有効化

パブリック ENI の無効化による影響

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

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

TOA フィールドを含むクライアントリクエストのサポート

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