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

Classic Load Balancer (CLB) はポートリダイレクトをサポートしていますか？

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

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

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

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

CLB インスタンスのリッスンポートを設定する際に注意すべきことは何ですか？

一部の ISP は、25、135、139、444、445、5800、5900 などのポートを脆弱性のあるポートとしてマークし、デフォルトでブロックします。セキュリティグループルールでこれらのポートを許可しても、影響を受けるリージョンのユーザーはアクセスできません。したがって、サービスには他の脆弱性のないポートを使用する必要があります。

• Windows Server で使用されるポートの詳細については、Microsoft のドキュメント「Windows のサービスの概要とネットワーク ポートの要件」をご参照ください。

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

バックエンドサーバーに WebSocket または WebSocket Secure サービスがデプロイされている場合、リスナーはどのように設定すればよいですか？

• バックエンドサーバーに WebSocket サービスがデプロイされている場合は、TCP または HTTP リスナーを設定できます。

• バックエンドサーバーに WebSocket Secure サービスがデプロイされている場合は、TCP または HTTPS リスナーを設定できます。

CLB リスナーの設定変更はいつ、どのように有効になり、どのような影響がありますか？

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

URL 転送ルールを設定した後、特殊文字を含む URL にアクセスできないのはなぜですか？

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

CLB 転送ルールのバックエンドサーバーを管理するにはどうすればよいですか？

転送ルールページで、[vServer グループ] 列にあるターゲットサーバーグループの名前をクリックします。表示されたページで、バックエンドサーバーのポートや重みを追加、削除、または変更できます。

モニタリングデータでは帯域幅が仕様を超えていないのに、なぜトラフィックがドロップされるのですか？

この問題は通常、以下の理由によって発生します：

• Alibaba Cloud の帯域幅モニタリングデータは、1 分間の平均値に基づいて計算されます。瞬間的なトラフィックがインスタンスの帯域幅制限を超えると、トラフィックはドロップされます。モニタリングチャートは平均値を表示するため、これを示さない場合があります。1 分間の平均帯域幅が制限を超えない限り、チャートは帯域幅使用量が仕様の範囲内であることを示します。

• SLB システムは、クラスターデプロイで CLB インスタンスにサービスを提供します。すべての外部アクセスリクエストは、これらの SLB システムサーバーに均等に分散されて転送されます。指定された帯域幅上限は、複数のシステムサーバーに分散されます。クライアント接続によってダウンロードされるデータ量が単一サーバーのしきい値を超えると、トラフィックはドロップされます。単一接続の最大トラフィックの計算方法の詳細については、「一部のシナリオで接続が帯域幅上限に達しないのはなぜですか？」をご参照ください。

モニタリングデータに表示されるリスナートラフィックが、設定された速度制限よりも大きいのはなぜですか？

SLB システムは、クラスターデプロイで CLB インスタンスにサービスを提供し、分散型の速度制限を使用します。数式は 単一ノードの帯域幅上限 = SLB インスタンスの合計帯域幅 / (N - 1) です。ここで、N はクラスター内の子ノードの数です。したがって、全体的な速度制限は設定値よりわずかに高くなります。

一部のシナリオで接続が帯域幅上限に達しないのはなぜですか？

• シナリオ：帯域幅課金方式を使用するパブリック向け CLB インスタンスを使用する場合、単一クライアントからのストレステスト中や、特大データパケットの送信時など、一部のシナリオで接続が帯域幅上限に達しないことがあります。

• 仕組み：

  SLB システムは、クラスターデプロイで CLB インスタンスにサービスを提供します。すべての外部アクセスリクエストは、SLB システムサーバーに均等に分散されて転送されます。したがって、指定された帯域幅上限はこれらのシステムサーバーに分散されます。

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

• 推奨ソリューション：

  • パブリック向け CLB インスタンスにトラフィック課金方式を使用します。

  • EIP と Internet Shared Bandwidth インスタンスを備えた Network Load Balancer (NLB) または Application Load Balancer (ALB) インスタンスを使用します。このソリューションは、ロードバランサーインスタンスに十分な弾力性を提供し、この制限はありません。

一部のシナリオで CLB インスタンスが QPS 上限に達しないのはなぜですか？

