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

CLB はポート フォワーディングをサポートしていますか？

はい。

CLB はポート フォワーディングをサポートしています。詳細については、「HTTP から HTTPS へのリクエストのリダイレクト」をご参照ください。

レイヤー 4 CLB リスナーはポート範囲をリッスンできますか？

いいえ、できません。TCP または UDP リスナーでポート範囲をリッスンするように設定するには、Network Load Balancer (NLB) インスタンスを作成し、TCP または UDP リスナーに対して全ポートリッスン機能を有効化します。詳細については、「NLB のマルチポートリッスンおよび転送の有効化」をご参照ください。

CLB のリスナーポートを構成する前に確認すべき事項は何ですか？

一部の通信事業者は、特定のリージョンにおいて、25、135、139、444、445、5800、5900 などの高リスクポートのトラフィックをデフォルトでブロックしています。これらのポートをセキュリティグループルールで開放したとしても、制限対象のリージョンにいるユーザーは、これらのポート経由で CLB インスタンスにアクセスできません。サービスには他のポートを使用することを推奨します。

• Windows Server オペレーティングシステム上のアプリケーションで使用されるポートについては、Windows ドキュメントの「Windows のサービスの概要とネットワークポートの要件」をご参照ください。

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

WebSocket または WebSocket Secure プロトコルを使用するバックエンドサービスには、どのリスナーを選択すればよいですか？

• WebSocket プロトコルを使用するバックエンドサービスには、TCP または HTTP リスナーを使用します。

• WebSocket Secure プロトコルを使用するバックエンドサービスには、TCP または HTTPS リスナーを使用します。

CLB リスナーの構成変更はいつから有効になりますか？また、影響範囲はどれくらいですか？

変更は即時反映され、新規のリクエストにのみ適用されます。既存の接続には影響しません。

モニタリングデータで CLB インスタンスの最大帯域幅に達していないと表示されているにもかかわらず、パケット損失が発生するのはなぜですか？

考えられる原因は以下のとおりです。

• Alibaba Cloud の帯域幅モニタリングデータは、1 分間の平均値に基づいています。1 分間に数秒間だけ瞬間的なトラフィックが帯域幅制限を超えた場合、その 1 分間の平均帯域幅は設定された制限以下に留まる可能性があります。この場合、モニタリングダッシュボードでは全体の帯域幅使用率が制限以下と表示されますが、パケット損失は発生する可能性があります。

• CLB は、複数のバックエンドサーバーにリクエストを分散させることでロードバランシングサービスを提供します。設定された帯域幅制限は、複数のバックエンドサーバーに分散されます。クライアントのリクエストが単一サーバーのしきい値を超えると、パケット損失が発生します。各接続ごとのダウンロード制限の計算方法については、「一部のシナリオで最大帯域幅に到達できない理由」をご参照ください。

モニタリングダッシュボードに表示されるトラフィックが、設定されたレート制限を超えているのはなぜですか？

CLB はクラスターデプロイおよび分散型レート制限を採用しています。 ノードごとのレート制限 = CLB インスタンスの合計帯域幅/(N−1)（N はクラスター内のノード数）です。このため、実効的な合計レート制限が設定値を若干上回ることがあります。

一部のシナリオで最大帯域幅に到達できないのはなぜですか？

• 現象：単一クライアントからのストレステストや、インターネット向けの帯域幅課金型 CLB インスタンスへの大規模パケット転送を行うと、接続が最大帯域幅に到達しないことがあります。

• 原理（原因）：

  CLB は、複数のバックエンドサーバーにリクエストを分散させることでロードバランシングサービスを提供します。設定された帯域幅制限は、複数のバックエンドサーバーに分散されます。

  単一接続経由でのダウンロード上限は、以下の式で算出されます：接続ごとの最大帯域幅 = CLB インスタンスの合計帯域幅/(N−1)（N はクラスター内のノード数）。レイヤー 4 リスナーの場合、N は 4 です。レイヤー 7 リスナーの場合、N は 8 です。たとえば、コンソールで 10 Mbps の帯域幅制限を設定した場合、複数のクライアントが同時に CLB インスタンスにアクセスすると、合計帯域幅は 10 Mbps に達します。一方、単一クライアントは最大で 10/(4−1)=3.33 Mbps のダウンロードが可能です。

