Server Load Balancer:ALB のよくある質問

ALB インスタンスの仕様

ALB では、インスタンス仕様を選択する必要はありません。ALB インスタンスをアップグレードすると、ALB は VIP 自動スケーリング機能を使用して、単一インスタンスで 100 万 QPS を達成します。インスタンスのパフォーマンスの詳細については、「インスタンスメトリック」をご参照ください。

IPv4 インスタンスとデュアルスタックインスタンスの変換

いいえ。

新しい IPv4 インスタンスまたは新しいデュアルスタックインスタンスを作成することのみ可能です。

ALB VIP への ping の無効化

• アップグレード済みの ALB インスタンスの場合、セキュリティグループを使用してアクセス トラフィックを管理できます。インスタンスのセキュリティグループでインバウンドルールを設定して、ICMP リクエストを拒否できます。

• アップグレードされていない ALB インスタンスの場合、インスタンスに関連付けられている Elastic IP Address (EIP) を Cloud Firewall に追加し、インバウンドポリシーを設定して ICMP リクエストを拒否できます。

ALB のパブリック帯域幅の増加

共有帯域幅インスタンスに追加されていない場合、2 つのアベイラビリティゾーンにまたがってデプロイされた単一の ALB インスタンスのデフォルトのピークパブリック帯域幅は 400 Mbps です。

ALB での Data Transfer Plan の使用

• ALB インスタンスが EIP を介してパブリックサービスを提供する場合、Data Transfer Plan を使用して EIP によって生成されたパブリックデータ転送コストを相殺できます。

• ALB インスタンスが Anycast Elastic IP Address (Anycast EIP) を介してパブリックサービスを提供する場合、Data Transfer Plan を使用して Anycast EIP によって生成されたパブリックデータ転送コストを相殺することはできません。

サポートされる EIP タイプ

プライベート ALB インスタンス用の EIP

はい。

プライベート向け ALB に EIP を関連付ける必要がある場合は、インスタンスのネットワークタイプを変更することで、プライベート向け ALB をパブリック向け ALB に変換できます。詳細については、「ALB インスタンスのネットワークタイプの変更」をご参照ください。

ネットワークタイプをプライベートからパブリックに変更すると、インスタンスに EIP が関連付けられ、結果として生じるインターネットデータ転送に対して料金が発生します。詳細については、「EIP の課金」をご参照ください。

EIP を BGP (マルチ ISP) Pro EIP に置き換える

ALB インスタンスのネットワークタイプを変更して EIP を置き換えます：

1. ALB インスタンスのネットワークタイプをパブリックからプライベートに変更して、EIP の関連付けを解除します。

2. ALB インスタンスのネットワークタイプをプライベートからパブリックに戻します。このプロセス中に、すでに作成済みの 2 つの BGP (マルチ ISP) Pro EIP を選択します。

EIP 間のトラフィック分散の不均衡

この問題には、次の原因が考えられます。

• サービスドメイン名が、ALB インスタンスの DNS 名ではなく、インスタンスに関連付けられた単一の EIP に誤って解決されている。

• Web Application Firewall (WAF) や Anti-DDoS などのレイヤー 7 プロキシが ALB インスタンスの前にデプロイされている。プロキシのオリジンサーバーへのアクセスアルゴリズム (IP ハッシュなど) により、トラフィックが EIP 間で均等に分散されない。

• 一部のクライアントが DNS 名前解決からの A レコードをキャッシュし、多数のリクエストが常に同じ EIP に送信される。

ALB の DNS 削除

アップグレード済みの ALB インスタンスは、デフォルトで DNS の削除と回復操作をサポートしています。

DNS の削除が完了すると、そのアベイラビリティゾーンの VIP のヘルスチェックが停止します。そのアベイラビリティゾーンの VIP または EIP (IPv4 と IPv6 アドレスの両方を含む) も ALB ドメイン名の名前解決から削除されます。IPv4 または IPv6 の VIP アドレスのみを削除することはできません。

バックエンド ECS インスタンスでの高いパブリックトラフィック

ALB インスタンスからバックエンドの Elastic Compute Service (ECS) インスタンスに転送されるトラフィックは、Virtual Private Cloud (VPC) の内部ネットワークを通過するため、ECS インスタンスのパブリック帯域幅を消費しません。ECS インスタンスのパブリックトラフィックが高いままである場合、通常は次のいずれかの理由によります。