• シナリオ：少数の持続的接続を使用するビジネスシナリオでは、転送グループ内のシステムサーバーすべてに持続的接続が割り当てられない場合があります。これにより、CLB インスタンスが秒間クエリ数 (QPS) の上限に達しない可能性があります。

• 原因：

  SLB システムは、ロードバランサーインスタンスにクラスターデプロイでサービスを提供します。すべての外部アクセスリクエストは、SLB システムサーバーに均等に分散されて転送されます。したがって、CLB インスタンスの QPS 上限はこれらのシステムサーバーに分散されます。

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

  説明

• ソリューション：

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

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

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

  • Application Load Balancer (ALB) インスタンスを使用します。このソリューションは、ロードバランサーインスタンスに十分な弾力性を提供します。

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

• シナリオ：スペック保証型課金方式を使用する Classic Load Balancer (CLB) インスタンスを使用する場合、単一クライアントまたは単一アクセス元からのストレステストなど、一部のシナリオで秒間新規接続数 (CPS) が指定されたレベルに達しないことがあります。

  説明

• 原因：

  SLB システムは、高可用性と拡張性を確保するためにクラスターデプロイアーキテクチャを使用します。外部アクセスリクエストのすべての接続操作は、クラスター内の複数のシステムサーバーに均等に分散されて処理されます。したがって、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 です。

• ソリューション：

  • CLB インスタンスの課金方法を変更する：CLB インスタンスの課金方法をスペック保証型から、より柔軟な従量課金に変更します。従量課金の 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 秒。

SLB エンドポイントへの接続がタイムアウトするのはなぜですか？

サーバー側の観点から、以下の問題がエンドポイントへの接続タイムアウトを引き起こす可能性があります：

• エンドポイントのセキュリティ保護

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

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

  これは特にストレステスト中によく見られます。クライアントポートが不足すると、接続障害が発生する可能性があります。デフォルトでは、SLB は 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 SLB インスタンスのバックエンドサーバーの 1 つからそのエンドポイントにアクセスする

  CLB のレイヤー 4 (TCP/UDP) リスナーの場合、バックエンドサーバーはクライアントとサーバーの両方として機能することはできません。バックエンドサーバーの 1 つから CLB インスタンスのエンドポイントにアクセスすると、接続障害が発生します。一般的なシナリオは、バックエンドアプリケーションが URL 連結を使用して CLB エンドポイントにアクセスする場合です。

  ソリューション：

  • レイヤー 4 SLB インスタンスのバックエンドサーバーの代わりに、別のクライアントを使用します。

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

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

  SLB が TCP 接続を確立した後、900 秒間アクティビティがない場合、接続を閉じるためにクライアントとサーバーの両方に RST パケットを送信します。一部のアプリケーションは RST 例外を適切に処理せず、閉じた接続を介してデータを送信する可能性があり、アプリケーションがタイムアウトする原因となります。

  説明

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

HTTP および HTTPS 接続のタイムアウトルールは何ですか？

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

• 持続的接続を介した 2 つの HTTP または HTTPS リクエスト間のタイムアウト期間は 1～60 秒で設定可能で、1～2 秒の誤差があります。タイムアウト期間を超えると、TCP 接続は閉じられます。持続的接続を使用するには、13 秒未満の間隔でハートビートリクエストを送信する必要があります。

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

• SLB が ECS インスタンスからの応答を待機するタイムアウト期間は 1～180 秒で設定可能です。タイムアウトが発生した場合、SLB は通常、クライアントに 504 または 408 ステータスコードを返します。アクセスログでアップストリームの応答時間を確認して、問題の特定に役立てることができます。

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

クライアントがバックエンドサーバーからの応答を受け取る前に能動的に切断した場合、SLB もバックエンドサーバーから切断しますか？

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

Classic Load Balancer (CLB) インスタンスのバックエンド持続的接続を有効にするにはどうすればよいですか？

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

CLB を介してバックエンドサービスにアクセスする際の高遅延をトラブルシューティングするにはどうすればよいですか？