• 解決策：

  • CLB インスタンスにトラフィック課金方式を適用します。

  • Elastic IP Address (EIP) およびインターネット共有帯域幅インスタンスを備えた Network Load Balancer (NLB) または Application Load Balancer (ALB) インスタンスを使用します。このソリューションは、より高い弾力性を提供し、この制限を回避できます。

一部のシナリオで最大 QPS に到達できないのはなぜですか？

• 現象：少数の永続的接続のみを使用している場合、転送グループ内のすべてのバックエンドサーバーに接続が届かないことがあります。その結果、CLB インスタンスが最大 QPS に到達できないことがあります。

• 理由：

  CLB は、複数のバックエンドサーバーにリクエストを分散させることでロードバランシングサービスを提供します。設定された QPS 制限は、複数のバックエンドサーバーに分散されます。

  バックエンドサーバーごとの最大 QPS は、以下の式で算出されます：バックエンドサーバーごとの最大 QPS = 合計 QPS/(N−1)（N は転送グループ内のバックエンドサーバー数）。たとえば、コンソールで Small I (slb.s1.small) 型の CLB インスタンスを購入した場合、最大 QPS は 1,000 です。複数のクライアントが同時にアクセスすると、合計 QPS は 1,000 に達します。バックエンドサーバーが 8 台の場合、各サーバーは最大で 1000/(8−1)=142 QPS を処理できます。

  説明

• 推奨される解決策：

  • ストレステストには、単一クライアントからの短命接続を使用します。

  • 必要に応じて、接続の再利用を減らします。

  • CLB インスタンスのスペックをアップグレードします。詳細については、「従量課金（スペック課金）インスタンスのアップグレードまたはスペックダウン」をご参照ください。

  • より高い弾力性を提供する ALB インスタンスを使用します。

一部のシナリオで新規接続数が上限に達しないのはなぜですか？

• 現象：サブスクリプション型 CLB インスタンスを購入した後、クライアント側のストレステストや単一ソースからのアクセスなど、特定のシナリオにおいて、1 秒あたりの新規接続数（CPS）が指定された上限に達しないことがあります。

  説明

• 原因：

  CLB は、高可用性およびスケーラビリティを確保するためにクラスターデプロイを採用しています。外部からの接続要求は、クラスター内の複数のシステムサーバーに均等に分散されます。その結果、CPS 制限もこれらのサーバーに分散されます。

  システムサーバーごとの最大 CPS は、以下の式で算出されます：システムサーバーごとの最大 CPS = CLB インスタンスの合計 CPS/(N−1)（N は転送グループ内のサーバー数）。

  たとえば、Small I (slb.s1.small) 型の CLB インスタンスを購入した場合、宣言された CPS は 3,000 です。複数のクライアントが同時にアクセスすると、合計 CPS は 3,000 に達します。システムサーバーが 4 台の場合、各サーバーは最大で 3,000/(4−1)=1,000 CPS を処理できます。

• 解決策：

  • 課金方法を変更します：サブスクリプションから従量課金へ切り替えます。従量課金型 CLB インスタンスはスペックを必要とせず、ほとんどのサブスクリプション型インスタンスよりも高いパフォーマンスを提供します。これにより、スペック不足によるパフォーマンス問題を回避できます。

  • Network Load Balancer（NLB）を使用します：NLB は、高同時接続数や 1 秒あたりの新規接続数が非常に多いシナリオに最適です。CLB と比較して、NLB は大幅に優れたパフォーマンスと弾力性を提供します。これにより、NLB は大規模な同時接続を効果的に処理でき、CLB の固定サーバー数に起因する CPS 制限を回避できます。

各タイプのリスナーにおける接続タイムアウト期間はどれくらいですか？

• TCP リスナー：10 ～ 900 秒。

• HTTP リスナー：

  • アイドル接続タイムアウト期間：1 ～ 60 秒。

  • 接続要求タイムアウト期間：1 ～ 180 秒。

• HTTPS リスナー：

  • アイドル接続タイムアウト期間：1 ～ 60 秒。

  • 接続要求タイムアウト期間：1 ～ 180 秒。

CLB のサービスアドレスへの接続がタイムアウトするのはなぜですか？