• インバウンドトラフィックが ALB インスタンスをバイパスしている：ドメイン名がまだ ECS のパブリック IP に解決されているか、クライアントがパブリック IP を介して直接 ECS インスタンスにアクセスしている。その結果、ALB インスタンスはトラフィックを転送していません。

• ECS インスタンスからのアウトバウンドリクエスト：ECS インスタンスで実行されているアプリケーションが、ソフトウェアの更新、ログのアップロード、外部 API の呼び出しなどの外部リクエストを開始し、アウトバウンドのパブリックトラフィックを生成しています。

トラブルシューティング手順：

1. サービスドメイン名が ECS のパブリック IP アドレスではなく、ALB のアドレスに解決されていることを確認します。

2. ECS インスタンスのセキュリティグループのインバウンドルールをチェックして、サービスポートがパブリックに公開されていないことを確認します。

3. ECS インスタンスで、iftop または nethogs を使用して、パブリック帯域幅を消費しているプロセスと宛先アドレスを特定します。

ALB を使用する際に、サードパーティプラットフォームの IP 許可リストに追加すべき IP アドレスはどれですか？

インターネット向けの ALB インスタンスを使用する場合、サードパーティプラットフォーム (WeChat Merchant Platform や支払いコールバックなど) は、バックエンドの Elastic Compute Service (ECS) インスタンスの IP アドレスではなく、ALB インスタンスの EIP をバインドする必要があります。

インターネット向けの ALB インスタンスは、その EIP を介してサービスを提供します。サードパーティプラットフォームからのコールバックリクエストを含むすべての外部トラフィックは、ALB インスタンスの EIP を介して入り、その後 ALB によってバックエンドサーバーに転送されます。バックエンドの ECS インスタンスは Virtual Private Cloud (VPC) 内のプライベート IP アドレスを使用しており、外部の呼び出し元には公開されません。複数のバックエンド ECS インスタンスがある場合でも、サードパーティプラットフォーム上で ALB インスタンスの EIP をバインドするだけで済みます。

インターネット向けの ALB インスタンスのトラフィックパスは次のとおりです：クライアントリクエスト > ALB EIP (パブリックエントリポイント) > ALB による内部転送 > バックエンド ECS インスタンスのプライベート IP アドレス。サードパーティプラットフォームからのコールバックリクエストがインターネットから入ると、ALB インスタンスの EIP にのみ到達し、ALB はそれをバックエンドの ECS インスタンスに転送します。プロセス全体を通じて、サードパーティプラットフォームは ALB インスタンスの EIP とのみ通信し、バックエンド ECS インスタンスのプライベート IP アドレスは外部の呼び出し元には見えません。

ALB はトラフィックミラーリングをサポートしていますか？

はい。詳細については、「ALB トラフィックミラーリングを使用したストレステスト」をご参照ください。

リスナーの QPS 上限に到達しない問題

• 仕組み：負荷分散システムは、各 ALB インスタンスにサービスを提供するためにサーバークラスターを使用します。このクラスターは、インバウンドリクエストをそのサーバー間で均等に分散して転送します。したがって、転送ルールで設定した QPS 上限も、これらのシステムサーバーに分散されます。

  単一のシステムサーバーの QPS 上限は、次の数式を使用して計算されます：システムサーバーあたりの QPS 上限 = 設定された合計 QPS / (N-1)。N は転送グループ内のシステムサーバーの数です。たとえば、コンソールで転送ルールの QPS 上限を 1,000 QPS に設定し、システムサーバーが 8 台ある場合、単一のシステムサーバーの最大 QPS は 1000/(8-1) = 142 QPS となります。

• 原因：持続的接続の数が少ない場合、転送グループ内の一部のシステムサーバーが接続を受信しないことがあります。これにより、ALB インスタンスが QPS 上限に到達できなくなる可能性があります。

• 推奨事項：ビジネス要件に基づいて、転送ルールに適切な QPS 上限を設定してください。これにより、サービスが利用可能な状態を維持し、予期せず制限されることがなくなります。リスナーの転送ルールで QPS 上限を設定する方法の詳細については、「転送ルールの追加」をご参照ください。

リクエスト長の制限

ALB 処理時間の範囲

はい、ALB の処理時間には、クライアントからのデータ受信時間とクライアントへのデータ送信時間が含まれます。

