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

クラシックロードバランサー (CLB) はポートリダイレクトをサポートしていますか？

はい。

CLB はポートリダイレクトをサポートしています。例については、「CLB を使用して HTTP リクエストを HTTPS にリダイレクトする」をご参照ください。

レイヤー 4 リスナーのポート範囲のサポート

いいえ。ポート範囲に対して TCP または UDP リスナーを設定するには、Network Load Balancer (NLB) インスタンスを作成し、TCP または UDP リスナーのマルチポートリッスン機能を有効にする必要があります。詳細については、「NLB のマルチポートリッスン機能を使用して複数ポートからのトラフィックを転送する」をご参照ください。

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

一部の通信事業者は、25、135、139、444、445、5800、5900 などのポートを高リスクポートとしてマークし、デフォルトでブロックします。セキュリティグループルールでこれらのポートのトラフィックを許可しても、制限されたリージョンのユーザーはアクセスできません。したがって、サービスには他の高リスクでないポートを使用してください。

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

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

WebSocket のリスナー設定

• WebSocket を使用するバックエンドサーバーには、TCP リスナーまたは HTTP リスナーを設定できます。

• WebSocket Secure を使用するバックエンドサーバーには、TCP リスナーまたは HTTPS リスナーを設定できます。

リスナー設定変更の影響

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

利用可能な帯域幅がある場合のパケット損失

この問題は、以下の理由で発生する可能性があります：

• Alibaba Cloud は帯域幅モニタリングデータを分単位で平均化します。1 分以内の特定の秒で瞬間的なトラフィックがインスタンスの最大帯域幅を超えても、その分全体の平均帯域幅が設定された制限を下回る場合、モニタリングチャートでは全体の帯域幅使用量が最大帯域幅未満であると表示されます。

• 負荷分散サービスはサーバークラスター上で実行され、すべての外部リクエストをサーバー間で均等に分散します。設定された最大帯域幅はこれらのサーバーに分散されます。クライアントがダウンロードを要求するデータ量が単一サーバーのしきい値を超えると、パケット損失が発生します。単一接続のダウンロード帯域幅制限の計算方法の詳細については、「特定のシナリオで接続が最大帯域幅に達しないことがあるのはなぜですか？」をご参照ください。

モニタリングされたトラフィックがレート制限を超える