CLB を介してバックエンドサービスにアクセスする場合、直接アクセスと比較して遅延がわずかに増加することは想定内です。CLB のレイヤー 7 リスナーはリバースプロキシアーキテクチャ (Tengine) を使用します。リクエストは CLB によって転送されるため、1 つのネットワークホップとプロトコル処理の遅延が追加されます。レイヤー 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) を使用して、クロスリージョンアクセスのエクスペリエンスを最適化します。

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

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

• 502 Bad Gateway：CLB がリクエストをバックエンドサーバーに転送できないか、バックエンドサーバーから応答を取得できません。一般的な原因には、到達不能なバックエンドサービスや、すべてのヘルスチェックの失敗が含まれます。

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

• 504 Gateway Time-out：バックエンドサーバーがタイムアウトしました。一般的な原因には、バックエンドサーバーでの処理時間が長いことや、バックエンドサーバーとの接続タイムアウトが含まれます。

ステップ 1：アクセスログの表示

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

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

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

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

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

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

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

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

• トラフィックがインスタンス仕様の制限を超える：CLB にアクセスするトラフィックの QPS、帯域幅、または新規接続数が現在の仕様制限を超えると、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 コンソールで、リスナーが作成されているかどうかを確認し、リッスンポートとプロトコルが正しく設定されていることを確認します。リスナーが追加されていないか、リッスンポートが誤って設定されている場合、リクエストは転送できません。

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

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

5. バックエンドサービスが正常に実行されているか確認する：バックエンドサーバーにログインし、telnet <private_IP_of_backend_server> <port> (レイヤー 4 の場合) または curl -I http://<private_IP_of_backend_server> (レイヤー 7 の場合) を実行して、バックエンドサービスが正常に応答できることを確認します。

6. ネットワークリンクを確認する：異なるネットワーク環境から CLB エンドポイントへのアクセスをテストします。オンプレミスネットワークのみに問題がある場合は、継続的な ping テストまたは MTR ルートトレースを実行して、さらにトラブルシューティングを行うことができます。

CLB インスタンスに IP アドレスでアクセスできるのに、ドメイン名でアクセスできない場合はどうすればよいですか？

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

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

次のように問題をトラブルシューティングして対処します：

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

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

3. 他の原因を排除する：ドメイン名が ICP 登録を完了し、ICP 登録情報に Alibaba Cloud を追加している場合は、ドメイン名の名前解決が CLB エンドポイントに正しく向いているかを確認します。これは nslookup または dig コマンドで確認できます。また、CLB リスナーのポートとプロトコルの設定がドメイン名アクセス方法と一致しているかどうかも確認します。

EIP にバインドされたプライベート向け CLB インスタンスのアクセス制御を設定すると、内部ネットワークアクセスに影響しますか？

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

CLB インスタンスでのストレステスト中にリクエストタイムアウトをトラブルシューティングするにはどうすればよいですか？

レイヤー 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 ファイルに書き込みます。

バックエンドデータベースの障害により、同じリスナー配下のすべてのサイトにアクセスできなくなる状況にどう対処すればよいですか？

シナリオ：CLB リスナーの下に複数のサイトがマウントされています。たとえば、静的 Web サイト www.example.com と動的 Web サイト app.example.com です。動的 Web サイトのバックエンドデータベースに障害が発生すると、静的 Web サイトもアクセス不能になり、HTTP 502 エラーを報告します。

原因：2 つの Web サイトは同じリスナーを共有しています。リスナーの ヘルスチェックドメイン名 は、動的 Web サイトのドメイン名として設定されています。動的 Web サイトのバックエンドに障害が発生すると、すべてのバックエンドサーバーがヘルスチェックに失敗します。CLB はバックエンドサーバーへのトラフィック転送を停止し、最終的にリスナー配下のすべてのサイトへのアクセスに影響を与えます。

ソリューション：動的 Web サイトと静的 Web サイトに異なる CLB インスタンスを使用してサービスを分離します。これにより、動的 Web サイトの障害が静的 Web サイトへのアクセスに影響を与えなくなります。