• クライアントデータの受信時間：これは read_request_time で、ロードバランサーがクライアントリクエストを読み取るのにかかる合計時間です。これには、HTTP リクエストヘッダー (read_header_time) とリクエストボディ (read_body_time) の読み取り時間が含まれます。

• レスポンスデータの送信時間：これには、クライアントにレスポンスデータを返す時間が含まれます。

持続的接続あたりの最大リクエスト数

単一の持続的接続は、最大 100 件の連続したリクエストをサポートします。この制限を超えると、接続は自動的に閉じられます。

HTTPS リスナーを使用し、HTTP/2 を有効にすると、この制限は 1,000 に増加します。

QUIC リスナーにおける Client Hello の長さ制限

QUIC リスナーを使用する場合、ALB はクライアントの Client Hello の最小長を強制します。パケットは少なくとも 1,024 バイト長である必要があります。そうでない場合、ALB は「client hello too small」エラーを返し、接続を閉じます。このチェックをパスするには、Client Hello パケットにヌル文字を埋め込んで 1,024 バイトの要件を満たすようにしてください。

ALB Ingress の考慮事項

ほとんどの場合、コンソールで ALB Ingress によって作成された ALB インスタンスを手動で変更しないでください。ALB 設定の信頼できる情報源として AlbConfig を使用してください。ALB Ingress の詳細については、「ALB Ingress の概要」および「ALB Ingress の使用」をご参照ください。

コンソールで手動で変更を行うと、その変更は AlbConfig リソースに反映されません。次の AlbConfig 同期時に、これらの手動変更は上書きされます。これにより、アクセスログが無効になったり、転送ルールが削除されたりするなどの問題が発生する可能性があります。

セッション維持が無効な場合、同じクライアントからの複数のリクエストは同じバックエンドサーバーに転送されますか？

転送される可能性はありますが、ALB はそれを保証しません。セッション維持が無効な場合、ALB はクライアントとバックエンドサーバー間のマッピングを記録しません。代わりに、各リクエストを独立したリクエストとして扱い、サーバーグループに設定されたスケジューリングアルゴリズムに基づいてバックエンドサーバーを選択します。同じクライアントからのリクエストが常に同じバックエンドサーバーに転送されるようにするには、サーバーグループのセッション維持を有効にしてください。

ALB のクロスオリジンに関するよくある質問

元のヘッダー値の参照

キー に、書き込みたいヘッダーの名前を入力します。値 で、参照方法を選択し、値を参照したい元のヘッダーの名前を入力します。次の例では、abc-abc という名前の新しいヘッダーが書き込まれ、元のヘッダー abc の値を参照します。転送ルールは、元のヘッダー abc から値を抽出し、新しいヘッダー abc-abc に割り当てます。

この転送ルールの条件は、/ の完全なパス一致です。ヘッダー書き込みアクションに加えて、ルールは特定のサーバーグループに重み 100 で 転送するようにも設定されています。

クライアント

クライアントが curl を使用してリクエストを送信する際、-H パラメーターでカスタムリクエストヘッダー abc:123456 を含めます。サーバーは 200 OK を返します。次のコードは、サンプルコマンドとその出力を示しています。

curl http://xxx.xxx.174 -v -k -H abc:123456
*   Trying xxx.xxx.174:80...
* Connected to xxx.xxx.174 (xxx.xxx.174) port 80
> GET / HTTP/1.1
> Host: xxx.xxx 174
> User-Agent: curl/8.4.0
> Accept: */*
> abc:123456
>
< HTTP/1.1 200 OK
< Date: Sat, 13 Sep 2025 16:18:38 GMT
< Content-Type: text/html
< Content-Length: 4833
< Connection: keep-alive
< Vary: Accept-Encoding
< Set-Cookie: acw_tc=0a2a24fb17577803180911860e42646551283f5ec94793498a70af97834171;path=/;HttpOnly;Max-Age=1800
< Last-Modified: Fri, 16 May 2014 15:12:48 GMT
< ETag: "53762af0-12e1"
< Accept-Ranges: bytes

サーバー

GET / HTTP/1.1
RemoteIp: xxx.xxx.xxx.103
Host: xxx.xxx.xxx.174
X-Forwarded-For: xxx.xxx.xxx.103
User-Agent: curl/8.4.0
Accept: */*
abc: 123456
X-Sinfo: on
abc-abc: 123456
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Sat, 13 Sep 2025 16:18:38 GMT
Content-Type: text/html
Content-Length: 4833