サービスエンドポイントへの接続が、サーバー側でタイムアウトする状況は以下のとおりです。

• サービスエンドポイントが保護されています。

  これは、トラフィックブラックホール、トラフィックスクラブ、Web Application Firewall（WAF）による保護などが原因で発生します。WAF は接続確立後に、クライアントおよびバックエンドサーバーの両方に Reset（RST）パケットを送信します。

• クライアント側のポート枯渇

  ストレステスト中に、クライアント側でポート枯渇が発生することがあります。デフォルトでは、CLB は TCP 接続からタイムスタンプ属性を削除します。その結果、Linux カーネルの `tw_reuse` 設定（TIME_WAIT 状態の接続を再利用する機能）が無効になります。これにより、TIME_WAIT 接続が蓄積し、利用可能なポートが枯渇します。

  解決策：クライアント側では、短命接続ではなく永続的接続を使用します。FIN パケットではなく RST パケット（SO_LINGER ソケットオプションを設定）を送信して接続を閉じます。

• バックエンドサーバーの accept キューが満杯

  バックエンドサーバーの accept キューが満杯になると、サーバーは SYN-ACK パケットの応答を停止します。これにより、クライアントのリクエストがタイムアウトします。

  解決策：net.core.somaxconn のデフォルト値は 128 です。業務要件に応じてこの値を評価・調整し、sysctl -w net.core.somaxconn=<希望値> コマンドを実行してパラメーターを更新し、バックエンドサーバー上のアプリケーションを再起動します。

• レイヤー 4 CLB インスタンスのバックエンドサーバーからの CLB アクセス

  レイヤー 4 CLB（TCP/UDP）は、バックエンドサーバーがクライアントおよびサーバーの両方として動作するシナリオをサポートしていません。このようなシナリオでバックエンドサーバーから CLB サービスアドレスにアクセスすると、接続が失敗します。よくあるトリガーは、バックエンドアプリケーションが URL 結合を使用して CLB サービスアドレスにリダイレクトすることです。

  解決策：

  • レイヤー 4 CLB のバックエンドサーバーではなく、別のクライアントを使用します。

  • Network Load Balancer（NLB）に移行し、サーバーグループでクライアント IP アドレスの保持機能を無効化します。この機能を無効化すると、サーバーグループ内の ECS インスタンスは、バックエンドサーバーおよびクライアントの両方として NLB にアクセスできるようになります。送信元 IP アドレスを取得するには、ProxyProtocol を有効化します。詳細については、「ECS インスタンスが NLB のバックエンドサーバーおよびクライアントの両方として動作する方法」をご参照ください。

• タイムアウト接続に対する RST パケットの不適切な処理

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

  説明

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

HTTP および HTTPS リスナーに指定されたタイムアウト値は何ですか？

• HTTP 持続的接続では、連続して最大 100 回のリクエストを送信できます。この上限に達すると接続が閉じられます。

• HTTP 持続的接続のアイドルタイムアウトは、1 ～ 60 秒で設定可能ですが、誤差として 1 ～ 2 秒程度発生する可能性があります。このタイムアウトが経過すると、TCP 接続が閉じられます。アプリケーションで持続的接続を必要とする場合は、クライアントを 13 秒以内の間隔でハートビートリクエストを送信するように設定します。

• CLB インスタンスと Elastic Compute Service（ECS）インスタンス間の TCP 3 ウェイハンドシェイクのタイムアウトは 5 秒です。ハンドシェイクがタイムアウトした場合、CLB は次の ECS インスタンスを選択します。問題の特定には、アクセスログの upstream 応答時間（upstream response time）を確認します。

• CLB インスタンスが ECS インスタンスからの応答を待機する時間は、1 ～ 180 秒で設定可能です。待機時間がタイムアウトに達すると、CLB はクライアントに HTTP 504 または 408 状態コードを返します。問題の特定には、アクセスログの upstream 応答時間（upstream response time）を確認します。

• HTTPS セッションの再利用は 300 秒後にタイムアウトします。その後、クライアントは完全な SSL ハンドシェイクを再度実行する必要があります。

クライアントが CLB への応答を受信する前に接続を閉じた場合、CLB はバックエンドサーバー側の接続も閉じますか？

