このトピックでは、Application Load Balancer (ALB) に関するよくある質問（FAQ）について説明します。
インスタンスと仕様
ALB には特定のインスタンス仕様がありますか？
ALB インスタンスは、特定の仕様を選択する必要はありません。スペックアップ済み ALB インスタンス では、自動スケーリング仮想 IP アドレス（VIP） を使用して、単一インスタンスで最大 100 万クエリ/秒（QPS）のパフォーマンスを実現します。ALB インスタンスのパフォーマンスに関する詳細については、「インスタンスのパフォーマンスメトリクス」をご参照ください。
スペックアップ前は、ALB インスタンスのパフォーマンスが、IP モード（静的または動的）によって異なりました。これらのインスタンスでは 自動スケーリング VIP がサポートされていませんでした。100 万 QPS を実現するには、IP アドレス数を動的にスケールアウトする必要がありました。
ALB インスタンスを IPv4 とデュアルスタック間で切り替えることはできますか？
この機能はサポートされていません。
新しい IPv4 またはデュアルスタックのインスタンスを作成する必要があります。
ネットワークと EIP
ALB インスタンスの VIP は ping を無効化できますか？
スペックアップ済み ALB インスタンス の場合、セキュリティグループ を使用してアクセストラフィックを管理できます。インスタンスのセキュリティグループにインバウンドルールを設定し、ICMP トラフィックを拒否します。
スペックアップされていないインスタンスの場合、関連付けられた Elastic IP Address（EIP）を インターネットファイアウォール に追加し、ICMP トラフィックを拒否するインバウンドポリシーを設定します。
ALB インスタンスのパブリック帯域幅をどのようにして増加させますか？
2 つのゾーンに展開された ALB インスタンスがインターネット共有帯域幅に追加されていない場合、デフォルトのピークパブリック帯域幅は 400 Mbps です。
帯域幅を追加で確保するには、インターネット共有帯域幅を購入し、ALB インスタンスに関連付けられている EIP をそれに追加します。
インターネット共有帯域幅の購入方法については、「インターネット共有帯域幅の作成と管理」をご参照ください。
EIP をインターネット共有帯域幅に追加する方法については、「ALB インスタンスの作成と管理」および「パブリック向けインスタンスのピーク帯域幅の調整」をご参照ください。
Data Transfer Plan を使用して ALB インスタンスのパブリックトラフィック料金を支払うことはできますか？
ALB インスタンスが Elastic IP アドレス (EIP) を使用してパブリックサービスを提供する場合、EIP によって生成されるパブリックトラフィックの支払いに、汎用 Data Transfer Plan を使用できます。
ALB インスタンスが Anycast EIP を使用してパブリックサービスを提供する場合、Anycast EIP によって生成されたパブリックトラフィックの料金の支払いに、汎用 Data Transfer Plan を使用することはできません。
ALB インスタンスに関連付け可能な EIP の種類
ALB は、従量課金の EIP インスタンスのみをサポートしています。次の表では、ALB インスタンスに関連付け可能な EIP のタイプについて説明します。
課金方法 | パブリックネットワーク課金方法 | 回線タイプ | セキュリティ保護 |
従量課金 | トラフィック課金 | BGP（マルチ ISP） | デフォルト |
トラフィック課金 | BGP（マルチ ISP）_プレミアム | デフォルト | |
トラフィック課金 | BGP（マルチ ISP） | Anti-DDoS（強化版） |
EIP を ALB インスタンスに関連付ける場合、次の点にご注意ください。
ALB インスタンスのすべてのゾーンにバインドされている EIP は、同じタイプである必要があります。
EIP を関連付ける前に、その EIP がインターネット共有帯域幅に追加されていないことを確認してください。EIP を ALB インスタンスに関連付けた後、SLB コンソールでインターネット共有帯域幅に追加できます。EIP の回線タイプは、インターネット共有帯域幅の回線タイプと一致している必要があります。サブスクリプションおよび従量課金のインターネット共有帯域幅プランの両方がサポートされています。EIP をインターネット共有帯域幅に追加する方法について詳しくは、「パブリックインスタンスのピーク帯域幅を調整する」をご参照ください。
サブスクリプション EIP および帯域幅課金方式の従量課金 EIP は関連付けられません。
ALB インスタンスに EIP を割り当てる際に [EIP の購入] または [パブリック IP の自動割り当て] を選択した場合、デフォルトのセキュリティ保護を備えた従量課金 (トラフィック課金) の BGP(マルチ ISP) EIP が作成されます。
プライベート ALB インスタンスに EIP を関連付けることはできますか？
サポートされています。
内部向け ALB に EIP を関連付けるには、インスタンスのネットワークタイプを変更して、内部向け ALB をインターネット向け ALB に変換します。詳細については、「ALB インスタンスのネットワークタイプの変更」をご参照ください。
ネットワークタイプをプライベートからパブリックに変更すると、EIP がインスタンスに関連付けられ、パブリックネットワーク料金が発生します。詳細については、「EIP の課金」をご参照ください。
ALB インスタンスの EIP をプレミアム EIP に変更するにはどうすればよいですか。
次の手順で置き換えられます：ALB インスタンスのネットワークタイプの変更：
ALB インスタンスのネットワークタイプをパブリックからプライベートに変更します。これにより、EIP がインスタンスからデタッチされます。
ALB インスタンスのネットワークタイプをプライベートからパブリックに戻します。変換時に、あらかじめ作成した 2 つのプレミアム BGP（マルチ ISP）EIP を選択します。
ALB インスタンスにバインドされた EIP 間でトラフィック負荷が不均等になる理由
以下のような理由が考えられます：
ビジネスのドメイン名が、ALB インスタンスの DNS 名ではなく、ALB インスタンスにバインドされた単一の EIP に解決されている。
WAF や Anti-DDoS Proxy などのレイヤー 7 プロキシが ALB インスタンスの前方に配置されている。プロキシの back-to-origin アルゴリズム（例：IP ハッシュ）により、複数の EIP 間でトラフィックが均等に分散されない。
一部のクライアントが DNS 解決から返された A レコードをキャッシュしている。これにより、多数のリクエストが同一の EIP に送信される。
ALB DNS 削除に関する注意事項
スペックアップ済み ALB インスタンス では、DNS 削除および復元がデフォルトでサポートされています。
スペックアップ前は、静的 IP モードの ALB インスタンスのみが DNS 削除および復元をサポートしていました。動的 IP モードのインスタンスではサポートされていませんでした。
DNS 削除が完了すると、ゾーン内の VIP に対する可用性プロービングが停止します。VIP または EIP（IPv4 および IPv6 アドレスを含む）は、ALB ドメイン名の DNS 解決から削除されます。IPv4 アドレスまたは IPv6 アドレスのいずれか一方のみを削除することはできません。
リスナーと転送
ALB はトラフィックミラーリングをサポートしていますか？
はい。詳細については、「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 が転送するリクエストの長さ制限は？調整可能ですか？
リクエスト URI の最大長は 32 KB、リクエストヘッダーの最大長も 32 KB です。これらの制限は変更できません。アクセスログにおけるカスタムヘッダーのデフォルト長は 1 KB です。上限を最大 4 KB まで引き上げるには、アカウントマネージャーにお問い合わせください。
クライアントリクエストのサイズが制限を超えると、400 または 414 ステータスコードが返される場合があります。詳細については、「ALB エラーコード」をご参照ください。
データ量が大きい場合は、POST メソッドの使用を推奨します。POST リクエストの本文は最大 50 GB まで可能です。
ALB 処理時間には、クライアントデータの受信および送信にかかる時間も含まれますか？
ALB の処理時間には、クライアントデータの受信および送信に要する時間も含まれます。
クライアントから ALB への単一 HTTP 持続的接続でサポートされる最大リクエスト数
単一の持続的接続では、最大 100 回の連続リクエストをサポートします。この上限を超えると、接続は自動的に閉じられます。
HTTPS リスナーを使用し、HTTP/2 を有効化している場合、単一の持続的接続でサポートされる最大リクエスト数は 1,000 に増加します。
ALB QUIC リスナーのクライアント Hello パケットの長さ制限
QUIC リスナーを使用する場合、ALB はクライアント Hello パケットの最小長を設定します。このパケットは少なくとも 1,024 バイトである必要があります。それより短い場合、ALB は「client hello too small」エラーを返し、接続を閉じます。1,024 バイトの要件を満たすために、クライアント Hello パケットをヌル文字でパディングできます。
ALB Ingress の使用上の注意事項
ほとんどの場合、コンソールで ALB Ingress を使用して作成された ALB インスタンスは手動で変更しないでください。ALB インスタンスの構成は、AlbConfig リソースに基づいて同期されます。ALB Ingress の詳細については、「ALB Ingress の管理」および「ALB Ingress の特徴」をご参照ください。
コンソールで手動変更を行うと、AlbConfig が更新されていないため、変更内容が上書きされます。これにより、アクセスログが無効化されたり、転送ルールが削除されたりするなどの問題が発生する可能性があります。
ALB におけるクロスオリジンリクエストに関する FAQ
なぜクロスオリジン構成が有効にならず、ブラウザがプリフライトリクエストエラーを報告するのでしょうか？
[許可されたリクエストヘッダー] を「*」ではなく特定のヘッダー名で構成している場合、テストのために「*」に設定してみてください。問題が解決された場合は、プリフライトリクエストの Access-Control-Request-Headers フィールドに含まれる header_name が構成から欠落しているかどうかを確認してください。これが原因でプリフライトリクエストが失敗しています。
プリフライトリクエストと実際のリクエストが異なる転送ルールにマッチする
ALB は、転送ルールに対して多様なマッチング方法をサポートしています。ただし、クロスオリジンシナリオにおけるプリフライトリクエストは、そのヘッダーおよびメソッドが実際のリクエストと異なるという特殊性があるため、ドメイン名を使用して転送ルールを設定することを推奨します。これにより、プリフライトリクエストおよび実際のリクエストが、クロスオリジンリクエスト用に構成されていない転送ルールにマッチしてしまうことを防ぎ、不要な問題を回避できます。
CORS 構成時における Access-Control-Allow-Headers 応答ヘッダーの生成および返却方法
プリフライトリクエスト
ブラウザがクロスオリジンリクエストを開始し、以下の条件が満たされた場合、まず
OPTIONSメソッドを使用したプリフライトリクエストを送信します：リクエストメソッドが
OPTIONSである。リクエストに
Access-Control-Request-Methodヘッダーが含まれている。
この場合、ALB はコンソールで設定したクロスオリジン転送ルールに基づき、
Access-Control-Allow-Headers応答ヘッダーを返します。この応答ヘッダーの値は、ルールで許可されたリクエストヘッダーフィールドの一覧です。例：DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorizationシンプルなクロスオリジンリクエスト
OPTIONS 以外のリクエスト、またはプリフライト条件を満たさないシンプルなリクエストの場合、ALB は
Access-Control-Allow-Headers応答ヘッダーを返しません。
証明書および HTTPS
ALB は相互認証をサポートしていますか？
Basic Edition の ALB インスタンスは相互認証をサポートしていません。Standard Edition および WAF 有効化済みの ALB インスタンスでは、HTTPS リスナーの追加 時に相互認証を有効化できます。Basic Edition の ALB インスタンスで相互認証を使用するには、インスタンスのエディションを変更 してください。
相互認証機能を使用する場合、Alibaba Cloud または第三者が発行した CA 証明書を選択できます。
Alibaba Cloud が発行した CA 証明書を選択する場合、Alibaba Cloud のプライベート CA 証明書を選択または購入する必要があります。
第三者が発行した CA 証明書を選択する場合、CA 証明書を選択またはアップロードする必要があります。CA 証明書をアップロードするには、自己署名 CA 証明書のアップロード を デフォルト CA 証明書の選択 ドロップダウンリストからクリックします。証明書リポジトリ ページで、データソースが CA 証明書のアップロード のリポジトリを作成します。その後、証明書アプリケーションリポジトリを通じて、自己署名ルート CA または自己署名中間 CA 証明書をアップロードします。
ALB リスナー用ワイルドカード証明書が満たすべきルール
ALB インスタンスに HTTPS リスナーを追加する場合、選択した証明書がワイルドカード証明書である場合、以下のルールに注意してください。
ワイルドカード証明書を選択すると、ALB は、単一のワイルドカード (
*) を含み、かつそのワイルドカード (*) がドメイン名の先頭に配置されている証明書のみを識別できます。 たとえば、ALB は*.example.comや*test.example.comは識別できますが、test*.example.comは識別できません。ワイルドカードドメイン名のマッチングルール：
ワイルドカードレベル：ワイルドカードドメイン名は、同一レベルのサブドメインのみをマッチさせることができます。たとえば、
*.example.comはtest.example.comをマッチさせることができますが、test.test.example.comはマッチさせられません。これは、サブドメインとワイルドカードドメイン名が異なるレベルにあるためです。IDNA サポート：
ワイルドカード証明書のワイルドカード文字が左端のラベルで唯一の文字である場合、IDNA ラベルはワイルドカード文字とマッチします。たとえば、
xn--fsqu00a.example.comは*.example.comとマッチします。ワイルドカード証明書のワイルドカード文字が左端のラベルで唯一の文字でない場合、IDNA ラベルはその部分のワイルドカードとマッチしません。たとえば、
xn--fsqu00atest.example.comは*test.example.comとマッチしません。
文字サポート：ワイルドカード証明書のワイルドカード文字（
*）は、数字（0–9）、大文字および小文字、ハイフン（-）のみをマッチさせることができます。たとえば、*.example.comはtest.example.comをマッチさせることができますが、test_test.example.comはマッチさせられません。
ALB コンソールで証明書をアップロードできますか？
No.
ALB は、Alibaba Cloud の SSL 証明書サービスから直接証明書を取得します。証明書は、SSL 証明書コンソールにアップロードする必要があります。したがって、ALB コンソールでは証明書をアップロードできません。詳細については、「SSL 証明書のアップロード」をご参照ください。
ALB 証明書を更新した後、ブラウザのドメイン名証明書の有効期限が変更されない
これは通常、ALB が透過プロキシモードで WAF 2.0 と接続されており、WAF 側の証明書が更新されていないことが原因です。WAF は ALB から定期的に証明書を同期します。即座に同期するには、WAF 側でトラフィックリダイレクトを無効化してから再び有効化し、証明書ステータスを強制的に更新します。この操作により、1～2 秒間の瞬断が発生することにご注意ください。
ヘルスチェック
リスナーのヘルスチェック構成を変更する方法
Application Load Balancer コンソール にログインします。
左側のナビゲーションウィンドウで、 を選択します。
サーバーグループ ページで、対象のサーバーグループを見つけ、その ID をクリックします。
詳細 タブの **ヘルスチェック** セクションで、ヘルスチェックの編集 をクリックします。
ヘルスチェックの編集 ダイアログボックスで、ヘルスチェック構成 の右側にある 編集 をクリックし、必要に応じてヘルスチェック構成を変更します。その後、保存 をクリックします。
詳細については、「ヘルスチェック」をご参照ください。
ヘルスチェックが正常なのに 502 ステータスコードが返される理由
これは通常、ALB インスタンスのバックエンドサーバーが過負荷になっていることが原因です。ALB インスタンスのバックエンドサーバーが過負荷になると、ヘルスチェックの結果がアクセスリクエストの結果と一致しない場合があります。バックエンドサーバーの負荷をクエリする方法の詳細については、「Linux インスタンスの高負荷問題のトラブルシューティングと対処」をご参照ください。
サーバーグループ内のすべてのバックエンドサーバーが不健全な場合の ALB のリクエスト転送方法
ALB は、ビジネスへの影響を最小限に抑えるために、スケジューリングアルゴリズムに基づいてリクエストの転送を継続します。リクエストが期待通りに動作しない場合は、バックエンドサーバーの例外をログで確認するか、ヘルスチェック構成に異常がないか確認してください。詳細については、「ALB ヘルスチェック例外のトラブルシューティング」をご参照ください。
トラブルシューティング
ALB 経由でサービスにアクセスできない場合のトラブルシューティング手順
以下の手順に従ってください：
ドメイン名の名前解決（CNAME）の確認：新しい ALB インスタンスは、その DNS 名を直接使用してアクセスすることはできません。カスタムドメイン名を ALB インスタンスの DNS 名に CNAME レコードで解決する必要があります。名前解決結果の検証には、
nslookupまたはdigコマンドを使用できます。詳細については、「ALB インスタンスの DNS 名」をご参照ください。インスタンスのネットワークタイプの確認：プライベート ALB インスタンスは VPC 内からのみアクセス可能です。インターネットからはアクセスできません。パブリックアクセスを有効化するには、インスタンスのネットワークタイプをパブリックに変更し、EIP を関連付けます。詳細については、「ALB インスタンスのネットワークタイプの変更」をご参照ください。
リスナーおよび転送ルールの確認：ALB コンソールで、リスナーが作成されているかを確認し、リスナーポートおよびプロトコルが正しく設定されているか、また転送ルールがリクエストのドメイン名およびパスとマッチするかを確認します。
ヘルスチェックステータスの確認：ALB コンソールで、バックエンドサーバーのヘルスチェックステータスを確認します。バックエンドサーバーが不健全な場合、ALB がリクエストを正常に転送できない可能性があります。
バックエンドサービスの正常性確認：バックエンドサーバーにログインし、
curl -I http://<バックエンドサーバーのプライベート IP>:<ポート>コマンドを実行して、バックエンドサービス自体が正常に応答できるかを確認します。セキュリティグループルールの確認：バックエンドサーバーおよび ALB インスタンスのセキュリティグループルールを確認し、リスナーポートおよびリクエスト元アドレス範囲が許可されているかを確認します。
ALB 経由でのアクセス時に高遅延が発生する場合のトラブルシューティング手順
ALB はアプリケーション指向のサービスであり、リクエストは ALB を経由してバックエンドサーバーに転送されます。バックエンドへの直接アクセスと比較すると、わずかな遅延の増加が発生しますが、これは正常です。
遅延が著しく高い場合は、以下の手順でトラブルシューティングを行ってください：
アクセスログを有効化し、遅延関連フィールドを分析：ALB アクセスログ を有効化し、以下のフィールドに注目します：
request_time：ロードバランサーが最初のリクエストパケットを受信してから応答を返すまでの秒単位の時間間隔。upstream_response_time：ロードバランサーがバックエンドサーバーとの接続を確立してから、データの受信を完了して接続を閉じるまでの秒単位の時間。
遅延の発生源の特定：
upstream_response_timeが大きい場合：遅延は通常、バックエンドサーバーの処理が遅いことが原因です。バックエンドアプリケーションのパフォーマンス、データベースクエリの効率、CPU／メモリ使用率を確認するか、負荷を分散するためにバックエンドサーバーを追加することを推奨します。request_timeがupstream_response_timeよりも大幅に大きい場合：遅延はクライアントから ALB へのネットワークリンクに起因している可能性があります。クライアントから ALB のエンドポイントへ、継続的なpingテストまたは MTR ルートトレースを実行して、ネットワークリンクの問題をトラブルシューティングすることを推奨します。
クロスリージョンアクセスのシナリオ：クライアントと ALB インスタンスが異なるリージョンにある場合、物理的な距離によるネットワーク遅延は避けられません。クロスリージョンアクセスの体験を最適化するには、Global Accelerator（GA）の使用を推奨します。
ドメイン名経由で ALB サービスにアクセスできない場合の対応
新しい ALB インスタンスは、その DNS 名を直接使用してアクセスすることはできません。カスタムドメイン名を ALB インスタンスの DNS 名に CNAME レコードで解決する必要があります。CNAME レコードを正しく設定したにもかかわらず、サービスにアクセスできない場合（403 が返される、または接続がリセットされる）、最も一般的な原因はドメイン名の ICP 登録が未完了であることです。
以下の手順でトラブルシューティングを行ってください：
CNAME 解決構成の確認：
nslookupまたはdigコマンドを使用して、ドメイン名が ALB インスタンスの DNS 名に正しく解決されているかを確認します。詳細については、「CNAME 解決の設定」をご参照ください。ドメイン名の ICP 登録ステータスの確認：関連する規制によると、中国本土でパブリックネットワークを介してサービスにドメイン名を使用してアクセスする場合、ドメイン名は ICP 登録を完了している必要があります。登録が未完了の場合、アクセスはブロックされます。ドメイン名の登録ステータスを照会するには、Alibaba Cloud ICP 登録システム にログインします。登録が未完了の場合は、まず ICP 登録を完了してください。詳細については、「ICP 登録の手順」をご参照ください。
Alibaba Cloud を ICP 登録情報のサービスプロバイダーとして追加する必要があるかの確認：他のクラウドサービスプロバイダーでドメイン名の ICP 登録が完了しているが、Alibaba Cloud で初めて使用する場合、Alibaba Cloud を ICP 登録情報のサービスプロバイダーとして追加する必要があります。これを怠ると、アクセスがブロックされる可能性があります。
一般的なエラーステータスコードおよびその原因
500（Internal Server Error）
バックエンドサーバーで内部エラーが発生し、リクエストを実行できませんでした。
バックエンドが直接 500 を返す：アクセスログを確認します。
upstream_statusが500の場合、ALB はおそらく上流のステータスコードをそのまま通過させています。バックエンドサービスをトラブルシューティングしてください。バックエンドサーバーが接続を異常終了：バックエンドサーバーが完全な応答を送信する前に接続を異常に閉じました。バックエンドサーバーでパケットキャプチャを行い、異常な接続終了の原因をトラブルシューティングしてください。
502（Bad Gateway）
HTTP または HTTPS リスナーがクライアントリクエストを受信した後、ALB がバックエンドサーバーにリクエストを適切に転送できなかった、またはバックエンドサーバーからの応答を受信できませんでした。
バックエンドが直接 502 を返す：アクセスログを確認します。
upstream_statusが502の場合、ALB はおそらく上流のステータスコードをそのまま通過させています。バックエンドサービスをトラブルシューティングしてください。バックエンドが他のエラーステータスコードを返す：たとえば
504や444などですが、ALB は一律に502を返します。アクセスログのstatusおよびupstream_statusフィールドを確認し、上流のステータスコードに基づいてトラブルシューティングを行ってください。ALB とバックエンドサーバー間の TCP 通信エラー：バックエンドサービスが正常に実行されているか、サービスポートが正しくリッスンしているか、または TCP ハンドシェイクが正常かどうかをパケットキャプチャで確認してください。
バックエンドサーバーの backlog が満杯：これにより、新しい接続要求が拒否または破棄されます。バックエンドサーバーで
netstat -s | grep -i listenを実行し、dropカウンターがあるかどうかを確認してください。クライアントパケット長がバックエンドサーバーの MTU を超過：ヘルスチェックなどの短いパケットは正常ですが、長いパケットが異常になります。バックエンドサーバーでパケットキャプチャを行い、パケット長が要件を満たしているかを分析してください。
バックエンドサーバーの応答パケット形式が異常または不正な HTTP ヘッダーを含む：バックエンドサーバーでパケットキャプチャを行い、応答パケット形式が標準であるかを分析してください。
バックエンドサーバーがリクエストを適切なタイミングで処理しなかった：バックエンドサーバーのログを確認し、CPU およびメモリ使用率を確認してください。
503（Service Temporarily Unavailable）
サーバーが一時的に利用不可です。通常はトラフィックの超過またはバックエンドサービスの利用不可が原因です。
バックエンドが直接 503 を返す：アクセスログを確認します。
upstream_statusが503の場合、ALB はおそらく上流のステータスコードをそのまま通過させています。バックエンドサービスをトラブルシューティングしてください。クライアントリクエストが ALB の速度制限をトリガー：
CloudMonitor を通じて
Requests per secondメトリクスを確認します。CloudMonitor は分単位のデータを表示するため、秒単位の超過状況を反映しない場合があります。アクセスログを確認し、
upstream_statusフィールドの値が-の場合、リクエストはバックエンドサーバーに到達していません。応答パケットヘッダーを確認し、
ALB-QPS-Limited:Limitedフィールドが含まれている場合、リクエストが ALB の速度制限をトリガーしています。
クライアントが ALB の IP を直接アクセス、またはドメイン名経由でのアクセス時に DNS 解決が異常：これにより、トラフィックが少数の IP に集中し、制限を超える可能性があります。クライアントは ALB のドメイン名を経由してアクセスすることを推奨します（「ALB インスタンスの CNAME レコードの設定」を参照し、DNS 解決が正常であることを確認してください）。
リスナーにバックエンドサーバーが構成されていない、または構成されたバックエンドサーバーの重みが
0
504（Gateway Time-out）
バックエンドサーバーの応答がタイムアウトしました。
バックエンドが直接 504 を返す：アクセスログを確認します。
upstream_statusが504の場合、ALB はおそらく上流のステータスコードをそのまま通過させています。バックエンドサービスをトラブルシューティングしてください。ALB とバックエンドサーバー間の接続確立がタイムアウト：デフォルトのタイムアウトは 5 秒で、変更できません。バックエンドサーバーの応答がタイムアウトする理由をパケットキャプチャでトラブルシューティングしてください。
バックエンドサーバーの応答がタイムアウト：接続要求タイムアウト はデフォルトで 60 秒です。CloudMonitor の
UpstreamResponseTimeメトリクスおよびアクセスログのupstream_response_timeフィールドを確認し、バックエンドサーバーの応答がタイムアウトしたかどうかを判断できます。
WAF 統合
WAF 2.0 の透過プロキシモードと WAF 3.0 の統合モードの違い
両者の違いを以下にまとめます：
WAF 2.0 透明プロキシモード: クライアントのリクエストは、まず WAF による検査を受けてから、ALB または CLB に転送されます。透明プロキシモードでは、リクエストが 2 つのゲートウェイを通過します。したがって、タイムアウト期間や証明書などの構成を、WAF 側およびロードバランサ側の両方で管理する必要があります。
WAF 3.0 サービス統合モード：WAF はバイパスモードで展開されます。クライアントのリクエストは直接 ALB に送信されます。リクエストがバックエンドサーバーに転送される前に、ALB がリクエストの内容を抽出し、WAF に検査のために送信します。サービス統合モードでは、リクエストは 1 つのゲートウェイのみを通過します。これにより、ゲートウェイ間での証明書および構成の同期を不要とし、同期問題を防止します。
詳細については、「WAF 3.0 と WAF 2.0 の比較」をご参照ください。
ALB と WAF の統合に関する手順
ALB インスタンスに WAF 3.0 の保護を適用するには、サービス統合方式で WAF 3.0 の保護を有効化 することを推奨します。つまり、WAF 有効化済みの ALB インスタンスを使用します。
サポートされるリージョン：
エリア
リージョン
中国
中国（成都）、中国（青島）、中国（北京）、中国（広州）、中国（杭州）、中国（ウランチャブ）、中国（上海）、中国（深セン）、中国（張家口）、中国（香港）
アジア太平洋
フィリピン（マニラ）、インドネシア（ジャカルタ）、日本（東京）、マレーシア（クアラルンプール）、シンガポール、タイ（バンコク）、韓国（ソウル）
ヨーロッパおよびアメリカ
ドイツ（フランクフルト）、米国（バージニア）、米国（シリコンバレー）、メキシコ
中東
SAU（リヤド - パートナー リージョン）
WAF のバージョン：WAF 3.0 を使用する必要があります。アカウントに WAF 2.0 インスタンスがある場合は、まず WAF 2.0 インスタンスを解放 するか、WAF 3.0 へ移行 する必要があります。
デフォルトでは、ALB はバックエンドサーバーグループに転送されるリクエストにおいて
X-Forwarded-Protoヘッダーを有効化していません。WAF 2.0 インスタンスを解放した後、ALB を直接アクセスすると、バックエンドサービスがプロトコル（HTTP/HTTPS）を正しく識別できないため、無限ループリダイレクトなどのサービス障害が発生する可能性があります。この問題を防ぐため、ALB リスナー構成でX-Forwarded-Protoリクエストヘッダーを手動で有効化する必要があります。機能の利用可否：ALB インスタンス向け WAF では、以下の機能はサポートされていません：データ漏洩防止モジュールおよびボット管理モジュール内の Web SDK 自動統合機能（ウェブサイト向けのクローラー対策ルール）。
アカウントに既存の WAF 2.0 インスタンスを使用する場合、パブリック向け Basic Edition および Standard Edition の ALB インスタンスは、WAF 2.0 の保護との透過的統合をサポートしています。サポートされるリージョン：中国（杭州）、中国（上海）、中国（深セン）、中国（成都）、中国（北京）、中国（張家口）。プライベート ALB インスタンスは、WAF 2.0 の保護との統合をサポートしていません。
CLB および ALB は、WAF 2.0 の透過的統合および WAF 3.0 のサービス統合をサポートしていますか？
製品 | WAF 2.0 の透過的統合 | WAF 3.0 のサービス統合 |
CLB | サポートされています CLB と WAF 2.0 の透過的統合方法については、以下をご参照ください： | サポートされていません |
ALB |
| サポートされています サポートされるリージョンおよび関連操作については、「ALB インスタンスへの WAF 保護の有効化」をご参照ください。 |
WAF 2.0 の透過的統合でタイムアウト期間および証明書の非同期が発生する理由
WAF 2.0 透明統合を使用する場合、クライアントリクエストはまず WAF によって検査され、その後 ALB または CLB に転送されます。クライアントリクエストは 2 つのゲートウェイを通過するため、WAF 側およびロードバランサ側の間で複数の構成を同期する必要があります。これは、特にタイムアウト期間や証明書を変更する際に、同期遅延を引き起こしやすくなります。