CA 相互認証

Basic Edition の ALB インスタンスは、CA 相互認証をサポートしていません。Standard Edition および WAF 対応版の ALB インスタンスは、HTTPS リスナーを追加する際に CA 相互認証をサポートします。Basic Edition の ALB インスタンスで CA 相互認証機能を使用する必要がある場合は、インスタンスエディションをアップグレードしてください。

ワイルドカード証明書のルール

証明書のアップロード

番号

ALB は Alibaba Cloud SSL 証明書サービスの証明書を使用します。したがって、証明書は ALB コンソールではなく、SSL 証明書コンソールにアップロードする必要があります。詳細については、「SSL 証明書のアップロード」をご参照ください。

証明書の有効期限が変更されない

この問題は通常、ALB インスタンスが透過型プロキシモードで WAF 2.0 と統合されており、WAF の証明書が更新されていない場合に発生します。WAF は ALB から定期的に証明書を同期します。即時更新をトリガーするには、WAF コンソールでドメインのトラフィック迂回を無効にしてから再度有効にすることができます。この操作により、証明書のリフレッシュが強制されます。この操作により、1〜2 秒の短いサービス中断が発生することにご注意ください。

ヘルスチェック設定の変更

1. Application Load Balancer (ALB) コンソールにログインします。

2. 左側のナビゲーションウィンドウで、ALB > サーバーグループ を選択します。

3. サーバーグループ ページで、対象のサーバーグループを見つけ、その ID をクリックします。

4. 詳細 タブの [ヘルスチェック] セクションで、ヘルスチェックの変更 をクリックします。

5. ヘルスチェックの変更 ダイアログボックスで、ヘルスチェックの設定 の横にある 編集 をクリックし、ヘルスチェック設定を変更してから 保存 をクリックします。

   詳細については、「ALB のヘルスチェック」をご参照ください。

ヘルスチェックが成功しているにもかかわらず 502 エラーが発生する

これは通常、ALB インスタンスのバックエンドサーバーの負荷が高すぎるためです。ALB インスタンスのバックエンドサーバーの負荷が高すぎると、ヘルスチェックの結果とアクセスリクエストの結果に不整合が生じることがあります。バックエンドサーバーの負荷を確認する方法については、「Linux インスタンスの高負荷問題のトラブルシューティングと対処」をご参照ください。

ヘルスチェックが失敗した場合のリクエスト転送

ALB インスタンスは、サービスの中断を最小限に抑えるために、設定されたスケジューリングアルゴリズムに基づいてリクエストを転送し続けます。リクエストが期待どおりに処理されない場合は、ログでバックエンドサーバーのエラーを確認するか、ヘルスチェック設定に問題がないかレビューしてください。詳細については、「ALB のヘルスチェック失敗のトラブルシューティング」をご参照ください。

ALB 経由でサービスにアクセスできない

問題を診断するには、次の手順に従ってください。

1. ドメイン名の名前解決 (CNAME) の確認：新しい ALB インスタンスには、その DNS 名を使用して直接アクセスすることはできません。CNAME レコードを使用して、カスタムドメイン名を ALB インスタンスの DNS 名にマッピングする必要があります。nslookup または dig コマンドを使用して、名前解決を確認します。詳細については、「ALB インスタンスの DNS 名」をご参照ください。

2. インスタンスのネットワークタイプの確認：プライベートネットワークの ALB インスタンスは、その Virtual Private Cloud (VPC) 内からのみアクセスできます。パブリックアクセスを有効にするには、インスタンスのネットワークタイプをパブリックに変更し、EIP を関連付けます。詳細については、「ALB インスタンスのネットワークタイプの変更」をご参照ください。

3. リスナーと転送ルールの確認：ALB コンソールで、正しいポートとプロトコルでリスナーが作成されていることを確認します。また、転送ルールが着信リクエストのドメイン名とパスに一致するように設定されていることを確認します。

4. ヘルスチェックステータスの確認：ALB コンソールで、バックエンドサーバーのヘルスチェックステータスを確認します。ALB インスタンスは、異常なバックエンドサーバーにリクエストを転送しません。

5. バックエンドサービスが正しく実行されていることの確認：バックエンドサーバーにログインし、curl -I http://<backend_server_private_IP>:<port> コマンドを実行して、バックエンドサービスが正しく応答することを確認します。