Server Load Balancer は、読み取り／書き込み操作中はバックエンドサーバーへの接続を維持します。

CLB インスタンスで持続的接続を有効化できますか？

いいえ、できません。CLB はバックエンドサーバーへの持続的接続の有効化をサポートしていません。この機能を実装するには、ALB インスタンスを作成し、HTTP または HTTPS リスナーを構成した後、対応する ALB サーバーグループで持続的接続を有効化します。詳細については、「サーバーグループの作成および管理」をご参照ください。

CLB 経由でバックエンドサービスにアクセスした場合と、直接アクセスした場合とで、遅延が著しく大きくなるのはなぜですか？

CLB 経由でバックエンドサービスにアクセスした場合、直接アクセスした場合と比較して、わずかな遅延増加は正常です。これは、レイヤー 7 CLB リスナーがリバースプロキシアーキテクチャ（Tengine）を採用しており、ネットワークホップが 1 つ追加され、プロトコル処理のオーバーヘッドが発生するためです。レイヤー 4 リスナーは LVS フォワーディングを採用しており、追加される遅延は最小限です。

遅延が著しく大きい場合は、以下の手順でトラブルシューティングを行ってください。

1. アクセスログを有効化し、遅延関連フィールドを分析する：「CLB アクセスログ」を有効化し、以下のフィールドに注目します。

   • request_time：最初のリクエストパケットを受信してから応答を返すまでの時間（秒単位）。

   • upstream_response_time：バックエンドサーバーとの接続確立から、すべてのデータを受信して接続を閉じるまでの時間（秒単位）。

2. 遅延の発生源を特定する：

   • upstream_response_time の値が高い場合、遅延の原因はバックエンド処理の遅さである可能性があります。バックエンドアプリケーションのパフォーマンス、データベースクエリの効率、CPU およびメモリ使用率を調査するか、負荷分散のためにバックエンドサーバーを追加します。

   • request_time の値が upstream_response_time の値より著しく大きい場合、遅延の原因はクライアントと CLB インスタンス間のネットワークパスにある可能性があります。クライアントから CLB サービスアドレスへの継続的な ping テストまたは MTR トレーサルートを実行して、ネットワークの問題を特定します。

3. クロスリージョンアクセス：クライアントと CLB インスタンスが異なるリージョンに存在する場合、物理的な距離によって必然的にネットワーク遅延が発生します。この場合、Global Accelerator（GA）を使用してクロスリージョンアクセスを最適化できます。

CLB が返す 502/503/504 エラーをトラブルシューティングするにはどうすればよいですか？

CLB インスタンスが 502、503、または 504 エラーを返す場合、リクエストがバックエンドサーバーによって正しく処理されていないことを意味します。これらのエラーコードの意味は以下のとおりです。

• 502 Bad Gateway：CLB インスタンスがリクエストをバックエンドサーバーに転送できない、またはバックエンドサーバーからの応答を受信できない場合に発生します。一般的な原因には、バックエンドサービスへの到達不能やヘルスチェックの失敗があります。

• 503 Service Temporarily Unavailable：通常、トラフィックが制限を超えた場合やバックエンドサーバーが利用不可の場合に発生します。CLB は、瞬間的なトラフィックがインスタンスのスペック制限を超えた場合にこのエラーを返します。

• 504 Gateway Time-out：バックエンドサーバーからの応答がタイムアウトした場合に発生します。一般的な原因には、バックエンド処理時間の過剰やバックエンド接続確立のタイムアウトがあります。

ステップ 1：アクセスログを確認する

まず、「CLB アクセスログ」を有効化し、status フィールド（CLB がクライアントに返す状態コード）および upstream_status フィールド（バックエンドサーバーが CLB に返す状態コード）を確認します。

• status の値と upstream_status の値が一致する場合、CLB インスタンスはバックエンドサーバーから異常な状態コードを転送した可能性があります。バックエンドサーバーがその状態コードを返した原因を優先的に調査してください。

• upstream_status の値が "-" であるか、status の値と異なる場合、エラーコードは CLB によって生成されたものです。以下の項目を参照してトラブルシューティングを行ってください。

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

