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

CLB はポートリダイレクトをサポートしていますか？

はい。

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

CLB のレイヤー 4 リスナーはポート範囲をサポートしていますか？

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

リスナーポート構成時の注意事項

一部の通信事業者は、ポート 25、135、139、444、445、5800、および 5900 を高リスクポートとして分類し、デフォルトでブロックしています。これらのポートに対するトラフィックをセキュリティグループルールで許可した場合でも、制限対象地域のユーザーはサービスにアクセスできません。サービスには、これらの高リスクポート以外のポートを使用することを推奨します。

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

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

WebSocket 用リスナーの構成

• バックエンドサーバーが WebSocket を使用している場合は、TCP リスナーまたは HTTP リスナーを構成できます。

• バックエンドサーバーが WebSocket Secure を使用している場合は、TCP リスナーまたは HTTPS リスナーを構成できます。

リスナー構成変更の影響と効果

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

特殊文字を含む URL へのアクセス

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

利用可能な帯域幅があるにもかかわらずパケットがドロップされる

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

• Alibaba Cloud の帯域幅モニタリングデータは 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 インスタンスにトラフィック課金の課金方法を使用します。

  • Elastic IP アドレス (EIP) と EIP 帯域幅プランを備えた Application Load Balancer (ALB) または Network Load Balancer (NLB) インスタンスを使用します。このソリューションにより、十分なスケーラビリティが確保され、この制限が解消されます。

最大 QPS に到達しない

• シナリオ：持続的接続数が少ないシナリオでは、転送グループ内のすべてのサーバーがそれらの接続を処理するために割り当てられない場合があります。その結果、CLB インスタンスは最大 QPS に到達できません。

• 原因：

  CLB はサーバークラスターを使用してサービスを提供します。すべての外部リクエストは、これらのサーバーに分散されて転送されます。したがって、CLB インスタンスの最大 QPS はクラスター内のサーバー間で共有されます。

  単一バックエンドサーバーの最大 QPS は、次の数式で計算されます：単一バックエンドサーバーの最大 QPS = インスタンスの合計 QPS / (N - 1)。N はサーバーグループ内のバックエンドサーバー数です。たとえば、slb.s1.small スペックの CLB インスタンスは合計 1,000 QPS を提供します。サーバーグループに 8 台のバックエンドサーバーが含まれている場合、単一バックエンドサーバーの最大 QPS は 1,000 / (8 - 1) = 142 QPS となります。

  説明

• 推奨事項：

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

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

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

  • ALB インスタンスを使用します。このソリューションにより、十分なスケーラビリティが確保されます。

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

• シナリオ： CLB インスタンスを購入し、従量課金 (スペックベース) の課金方法を選択した場合、特定のシナリオ（単一クライアントでのストレステストや単一ソースからのトラフィックなど）において、新規接続レート (CPS) がスペックに記載されたレベルに到達しないことがあります。

  説明

• 原因：

  CLB は高可用性とスケーラビリティを確保するためにクラスターデプロイアーキテクチャを使用しています。着信接続リクエストはクラスター内の複数のサーバーに分散されます。したがって、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 インスタンスではスペックを指定する必要がなく、ほとんどのスペックベースインスタンスよりも高いパフォーマンス制限を提供するため、パフォーマンスボトルネックを回避できます。

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

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

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

• HTTP リスナー：

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

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

• HTTPS リスナー：

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

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

CLB サービスアドレスへの接続タイムアウト

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

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

  これには、トラフィックブラックホール化、スクラビング、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 リスナー (TCP/UDP) では、バックエンドサーバーがロードバランサー経由で自身のサービスアドレスにアクセスすることはできません。この構成により、接続が失敗します。一般的なシナリオは、バックエンドアプリケーションが URL を構築して CLB のサービスアドレスにリダイレクトする場合です。

  解決策：

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

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

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

  TCP 接続が 900 秒間アイドル状態になると、ロードバランサーがクライアントとサーバーの両方に RST パケットを送信して接続を閉じます。一部のアプリケーションはこれらの RST パケットを不適切に処理し、閉じられた接続上でデータを送信しようとするため、アプリケーションタイムアウトが発生する可能性があります。

  説明

  900 秒はシステムのデフォルト値であり、必要に応じて調整できます。

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

• 持続的 HTTP 接続では、最大 100 個の連続リクエストを送信できます。この制限を超えると、接続は閉じられます。

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