6. アクセス制御とファイアウォール設定の確認：ALB インスタンスのアクセス制御設定またはセキュリティグループルールが、クライアントのソース IP アドレス範囲を許可していることを確認します。また、バックエンドの Elastic Compute Service (ECS) インスタンス上の iptables またはサードパーティのセキュリティソフトウェアが、ALB インスタンスのローカル IP アドレス範囲を許可していることを確認します。

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

ALB はアプリケーション層で動作するため、リクエストはバックエンドサーバーに転送されます。このプロセスにより、バックエンドサーバーに直接アクセスする場合と比較して、わずかな追加レイテンシが発生します。これは想定される動作です。

著しく高いレイテンシが発生した場合は、次の手順でトラブルシューティングを行ってください。

1. アクセスログを有効にし、レイテンシフィールドを分析する：ALB アクセスログを有効にし、次のフィールドに注目します。

   • request_time：ロードバランサーが最初のリクエストパケットを受信してから、ロードバランサーがレスポンスを送信するまでの時間 (秒)。

   • upstream_response_time：ロードバランサーがバックエンドサーバーへの接続を開始してから、すべてのデータを受信して接続を閉じるまでの時間 (秒)。

2. レイテンシの原因を特定する：

   • upstream_response_time が高い場合、バックエンドサーバーがレイテンシの原因である可能性が高いです。バックエンドアプリケーションのパフォーマンス、データベースクエリの効率、CPU やメモリなどのリソース使用状況を確認してください。また、バックエンドサーバーを追加して負荷を分散することもできます。

   • request_time が upstream_response_time よりもはるかに高い場合、レイテンシはクライアントと ALB インスタンス間のネットワークパスにある可能性が高いです。クライアントから、ALB サービスアドレスへの継続的な ping テストまたは MTR トレースを実行して、ネットワークリンクの問題を診断します。

3. クロスリージョンアクセスのシナリオを考慮する：クライアントと ALB インスタンスが異なるリージョンにある場合、物理的な距離によるネットワーク遅延は避けられません。クロスリージョンアクセスのエクスペリエンスを最適化するために、Global Accelerator (GA) の使用を推奨します。

ドメイン名でサービスにアクセスできない

カスタムドメイン名を CNAME レコードで ALB インスタンスの DNS 名にマッピングした後でも、サービスにアクセスできない場合があります。HTTP 403 エラーまたは接続リセットを受け取った場合、原因はドメイン名の ICP 登録が完了していないことである可能性が高いです。

問題を診断するには、次の手順に従ってください。

1. CNAME レコード設定の確認：nslookup または dig コマンドを使用して、ドメイン名が ALB インスタンスの DNS 名に正しく解決されていることを確認します。詳細については、「CNAME レコードの設定」をご参照ください。

2. ドメイン名の ICP 登録状況の確認：規制によると、中国本土でのパブリックアクセスに使用されるドメイン名は、有効な ICP 登録が必要です。そうでない場合、アクセスはブロックされます。Alibaba Cloud ICP 登録システムにログインして、ドメイン名の登録状況を確認してください。登録されていない場合は、まず ICP 登録プロセスを完了してください。詳細については、「ICP 登録プロセス」をご参照ください。

3. ICP 登録の移管が必要かどうかの判断：ドメイン名が他のクラウドサービスプロバイダーを通じて登録され、Alibaba Cloud で初めて使用する場合は、ICP 登録の移管を完了する必要があります。このプロセスにより、登録情報が Alibaba Cloud に登録されます。移管が完了していない場合、アクセスがブロックされる可能性があります。

500 (Internal Server Error)

バックエンドサーバーで内部エラーが発生し、リクエストを処理できませんでした。

• バックエンドが直接 500 を返す：アクセスログを確認します。upstream_status が 500 の場合、ALB はバックエンドからのステータスコードをそのまま渡した可能性が高いです。バックエンドサービスを調査してください。

• バックエンドサーバーが予期せず接続を閉じた：バックエンドサーバーが完全なレスポンスを送信する前に接続を閉じました。バックエンドサーバーでパケットキャプチャを行い、予期せぬ接続切断の原因を特定してください。

502 (Bad Gateway)

このエラーは、HTTP または HTTPS リスナーがクライアントリクエストを受信したものの、ALB がリクエストをバックエンドサーバーに転送できなかったり、そこからレスポンスを受信できなかったりした場合に発生します。