負荷分散サービスはサーバークラスター上で実行され、分散型のレート制限メカニズムを使用します。単一ノードのピークレート制限は 単一ノードのピークレート制限 = 設定された総帯域幅 / (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 インスタンスを使用します。この設定は、より高い弾力性を提供し、これらの帯域幅制限を回避します。

最大 QPS に到達しない問題

• シナリオ：少数の長時間接続を使用している場合、転送グループ内のすべてのサーバーが利用されていないため、CLB インスタンスが最大 QPS に達しないことがあります。

• 原因：

  負荷分散システムは、クラスターデプロイを通じてロードバランサーインスタンスにサービスを提供します。すべての外部リクエストは、転送のためにクラスター内のシステムサーバーに均等に分散されます。したがって、CLB インスタンスの最大 QPS は複数のシステムサーバーに分散されます。

  単一システムサーバーの最大 QPS は次のように計算されます：単一システムサーバーあたりの最大 QPS = インスタンスの総 QPS / (N-1)。ここで N は転送グループ内のシステムサーバーの数です。例えば、1,000 QPS に対応する `slb.s1.small` スペックの CLB インスタンスを購入した場合、複数のクライアントが同時に使用すると総 QPS は 1,000 QPS に達することがあります。システムサーバーの数が 8 の場合、単一システムサーバーの最大 QPS は 1,000/(8-1)=142 QPS です。

  説明

• 推奨事項：

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

  • ビジネス要件に基づいて接続の再利用を減らします。

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

  • ALB インスタンスを使用します。このタイプのロードバランサーは十分な弾力性を提供します。

最大 CPS に到達しない問題

• シナリオ：スペック課金型のクラシックロードバランサー (CLB) インスタンスは、単一クライアントのストレステストや単一ソースからのトラフィックなど、特定のシナリオで指定された秒間新規接続数 (CPS) レートに達しない場合があります。

  説明

• 原因：

  負荷分散システムは、高可用性とスケーラビリティを確保するためにクラスターデプロイアーキテクチャを使用します。すべての着信接続リクエストは、クラスター内のシステムサーバー間で均等に分散されます。したがって、CLB インスタンスの最大 CPS はこれらのサーバーに分散されます。

  単一システムサーバーの最大 CPS は次のように計算されます：単一システムサーバーあたりの最大 CPS = インスタンスの総 CPS / (N-1)。ここで N は転送グループ内のシステムサーバーの数です。

  例えば、`slb.s1.small` スペックの CLB インスタンスを購入した場合、その公称 CPS は 3,000 です。複数のクライアントからの同時アクセス中、全体の CPS は 3,000 に達することがあります。システムサーバーの数が 4 の場合、単一サーバーの最大 CPS は 3,000/(4-1)=1,000 CPS です。

• 推奨事項：

  • CLB の課金方法を調整する：CLB インスタンスの課金方法をスペック課金から、より柔軟な従量課金に変更することを検討してください。従量課金インスタンスは特定のスペックを必要とせず、ほとんどのスペックベースのインスタンスよりも高いパフォーマンス制限を提供するため、スペック不足によるパフォーマンスボトルネックを防ぎます。

  • Network Load Balancer (NLB) へのアップグレード：高い同時実行性と新規接続の高い需要があるシナリオでは、NLB の使用を推奨します。CLB と比較して、NLB はより優れたパフォーマンスと弾力性を提供します。単一の NLB インスタンスは最大 1 億の同時接続を処理できるため、大規模な同時接続シナリオに適しており、CLB のシステムサーバー数の制限による CPS 不足を回避するのに役立ちます。

リスナーの接続タイムアウト範囲

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

• HTTP リスナー：

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

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

• HTTPS リスナー：

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

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

接続タイムアウトのトラブルシューティング

以下のサーバー側の問題が接続タイムアウトの原因となる可能性があります：

• サービスアドレスがセキュリティ保護下にある。

  例えば、トラフィックブラックホールやスクラビング、または Web Application Firewall (WAF) 保護 (WAF は接続確立後にクライアントとサーバークラスターの両方に RST パケットを送信します)。

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

  これは特にストレステスト中によく見られます。クライアントポートが不足すると、接続障害が発生する可能性があります。デフォルトでは、ロードバランサーは 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=<new_value> を実行してパラメーターを変更します。最後に、バックエンドサーバー上のアプリケーションを再起動します。

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

  レイヤー 4 CLB リスナー (TCP/UDP) は、バックエンドサーバーが自身のサービスアドレスにアクセスすることをサポートしていません。この操作は接続障害を引き起こします。一般的なシナリオは、バックエンドアプリケーションが URL を連結して CLB サービスアドレスにリダイレクトする場合です。

  ソリューション：

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

  • Network Load Balancer (NLB) に移行し、サーバーグループでクライアント IP の維持機能を無効にします。この機能を無効にすると、サーバーグループ内の ECS インスタンスは、バックエンドサーバーとして機能すると同時に、NLB インスタンスにアクセスするクライアントとしても機能できます。クライアントのソース IP を取得するには、Proxy Protocol を有効にできます。詳細については、「NLB で ECS インスタンスをバックエンドサーバーとクライアントの両方として機能させるにはどうすればよいですか？」をご参照ください。

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

  TCP 接続が確立された後、900 秒間アクティビティがない場合、ロードバランサーはクライアントとサーバーの両方に RST パケットを送信して接続を終了します。一部のアプリケーションは RST 例外を正しく処理せず、閉じた接続でデータを送信しようとすることがあり、これがアプリケーションのタイムアウトにつながります。

  説明

  デフォルト値は 900 秒で、必要に応じて調整できます。

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

• 持続的な HTTP 接続のリクエスト数は、最大 100 回の連続リクエストに制限されます。この制限を超えると接続は閉じられます。

• 持続的な接続における 2 つの HTTP または HTTPS リクエスト間のアイドルタイムアウトは、1～60 秒 (1～2 秒の誤差の可能性あり) の範囲で設定可能です。タイムアウト後、TCP 接続は閉じられます。長時間接続が必要な場合は、15 秒未満の間隔でハートビートリクエストを送信してください。

• ロードバランサーは、バックエンド ECS インスタンスとの TCP 3 ウェイハンドシェイクが完了するまで 5 秒間待機します。タイムアウトが発生した場合、次の ECS インスタンスが選択されます。これは、アクセスログの上流応答時間を確認することで特定できます。

• ロードバランサーが ECS インスタンスからの応答を待つ時間は、1～180 秒の範囲で設定可能です。タイムアウト後、通常は 504 または 408 ステータスコードがクライアントに返されます。アクセスログの上流応答時間を確認することで、問題の特定に役立ちます。

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

クライアントが早期に切断した場合の CLB の動作

ロードバランサーは、読み取りおよび書き込み操作中にバックエンドサーバーから切断しません。

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

CLB インスタンスは、永続的なバックエンド接続をサポートしていません。これを実現するには、ALB インスタンスを作成し、HTTP または HTTPS リスナーを設定し、対応する ALB サーバーグループで永続的なバックエンド接続を有効にします。詳細については、「サーバーグループの作成と管理」をご参照ください。

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

CLB インスタンス経由でサービスにアクセスする場合、バックエンドサーバーに直接アクセスする場合と比較して、わずかなレイテンシーの増加は正常です。CLB のレイヤー 7 リスナーはリバースプロキシアーキテクチャ (Tengine) を使用しており、リクエストは CLB を経由して転送されるため、1 つのネットワークホップとプロトコル処理の時間が追加されます。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：バックエンドサーバーの応答がタイムアウトしました。一般的な原因は、バックエンドでの処理時間が長いことや、バックエンドサーバーへの接続タイムアウトです。

ステップ 1：アクセスログの確認

まず、CLB アクセスログを有効にし、status (CLB がクライアントに返すステータスコード) と upstream_status (バックエンドサーバーが CLB に返すステータスコード) フィールドを確認することを推奨します：

• status と upstream_status が同じ場合、CLB はバックエンドサーバーからの異常なステータスコードをそのまま渡した可能性が高いです。バックエンドサーバーが返したステータスコードの原因を優先的にトラブルシューティングしてください。

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

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

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

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

• バックエンドサービスの問題：バックエンドサーバーの高負荷、異常な応答フォーマット、または不適切に閉じられた接続も 502 エラーの原因となることがあります。バックエンドサーバーのログと、CPU やメモリなどのリソース使用量を確認してください。

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

• トラフィックがインスタンスのスペック制限を超える：CLB への着信トラフィックの QPS、帯域幅、または新規接続数が現在のスペック制限を超えると、503 エラーが返されます。これらのメトリックは CloudMonitor から取得できます。

• 瞬間的なトラフィックが制限を超えているがモニタリングに表示されない：CloudMonitor は分単位の粒度でデータを表示するため、秒単位の制限超過が表示されない場合があります。アクセスログで秒単位のリクエスト数を確認してください。ログの 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 コンソールで、リスナーが作成されているかを確認し、リスナーのポートとプロトコルが正しく設定されていることを確認してください。リスナーがない、または設定が誤っていると、リクエストは転送されません。

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

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

5. バックエンドサービスステータスの確認：バックエンドサーバーに直接ログインし、telnet <backend_server_private_IP> <port> (レイヤー 4 の場合) または curl -I http://<backend_server_private_IP> (レイヤー 7 の場合) を使用して、バックエンドサービス自体が正しく応答していることを確認してください。

6. ネットワークパスのトラブルシューティング：異なるネットワーク環境から CLB サービスアドレスへのアクセスをテストしてください。問題がローカルネットワークに限定されている場合は、連続的な ping テストや MTR ルートトレースを使用してさらに調査できます。

IP アクセスは成功するがドメインアクセスが失敗する

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

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

問題をトラブルシューティングし、解決するために、以下の手順に従うことを推奨します：

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

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

3. 他の原因の除外：ドメインに有効な ICP 登録があり、転送が完了している場合は、ドメインの DNS レコードが CLB サービスアドレスに正しく向いていることを確認してください。これは nslookup または dig コマンドで確認できます。また、CLB リスナーのポートとプロトコルが、ドメインへのアクセス方法と一致していることを確認してください。

アクセス制御が内部ネットワークアクセスに与える影響

はい。アクセス制御はリスナーレベルで適用され、内部ネットワークとパブリックネットワークの両方のトラフィックに影響します。ホワイトリストが特定のパブリック IP アドレスのみを許可している場合、内部アクセスリクエストはブロックされます。内部サービスの混乱を避けるために、関連する内部ネットワークセグメントをホワイトリストに追加するか、Cloud Firewall を使用して EIP 上のパブリック向けトラフィックに特化して制限を適用することを推奨します。

セッション維持が失敗することがあるのはなぜですか？

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

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

  ソリューション：クライアントのソース IP アドレスに基づいてセッション維持を実行する TCP リスナーに切り替えます。さらに、バックエンド ECS インスタンスに Cookie を挿入し、追加の保証として Cookie 検証チェックを追加できます。

• 302 リダイレクトの問題：302 リダイレクトは、セッション維持で使用される SERVERID 文字列を変更します。

  ロードバランサーが Cookie を挿入する際、バックエンド ECS インスタンスが 302 リダイレクト応答を返すと、セッション維持 Cookie の SERVERID 文字列が変更され、セッション維持が失敗します。

  調査方法：ブラウザでリクエストとレスポンスをキャプチャするか、パケットスニッフィングツールを使用して 302 応答が存在するかどうかを分析します。前後の Cookie の SERVERID 文字列を比較して、変更されているかどうかを確認します。

  ソリューション：クライアントのソース IP アドレスに基づいてセッション維持を実行する TCP リスナーに切り替えます。さらに、バックエンド 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 コマンドを実行します。

   ロードバランサーのサービス 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

      説明

      Alibaba Cloud Load Balancer のデフォルトのセッション維持モードは 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' は表示される IP 情報をフィルタリングします。ご利用のバックエンド ECS インスタンスのプライベート IP に応じて調整してください。

   4. テスト出力の IP アドレスを観察します。それが同じ ECS プライベート IP であれば、セッション維持が有効であることが確認されます。そうでなければ、セッション維持は正しく機能していません。

HTTPS 経由でのスタイル読み込みの失敗

症状：

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

原因：

デフォルトでは、ロードバランサーは JS ファイルの読み込みや送信をブロックしません。考えられる原因は次のとおりです：

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

• 証明書が未承認のサードパーティプロバイダーからのものである。証明書の発行者に連絡して、証明書に問題がないか確認する必要があります。

ソリューション：

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

2. 対応する証明書をクライアントに追加します。

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

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

更新後の古い証明書情報

この問題は、ご利用の CLB インスタンスが透過型プロキシモードで Web Application Firewall (WAF) と統合されており、WAF 側の証明書が更新されていない場合に発生する可能性があります。WAF は定期的に CLB から証明書を同期します。即時更新を強制するには、WAF コンソールに移動し、保護対象ドメインのトラフィック転送を無効にしてから再度有効にすることができます。この操作により、WAF は証明書を強制的にリフレッシュします。この操作により、1～2 秒のサービス中断が発生する可能性があることに注意してください。

リスナーのバックエンド HTTP プロトコルバージョン

• クライアントのリクエストプロトコルが HTTP/1.1 または HTTP/2.0 の場合、レイヤー 7 リスナーは HTTP/1.1 を使用してバックエンドサーバーにアクセスします。

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

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

はい。

CLB は URL ベースのレート制限をサポートしていますか？

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

ALB は URL ベースのレート制限をサポートしています。リスナーの転送ルールを設定して、特定のパスに対して QPS 制限を設定できます。これには「転送先」アクションを使用する必要があります。以下の図をご参照ください：

CLB の WAF 保護の有効化

パブリックネットワークインターフェース無効化の影響

ECS インスタンスにパブリック IP アドレスがある場合、そのパブリックネットワークインターフェースを無効にすると、負荷分散サービスに影響します。

これは、パブリックネットワークインターフェースが存在する場合、デフォルトルートがパブリックネットワークを経由するためです。これを無効にすると、リターンパケットが妨げられ、負荷分散サービスに影響します。パブリックネットワークインターフェースを無効にしないことを推奨します。無効にする必要がある場合は、サービスの中断を避けるために、デフォルトルートをプライベートネットワークに変更する必要があります。ただし、パブリックネットワーク経由で RDS にアクセスするなど、ビジネスがパブリックネットワークに依存しているかどうかを考慮する必要があります。

TOA フィールドを持つリクエストのサポート

いいえ。クライアントリクエストの TCP Option Address (TOA) フィールドは、ロードバランサーが内部で使用する TOA フィールドと競合し、クライアントのリアル IP アドレスの取得を妨げます。