• すべてのバックエンドサーバーがヘルスチェックに失敗：リスナーに関連付けられたすべてのバックエンドサーバーがヘルスチェックに失敗すると、CLB インスタンスはリクエストを転送できず、502 エラーを返します。コンソールでヘルスチェックのステータスを確認し、失敗の原因を調査します。たとえば、セキュリティグループルールが 100.64.0.0/10（CLB システム CIDR ブロック）からのトラフィックを許可していない、ヘルスチェックのステータスコードが不一致である、ヘルスチェックパスが存在しないなどです。詳細については、「CLB ヘルスチェックに関するよくある質問」をご参照ください。

• バックエンドサーバーが CLB によって 502 に変換される異常な状態コードを返す：バックエンドサーバーが 504 や 444 などの特定の異常な状態コードを返す場合、CLB はクライアントに 502 エラーを返すことがあります。アクセスログの upstream_status フィールドを確認して、バックエンドサーバーが実際に返した状態コードを特定し、根本原因を調査します。

• バックエンドサービスの異常：バックエンドサーバーの高負荷、不正な応答フォーマット、予期しない接続の切断なども、502 エラーの原因となります。バックエンドサーバーのログおよび CPU やメモリなどのリソース使用率を確認します。

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

• トラフィックがインスタンスの制限を超える：QPS、帯域幅、または新規接続数が現在のスペックの制限を超えると、CLB は 503 エラーを返します。これらのメトリックは、「CloudMonitor」を使用してモニタリングできます。

• 瞬間的なトラフィックが制限を超えるが、モニタリングでは検出されない：CloudMonitor は 1 分単位のデータを表示するため、1 秒単位のピークを見逃す可能性があります。アクセスログで 1 秒単位のリクエスト数を確認します。upstream_status の値が "-" の場合、リクエストはバックエンドサーバーに送信されていません。

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

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

• バックエンド接続確立のタイムアウト：CLB インスタンスと ECS インスタンス間の TCP 3 ウェイハンドシェイクのタイムアウトは 5 秒です。upstream_response_time の値がアクセスログで異常に長い場合、バックエンドサーバーとの接続確立に失敗している可能性があります。パケットキャプチャを実行して調査できます。

• バックエンドサーバーの高負荷：バックエンドサーバーの CPU やメモリ使用率が高いと、応答時間がタイムアウトを超過する可能性があります。バックエンドサービスのパフォーマンスを最適化するか、負荷分散のためにバックエンドサーバーを追加します。

CLB 経由でサービスにアクセスできない場合のトラブルシューティング手順を教えてください。

CLB を構成した後にサービスにアクセスできない場合は、以下の手順でトラブルシューティングを行ってください。

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

2. リスナーの構成を確認する：CLB コンソールで、リスナーが作成され、リスナーポートおよびプロトコルが正しく構成されていることを確認します。リスナーが欠落している、またはポート構成が不適切な場合、リクエストの転送は行われません。

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

4. セキュリティグループおよびファイアウォールの設定を確認する：バックエンドサーバーのセキュリティグループルールおよびファイアウォール設定が、バックエンドサービスポートおよび CLB システム CIDR ブロック 100.64.0.0/10 からのトラフィックを許可していることを確認します。

5. バックエンドサービスの可用性を確認する：バックエンドサーバーにログインし、telnet <バックエンドサーバーのプライベート IP アドレス> <ポート>（レイヤー 4 の場合）または curl -I http://<バックエンドサーバーのプライベート IP アドレス>（レイヤー 7 の場合）を実行して、バックエンドサービスが期待通りに応答することを確認します。

6. ネットワーク接続をトラブルシューティングする：異なるネットワーク環境から CLB サービスアドレスへのアクセスをテストします。ローカルネットワークのみで問題が発生する場合、継続的な ping テストまたは MTR トレーサルートを実行してさらに調査します。

ドメイン名では CLB にアクセスできませんが、IP アドレスでは正常にアクセスできます。どうすればよいですか？

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

規制によると、中国本土でパブリックネットワークアクセスを提供するドメイン名には、ICP 登録が必要です。登録されていないドメイン名はブロックされ、403 状態コードまたは接続のリセットが発生します。

この問題をトラブルシューティングおよび解決するには、以下の手順を実行します。

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