• ロードバランサーとバックエンド ECS インスタンス間の TCP 3 ウェイハンドシェイクのタイムアウトは 5 秒です。ハンドシェイクがタイムアウトすると、CLB は次の ECS インスタンスを選択します。この現象は、アクセスログのアップストリーム応答時間を確認することで識別できます。

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

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

クライアント切断時のバックエンド接続動作

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

バックエンドサーバーへの持続的接続の有効化

クラシックロードバランサー (CLB) は、バックエンドサーバーへの持続的接続をサポートしていません。この機能を使用するには、Application Load Balancer (ALB) インスタンスを作成し、HTTP または HTTPS リスナーを構成して、対応する ALB サーバーグループで持続的接続を有効にしてください。詳細については、「サーバーグループの作成と管理」をご参照ください。

CLB の高遅延のトラブルシューティング

CLB 経由でサービスにアクセスすると、バックエンドサーバーに直接アクセスする場合よりもわずかに遅延が増加しますが、これは想定内の動作です。レイヤー 7 CLB リスナーはリバースプロキシアーキテクチャ (Tengine) を使用しており、リクエストは CLB によって転送されます。これにより、追加のネットワークホップとプロトコル処理による遅延が発生します。レイヤー 4 リスナーは LVS を使用して転送を行うため、追加遅延は通常最小限です。

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

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 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 システムアドレス範囲) からのトラフィックを許可していないセキュリティグループ、ヘルスチェックステータスコードの構成ミスマッチ、存在しないヘルスチェックパスなど）をトラブルシューティングしてください。「CLB ヘルスチェックに関するよくある質問」をご参照ください。

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

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

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

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

• 瞬間的なトラフィックが制限を超えているが、モニタリングに表示されていない：CloudMonitor は 1 分単位の粒度でデータを表示するため、1 秒以内に制限を超えるトラフィックバーストを反映できない場合があります。アクセスログ内の 1 秒あたりのリクエスト数を確認してください。ログ内の upstream_status が "-" の場合、リクエストがバックエンドサーバーに送信されていないことを示しています。

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

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

• バックエンド接続タイムアウト：CLB インスタンスとバックエンド ECS インスタンス間の TCP 3 ウェイハンドシェイクのタイムアウトは 5 秒です。アクセスログ内の upstream_response_time が長すぎる場合、バックエンドサーバーとの接続エラーを示している可能性があります。パケットキャプチャを実行して原因を調査してください。

• バックエンドの高負荷：バックエンドサーバーの CPU やメモリなどのリソース使用率が高いと、応答時間がタイムアウト期間を超える可能性があります。バックエンドサービスのパフォーマンスをトラブルシューティングして最適化するか、バックエンドサーバーを追加して負荷を分散させてください。

サービスアクセス障害のトラブルシューティング

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

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

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

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

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

5. バックエンドサービスが正常に動作していることを確認する：バックエンドサーバーに直接ログインし、レイヤー 4 の場合は telnet <バックエンドサーバーのプライベート IP アドレス> <ポート> コマンドを、レイヤー 7 の場合は curl -I http://<バックエンドサーバーのプライベート IP アドレス> コマンドを実行して、バックエンドサービスが正常に応答できることを確認します。

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

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

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

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

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

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

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

3. その他の原因を除外する：ドメインの ICP 登録およびアクセス登録が完了している場合は、ドメインが CLB サービスアドレスに正しく解決されていることを確認してください (nslookup コマンドまたは dig コマンドを使用して確認できます)。また、CLB リスナーのポートおよびプロトコル構成がドメインアクセス方法と一致していることを確認してください。

プライベートネットワークへのアクセス制御の影響

はい。アクセス制御はリスナーレベルで適用され、プライベートネットワークおよびパブリックネットワークの両方に影響します。許可リストに特定のパブリック IP アドレスのみを許可している場合、リストに含まれていない内部 IP アドレスからのリクエストはブロックされます。内部サービスへの影響を回避するには、関連する内部ネットワークセグメントを許可リストに追加するか、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 エラーを返します。

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

解決策：動的および静的 Web サイトに個別の CLB インスタンスを使用してサービスを分離します。これにより、動的 Web サイトの障害が静的 Web サイトへのアクセスに影響を与えないようにします。

セッション維持が失敗する原因

• セッション維持が有効になっていない：リスナー構成でセッション維持が有効になっているかどうかを確認します。