セッション維持が時々失敗するのはなぜですか？

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

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

  ソリューション：TCP リスナーを使用します。TCP リスナーは、セッション維持にクライアントの送信元 IP アドレスを使用します。また、バックエンドの ECS インスタンスに Cookie を挿入し、追加の保証として Cookie チェックを追加することもできます。

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

  SLB が Cookie を挿入する際、バックエンドの ECS インスタンスが 302 リダイレクトメッセージで応答すると、セッション維持 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 を実行してサイトにアクセスすることもできます。

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

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

   SLB インスタンスのすべてのバックエンド ECS インスタンスで、ローカルマシンのプライベート IP アドレスを表示するテストページを作成します。プライベート IP アドレスは、リクエストがどの物理サーバーに割り当てられたかを判断するために使用されます。この IP アドレスの一貫性を観察することで、SLB セッション維持の有効性を判断できます。

   

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

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

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

   2. 次のコマンドを実行して、SLB サーバーの Cookie 値をクエリします。

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

      説明

      Alibaba Cloud SLB のデフォルトのセッション維持モードは Cookie 挿入です。`curl` コマンドはデフォルトでは Cookie を保存も送信もしません。テストにはまず対応する Cookie を保存する必要があります。そうしないと、`curl` のテスト結果はランダムになり、SLB のセッション維持が機能していないと誤って結論付けてしまう可能性があります。

   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.X.X' の部分は表示される IP 情報をフィルタリングします。バックエンド ECS インスタンスのプライベート IP アドレスに基づいて変更してください。

   4. テストによって返された IP アドレスを観察します。それが ECS インスタンスの同じプライベート IP アドレスであれば、SLB のセッション維持は機能しています。そうでなければ、SLB のセッション維持に問題があります。

Cookie の上書き モードを使用する場合、バックエンドサーバーで Cookie をどのように設定すればよいですか？

CLB のレイヤー 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、メモリ、その他のリソース使用量の違いにより、一部のサーバーの負荷が高くなることがあります。各バックエンドサーバーにログインし、アプリケーションのリソース使用量を比較して、パフォーマンスボトルネックがないか確認します。

なぜ Web サイトは HTTP リスナーでは正常に読み込まれるのに、HTTPS リスナーではスタイルが読み込まれないのですか？

症状：

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

原因：

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

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

• 証明書が非公式のサードパーティプロバイダーからのものである。証明書の発行元に連絡して、証明書に問題がないか確認してください。

ソリューション：

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

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

CLB インスタンスで HTTP から HTTPS へのリダイレクトを設定した後、バックエンドサーバーにも証明書を設定する必要がありますか？

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

CLB インスタンスで証明書を更新した後、なぜブラウザには古い有効期限が表示されるのですか？

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

CLB は HSTS をサポートしていますか？

CLB は HSTS 応答ヘッダーの設定をサポートしていません。HSTS を有効にするには、以下のいずれかの方法を使用できます：

• バックエンドサーバー側で Strict-Transport-Security 応答ヘッダーを自分で追加します。

• WAF に接続し、WAF を介して HSTS を有効にします。

HTTP または HTTPS リスナーは、バックエンドサーバーへのアクセスにどの HTTP プロトコルバージョンを使用しますか？

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

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

バックエンドサーバーは、HTTP または HTTPS リスナーへのクライアントリクエストのプロトコルバージョンを取得できますか？

はい、できます。

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

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

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

なぜレイヤー 7 CLB インスタンスの HTTP リクエストヘッダーに `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 で `proxy_buffering` と `proxy_cache` は有効になっていますか？

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

CLB の WAF 保護を有効にするための手順

パブリック NIC を無効にすると SLB サービスに影響しますか？

ECS インスタンスにパブリック IP アドレスがある場合、パブリックネットワークインターフェースコントローラー (NIC) を無効にすると SLB サービスに影響します。

これは、パブリック NIC が存在する場合、デフォルトルートがパブリックネットワークを経由するためです。パブリック NIC を無効にすると、応答パケットが返送されなくなり、SLB サービスに影響します。パブリック NIC は無効にしないでください。無効にする必要がある場合は、サービスに影響を与えないようにデフォルトルートをプライベートネットワークに変更する必要があります。ただし、パブリックネットワーク経由で RDS にアクセスするなど、サービスがパブリックネットワークに依存しているかどうかを考慮する必要があります。

SLB は TOA フィールドを含むクライアントリクエストをサポートしていますか？

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