トラブルシューティングのアプローチ：まず、アクセスログの upstream_status フィールドの値を確認して、次のステップを決定します。

• upstream_status = 502 の場合：ALB はバックエンドサーバーから 502 ステータスコードをそのまま渡しました。問題はバックエンドサービス自体にあります。バックエンドサービスを調査してください。たとえば、バックエンドの Nginx やゲートウェイ層が、到達不能なアップストリームへのリバースプロキシを試みていないか確認してください。

• upstream_status が他の値の場合 (例：504、444、500)：ALB がクライアントに返す status は upstream_status と異なり、ALB がステータスコードを変更したことを意味します。バックエンドの Nginx、ゲートウェイ、またはアプリケーションのログを確認して、バックエンドサービスがその特定のステータスコードを返す理由を調査してください。

• upstream_status が - または空の場合：ALB はバックエンドから何のレスポンスも受信しませんでした。これは、リクエストがバックエンドに到達しなかったか、レスポンスが送信される前にバックエンド接続が異常終了したことを意味します。次の原因を順に確認してください。

  • ALB とバックエンドサーバー間の TCP 通信が失敗している。バックエンドサービスが実行中であること、サービスポートが正しくリッスンしていること、バックエンド ECS 上の iptables ルールやサードパーティのセキュリティソフトウェアが ALB インスタンスが配置されている VSwitch の CIDR ブロックをブロックしていないことを確認してください。ALB は、VSwitch によって割り当てられたLocal IP を使用してバックエンドサーバーと通信します。パケットキャプチャを行って、TCP ハンドシェイクが成功しているか確認できます。

  • バックエンドサーバーのバックログがいっぱいになっている。これにより、サーバーは新しい接続リクエストをドロップします。バックエンドサーバーで netstat -s | grep -i listen を実行し、drop カウンターを確認してください。

  • バックエンドサーバーが時間内にリクエストを処理できなかった。バックエンドサーバーのログを確認し、CPU とメモリの使用状況をレビューして、パフォーマンスのボトルネックを特定してください。

  • クライアントリクエストのパケットサイズがバックエンドサーバーの MTU を超えている。これにより、短いパケット (ヘルスチェックなど) は成功するが、長いパケットは失敗する可能性があります。バックエンドサーバーでパケットキャプチャを行い、パケット長が必要な制限内にあるかどうかを分析してください。

  • バックエンドサーバーのレスポンスの形式が無効であるか、無効な HTTP ヘッダーが含まれている。バックエンドサーバーでパケットキャプチャを行い、レスポンス形式が標準に準拠しているかどうかを分析してください。

503 (Service Temporarily Unavailable)

サーバーは一時的に利用できません。通常、トラフィックが制限を超えたか、バックエンドサービスが利用できないことが原因です。

• バックエンドが直接 503 を返す：アクセスログを確認します。upstream_status が 503 の場合、ALB はバックエンドからのステータスコードをそのまま渡した可能性が高いです。バックエンドサービスを調査してください。

• クライアントリクエストが ALB のスロットリングをトリガーする：

  • Cloud Monitor で、Requests per second メトリックを確認します。

  • Cloud Monitor は分単位のデータを表示し、秒単位のスパイクを反映しない場合があります。アクセスログを確認してください。upstream_status フィールドが - の場合、リクエストはバックエンドサーバーに到達していません。

  • レスポンスパケットヘッダーを確認します。ヘッダーに ALB-QPS-Limited:Limited フィールドが含まれている場合、リクエストは ALB のスロットリングをトリガーしました。

• 直接 IP アクセスまたは異常な DNS 名前解決：これにより、トラフィックが少数の IP アドレスに集中し、スロットリングがトリガーされる可能性があります。ドメイン名を通じて ALB にアクセスし (「ALB インスタンスの CNAME を設定する」をご参照ください)、DNS 名前解決が期待どおりに機能することを確認してください。

• リスナーにバックエンドサーバーが設定されていないか、設定されているバックエンドサーバーの重みが 0 である。