• HTTP/HTTPS リスナーの問題：バックエンドサーバーが 4xx ステータスコードを返す場合、HTTP または HTTPS リスナーは応答にセッション維持クッキーを挿入しません。

  解決策：クライアントの送信元 IP アドレスを使用してセッション維持を行う TCP リスナーに切り替えます。また、バックエンド ECS インスタンスにクッキーを挿入し、追加の保証としてクッキーチェックを追加することもできます。

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

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

  トラブルシューティング：ブラウザでリクエストと応答をキャプチャするか、パケットキャプチャツールを使用して 302 応答が存在するかどうかを分析します。前後のクッキー内の SERVERID 文字列を比較して、異なるかどうかを確認します。

  解決策：クライアントの送信元 IP アドレスを使用してセッション維持を行う TCP リスナーに切り替えます。また、バックエンド ECS インスタンスにクッキーを挿入し、追加の保証としてクッキーチェックを追加することもできます。

• セッション維持タイムアウトが短すぎる：セッション維持タイムアウトが小さい値に設定されている場合、セッション維持が失敗する可能性があります。

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

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

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

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

   各バックエンド ECS インスタンスに、インスタンスのプライベート IP アドレスを表示するテストページを作成します。この IP はリクエストを処理するサーバーを識別し、一貫した IP を確認することでセッション維持の有効性を検証できます。

   

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

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

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

   2. CLB が挿入するクッキー値を照会するコマンドを実行します。

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

      説明

      Alibaba Cloud のセッション維持のデフォルトモードはクッキー挿入です。ただし、curl テストはデフォルトでクッキーを保存または送信しません。したがって、テストのためにまずクッキーを保存する必要があります。保存しない場合、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 アドレスに基づいて IP アドレスを変更してください。

   4. テストで返された IP アドレスを観察します。常に同じバックエンド ECS インスタンスのプライベート IP アドレスが返される場合は、セッション維持が有効です。そうでない場合は、セッション維持に問題がある可能性があります。

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

CLB のレイヤー 7 セッション維持で 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;
    }
}

HTTPS リスナーでのスタイル読み込みの問題

症状：

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

原因：

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

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

• 証明書が認証されていないサードパーティ発行者によるものである。証明書の発行者に連絡して問題を確認する必要があります。

解決策：

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

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

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

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

証明書更新後にブラウザに古い証明書が表示される

この状況は通常、CLB が透過型プロキシモードで WAF 2.0 に接続されており、WAF 側の証明書が更新されていないために発生します。WAF は CLB から証明書を定期的に同期します。即時同期を強制するには、WAF 側でトラフィックリダイレクトを一度無効にしてから再度有効にします。この操作により、証明書ステータスが強制的にリフレッシュされます。ただし、この操作により 1 ～ 2 秒間のサービス中断が発生することにご注意ください。

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

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

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

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

はい。

URL ベースのレート制限のサポート

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

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

Transfer-Encoding: chunked ヘッダー

Transfer-Encoding: chunked は HTTP プロトコルの標準フィールドで、メッセージ本文がチャンク単位で転送されることを示します。レイヤー 7 CLB は Tengine リバースプロキシに基づいて実装されており、バックエンドサーバーへのリクエスト転送時にチャンク転送エンコーディングを使用します。したがって、バックエンドサーバーはリクエストヘッダーにこのフィールドを確認できます。これはリバースプロキシの通常の動作であり、サービスに影響しません。レイヤー 4 CLB はトラフィックを転送するのみのため、このフィールドは表示されません。

レイヤー 7 CLB によって削除されるバックエンド応答ヘッダー

セッション維持を実装するために、CLB は応答ヘッダーから Date、Server、X-Pad、および X-Accel-Redirect などのフィールドを削除します。これらのフィールドを保持する必要がある場合は、カスタム応答ヘッダーにプレフィックス (例：xl-server) を追加するか、レイヤー 4 TCP リスナーを使用してください。

CLB での WAF 保護の使用

パブリック NIC の無効化の影響

ECS インスタンスにパブリック IP アドレスがある場合、パブリックネットワークインターフェイスコントローラー (NIC) を無効にすると、負荷分散サービスが中断されます。

これは、パブリック NIC が存在する場合、デフォルトルートがパブリックネットワーク経由になるためです。これを無効にすると、応答パケットが送信されなくなり、負荷分散サービスに影響します。パブリック NIC を無効にしないことを推奨します。無効にする必要がある場合は、サービス中断を回避するためにデフォルトルートをプライベートネットワーク経由に変更する必要があります。ただし、RDS インスタンスへのアクセスなど、ビジネスがパブリックネットワークに依存しているかどうかを事前に検討してください。

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

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