2. プロバイダー登録の必要性を確認する：ドメイン名が他のクラウドプロバイダーで登録済みでも、Alibaba Cloud 上で初めて使用する場合は、プロバイダー登録 を実行して、登録情報に Alibaba Cloud をサービスプロバイダーとして追加する必要があります。プロバイダー登録を完了しないと、アクセスがブロックされる可能性があります。

3. その他の原因を除外する：ドメイン名が登録済みであり、プロバイダー登録も完了している場合、DNS 解決が CLB サービスアドレスを指していることを確認します。これには、nslookup または dig を使用して検証できます。また、CLB リスナーポートおよびプロトコルの構成が、ドメイン名によるアクセス方法と一致していることを確認します。

一部のシナリオでセッション維持が失敗するのはなぜですか？

• セッション維持が有効化されていない：リスナー構成でセッション維持が有効化されていることを確認します。

• HTTP/HTTPS リスナーの問題：HTTP または HTTPS リスナーは、4xx 状態コードを持つ応答にセッション維持用の Cookie を挿入できません。

  解決策：代わりに TCP リスナーを使用します。TCP リスナーはクライアントの送信元 IP アドレスに基づいてセッションを維持します。あるいは、バックエンド ECS インスタンスを構成して Cookie を挿入および検証することで、信頼性を高めることもできます。

• 302 リダイレクトの問題：302 リダイレクトにより、セッション維持に使用される SERVERID 文字列が変更されることがあります。CLB インスタンスが HTTP 302 状態コードを持つ応答に Cookie を挿入すると、SERVERID 文字列が変更され、セッション維持が失敗します。

  Server Load Balancer が Cookie を挿入する際に、バックエンド ECS インスタンスが 302 リダイレクトメッセージを返すと、セッション維持用の SERVERID 文字列が変更され、セッション維持が失敗します。

  この問題を診断するには、ブラウザでリクエストおよび応答をキャプチャするか、パケットキャプチャソフトウェアを使用して 302 応答を確認し、リダイレクト前後の Cookie 内の SERVERID 文字列を比較します。

  解決策：代わりに TCP リスナーを使用します。TCP リスナーはクライアントの送信元 IP アドレスに基づいてセッションを維持します。あるいは、バックエンド ECS インスタンスを構成して Cookie を挿入および検証することで、信頼性を高めることもできます。

• セッション維持のタイムアウトが短すぎる：タイムアウト期間を短く設定すると、セッション維持が失敗する可能性があります。

セッション維持文字列を確認するにはどうすればよいですか？

ブラウザを開き、F12 キーを押して、応答に SERVERID 文字列またはユーザー定義のキーワードが含まれているかどうかを確認できます。あるいは、curl www.example.com -c /tmp/cookie123 コマンドを実行して Cookie を保存し、その後 curl www.example.com -b /tmp/cookie123 コマンドを実行してサイトにアクセスできます。

Linux curl コマンドを使用してセッション維持をテストするにはどうすればよいですか？

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

   各バックエンド ECS インスタンスで、インスタンスのプライベート IP アドレスを表示するテストページを作成します。プライベート IP アドレスは、リクエストを処理したサーバーを識別します。各リクエストで同じ IP アドレスが返される場合、セッション維持は成功しています。

   

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

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

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

   2. 以下のコマンドを実行して、CLB サーバーによって設定された Cookie を取得します。

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

      説明

      デフォルトでは、CLB は Cookie を挿入してセッションを維持します。ただし、curl はデフォルトで Cookie を保存および送信しないため、テスト前に Cookie を保存する必要があります。これを怠ると、curl のテスト結果はランダムになり、誤ってセッション維持が失敗していると判断される可能性があります。

   3. 以下のコマンドを実行して、連続テストを行います。

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

      説明

      a≤30 はテスト反復回数であり、必要に応じて調整できます。grep '10.170.XX.XX' は、お使いの ECS インスタンスのプライベート IP アドレスに置き換えてください。

   4. テストで返された IP アドレスを確認します。同じ ECS のプライベート IP アドレスが一貫して表示される場合、セッション維持は正常に機能しています。そうでない場合、セッション維持が失敗しています。

HTTPS リスナー経由で Web サイトを開いたときに、スタイルシートの読み込みに失敗するのはなぜですか？

現象：