• ALB Ingress のデフォルト転送ルールが 503 を引き起こす：ACK に ALB Ingress コントローラーをインストールすると、コントローラーは ALB インスタンス上にデフォルトの転送ルールと関連するデフォルトサーバーグループを自動的に作成します。デフォルトサーバーグループは最初は空です。着信トラフィックが設定された Ingress 転送ルールのいずれにも一致しない場合、ALB はリクエストをデフォルトの転送ルールにルーティングします。デフォルトサーバーグループが空であるため、ALB は 503 エラーを返します。これは想定される動作です。デフォルトの転送ルールを手動で削除する必要はありません。この問題を解決するには、正しいドメインベースの転送ルールを設定して、トラフィックを対応するバックエンドサーバーグループにルーティングしてください。

  説明

  503 エラーは、リクエストを処理できるバックエンドサーバーがない (サーバーグループが空である) ことを示し、バックエンドサーバーは存在するが利用できない 502 エラーとは異なります。

504 (Gateway Time-out)

ALB がバックエンドサーバーからのレスポンスを待機中にタイムアウトしました。

• バックエンドが直接 504 を返す：アクセスログを確認します。upstream_status が 504 の場合、ALB はバックエンドからのステータスコードをそのまま渡した可能性が高いです。バックエンドサービスを調査してください。

• ALB からバックエンドサーバーへの接続試行がタイムアウトする：このタイムアウトはデフォルトで 5 秒であり、変更できません。パケットキャプチャを行い、バックエンドサーバーが時間内に応答しない理由を特定してください。

• バックエンドのレスポンスタイムアウト：接続リクエストのタイムアウトはデフォルトで 60 秒です。Cloud Monitor の UpstreamResponseTime メトリックと、アクセスログの upstream_response_time フィールドを確認して、バックエンドサーバーのレスポンスがタイムアウトしたかどうかを判断できます。

WAF 2.0 透過型統合と WAF 3.0 サービスベース統合の比較

詳細については、「WAF 3.0 と WAF 2.0 の比較」をご参照ください。

ALB と WAF の統合

• ALB インスタンスの WAF 3.0 保護を有効にするには、WAF 3.0 サービスベース統合を使用することを推奨します。これは、WAF 対応の ALB インスタンスを使用することを意味します。

  • サポートされているリージョン：

    エリア	リージョン
    中国	中国 (成都)、中国 (青島)、中国 (北京)、中国 (広州)、中国 (杭州)、中国 (ウランチャブ)、中国 (上海)、中国 (深セン)、中国 (張家口)、中国 (香港)、および中国 (河源)
    アジアパシフィック	フィリピン (マニラ)、インドネシア (ジャカルタ)、日本 (東京)、マレーシア (クアラルンプール)、シンガポール、タイ (バンコク)、および韓国 (ソウル)
    ヨーロッパおよびアメリカ	ドイツ (フランクフルト)、米国 (シリコンバレー)、米国 (バージニア)、およびメキシコ
    中東	サウジアラビア (リヤド - パートナー運営) および UAE (ドバイ)

  • WAF 対応の ALB インスタンスは、WAF 3.0 SDK 統合モデルを使用します。アカウントに WAF 2.0 インスタンスがある場合は、まず WAF 2.0 インスタンスをリリースするか、WAF 3.0 に移行する必要があります。

    デフォルトでは、ALB はリクエストに X-Forwarded-Proto ヘッダーを追加しません。WAF 2.0 インスタンスをリリースした後、ALB インスタンスに直接アクセスすると、バックエンドサーバーが元のプロトコル (HTTP または HTTPS) を識別できないため、無限リダイレクトなどのサービスの問題が発生する可能性があります。この問題を回避するには、ALB リスナー設定で X-Forwarded-Proto リクエストヘッダーを手動で有効にする必要があります。

  • WAF 対応の ALB インスタンスは、WAF のデータ漏えい防止機能をサポートしていません。

• 既存の WAF 2.0 インスタンスを使用したい場合、インターネット向けの Basic および Standard の ALB インスタンスは、次のリージョンで WAF 2.0 透過型統合をサポートしています：中国 (杭州)、中国 (上海)、中国 (深セン)、中国 (成都)、中国 (北京)、および中国 (張家口)。内部向けの ALB インスタンスは、WAF 2.0 透過型統合をサポートしていません。

CLB と ALB の WAF 統合サポート

WAF 2.0 透過型統合の問題

WAF 2.0 透過型統合では、クライアントリクエストは WAF で検査された後、ALB または CLB インスタンスに送信されます。この 2 つのゲートウェイを経由するパスでは、WAF とロードバランサー間で複数の設定を同期する必要があります。特にタイムアウトと証明書の変更は、設定の同期遅延が発生しやすいです。