同一のバックエンドサーバーを使用する HTTP リスナーおよび HTTPS リスナーを作成しました。指定されたポート番号で HTTP リスナー経由で Web サイトにアクセスすると、Web サイトは正常に表示されます。しかし、HTTPS リスナー経由でアクセスすると、レイアウトが崩れます。

原因：

デフォルトでは、CLB は JavaScript ファイルの読み込みまたは転送をブロックしません。考えられる原因は以下のとおりです。

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

• 証明書が無効な第三者証明書である。証明書の発行者に連絡して、証明書の有効性を確認してください。

解決策：

1. Web サイトを開いた際に、ブラウザの指示に従ってスクリプトを読み込みます。

2. 必要な証明書をクライアントに追加します。

HTTP リスナーから HTTPS リスナーへのトラフィックリダイレクトを有効化した場合、バックエンドサーバーに証明書をデプロイする必要がありますか？

いいえ、必要ありません。証明書は CLB インスタンスにのみデプロイし、HTTPS リスナーに対して構成する必要があります。詳細については、「SSL 証明書の構成」をご参照ください。

CLB が証明書を更新した後、ブラウザに表示されるドメイン名証明書の有効期限が変更されません。

この問題は、CLB インスタンスが透過プロキシモードで WAF 2.0 と統合されている場合に発生します。このモードでは、WAF 側の証明書は即時に更新されません。WAF は CLB から定期的に証明書を同期します。即時の更新を強制するには、WAF コンソールに移動し、保護対象のドメインのトラフィック転送を無効化した後、すぐに再有効化します。この操作により、WAF は CLB から証明書のステータスを強制的に更新します。ただし、この操作により約 1 ～ 2 秒間のサービス中断が発生します。

HTTP および HTTPS リスナーがバックエンドサーバーにアクセスする際に使用する HTTP のバージョンは何ですか？

• クライアントが HTTP/1.1 または HTTP/2 でリクエストを送信する場合、レイヤー 7 リスナーはバックエンドサーバーへのリクエスト転送に HTTP/1.1 を使用します。

• クライアントが HTTP/1.1 および HTTP/2 以外のプロトコルでリクエストを送信する場合、レイヤー 7 リスナーはバックエンドサーバーへのリクエスト転送に HTTP/1.0 を使用します。

バックエンドサーバーは、クライアントが HTTP または HTTPS リスナーにアクセスする際に使用したプロトコルバージョンを取得できますか？

はい。

CLB は特定の URL に対する QPS レート制限をサポートしていますか？

CLB は URL ベースのレート制限をサポートしていません。帯域幅の速度制限は、リスナー単位でのみサポートされています。

ALB は URL ベースのレート制限をサポートしています。特定のパスに対して QPS レート制限を設定するには、「リスナー転送ルールの構成」を実行し、転送先（Forward To）アクションを使用します。以下の図を参照してください。

CLB に WAF 保護を有効化するにはどうすればよいですか？

パブリックネットワークインターフェースコントローラー（NIC）を無効化した場合、CLB サービスに影響がありますか？

はい、影響があります。Elastic Compute Service（ECS）インスタンスにパブリック IP アドレスがある場合、パブリックネットワークインターフェースコントローラー（NIC）を無効化すると、CLB サービスに影響が出ます。

デフォルトでは、ECS インスタンスにパブリック IP アドレスがある場合、この IP アドレスを使用して通信を行います。トラフィックは ECS インスタンスのパブリック NIC を通じて流れます。パブリック NIC を無効化すると、ECS インスタンスはインターネットに対して応答を送信できなくなります。ECS インスタンスのパブリック NIC を無効化しないことを推奨します。やむを得ず無効化する場合は、デフォルトルートの宛先をプライベート IP アドレスに変更して、サービス障害を回避してください。また、ApsaraDB RDS インスタンスへのインターネット経由のアクセスなど、サービスがインターネットアクセスを必要とするかどうかを確認してください。

リクエストが CLB に送信される前に TCP Option Address（TOA）ヘッダーをすでに含んでいる場合、CLB はヘッダー内のクライアント IP アドレスを保持できますか？

いいえ、できません。TOA ヘッダーを含むクライアントリクエストは、CLB 内部で使用される TOA ヘッダーと競合し、クライアントの送信元 IP アドレスを取得できなくなります。